21.3. Maintenance du fichier de traces

Il est bon de sauvegarder les traces du serveur de données plutôt que se contenter de les rediriger vers /dev/NULL. Les journaux de traces s'avèrent très précieux quand il s'agit de diagnostiquer un problème. Mais ces traces peuvent devenir volumineuses (notamment si le niveau de débogage est élevé) et il n'est pas souhaitable de les conserver indéfiniment. Il est nécessaire de << recycler >> les journaux de traces de façon à supprimer les anciennes informations au fur et à mesures que de nouvelles apparaîssent.

En redirigeant simplement stderr du postmaster dans un fichier, le seul moyen de tronquer le fichier est de redémarrer postmaster. Cela peut suffire pour les environnements de développement mais pas pour un serveur de production.

La meilleure approche de production pour gérer ces traces est de les renvoyer vers syslog qui gérera le recyclage du fichier. Pour ce faire, on fixera le paramètre de configuration syslog à 2 (pour tracer vers syslog uniquement) dans postgresql.conf. Il suffit alors d'envoyer le signal SIGHUP au démon syslog chaque fois qu'on voudra écrire dans un nouveau fichier. Pour automatiser la rotation des traces, on pourra configurer le programme logrotate pour s'appliquer aux fichiers de syslog.

Sur la plupart des systèmes, syslog n'est pas très sûr, particulièrement pour les messages volumineux ; il peut arriver que ceux-ci soient tronqués voire perdus, juste quand on en a réellement besoin ! On préfèrera peut-être rediriger stderr de postmaster vers un programme qui réaliserait le recyclage des traces. En démarrant le serveur avec pg_ctl, stderr est déjà redirigé vers stdout ; une commande << pipe >> alors suffira :

pg_ctl start | logrotate

La distribution de PostgreSQL n'inclut pas de programme de rotation de traces adapté mais plusieurs sont disponibles sur Internet. Il y en a un dans la distribution d'Apache par exemple.