Sauvegarder les journaux de trace du serveur de bases de données dans un
fichier plutôt que dans /dev/null est une bonne idée. Les
journaux sont d'une utilité incomparable lorsqu'arrive le moment où des
problèmes surviennent.
Les traces d'un serveur peuvent contenir des informations sensibles et ont
besoin d'être protégées, peu importe où et comment ils sont enregistrés, ou
leur destination d'envoi. Par exemple, certaines requêtes DDL pourraient
contenir des mots de passe en clair ou d'autres détails d'authentification.
Les instructions tracées au niveau ERROR pourraient
afficher le code source SQL des applications, et pourraient aussi contenir
une partie des lignes de données. Enregistrer des données, événements et
informations relatives est le but assumé de cette fonctionnalité, donc il ne
s'agit pas d'une fuite d'information ou d'un bug. Merci de vous assurer que
les traces du serveur sont visibles uniquement par les personnes
appropriées.
Les journaux ont tendance à être volumineux (tout spécialement à des niveaux de débogage importants) et vous ne voulez pas les sauvegarder indéfiniment. Vous avez besoin de faire une « rotation » des journaux pour que les nouveaux journaux sont commencés et que les anciens soient supprimés après une période de temps raisonnable.
Si vous redirigez simplement stderr du
postgres dans un fichier, vous aurez un journal des
traces mais la seule façon de le tronquer sera d'arrêter et de relancer
le serveur. Ceci peut convenir si vous utilisez
PostgreSQL dans un environnement de développement
mais peu de serveurs de production trouveraient ce comportement acceptable.
Une meilleure approche est d'envoyer la sortie
stderr du serveur dans un programme de rotation de
journaux. Il existe un programme interne de rotation que vous pouvez
utiliser en configurant le paramètre logging_collector à
true dans postgresql.conf. Les
paramètres de contrôle pour ce programme sont décrits dans Section 19.8.1. Vous pouvez aussi utiliser cette
approche pour capturer les données des journaux applicatifs dans un format
CSV (valeurs séparées par des virgules) lisible par une
machine
Sinon, vous pourriez préférer utiliser un programme externe de rotation de
journaux si vous en utilisez déjà un avec d'autres serveurs. Par exemple,
l'outil rotatelogs inclus dans la distribution
Apache peut être utilisé avec
PostgreSQL. Pour cela, envoyez via un tube la
sortie stderr du serveur dans le programme
désiré. Si vous lancez le serveur avec pg_ctl, alors
stderr est déjà directement renvoyé dans
stdout, donc vous avez juste besoin d'ajouter la commande via
un tube, par exemple :
pg_ctl start | rotatelogs /var/log/pgsql_log 86400
Vous pouvez combiner ces approches en configurant
logrotate pour qu'il récupère les fichiers de
trace produits par le collecteur de trace de
PostgreSQL. Dans ce cas, le collecteur définit
les noms et emplacement des fichiers de trace, alors que
logrotate les archive périodiquement. Lors d'une
rotation de fichier de traces, logrotate doit
s'assurer que l'application envoie les nouvelles traces dans le nouveau
fichier. Ceci se fait habituellement avec un script
postrotate qui envoie un signal
SIGHUP à l'application, qui ouvre ensuite de nouveau le
fichier de traces. Dans PostgreSQL, vous pouvez
exécuter pg_ctl avec l'option
logrotate. Quand le serveur reçoit cette commande, soit
le serveur bascule vers un nouveau fichier de trace soit il ouvre le
fichier existant, suivant la configuration des traces (voir Section 19.8.1).
Lors de l'utilisation de noms de fichier statique, le serveur pourrait
échouer lors de la réouverture du fichier de trace si la limite du nombre
maximum de fichiers ouvert est atteint ou qu'un dépassement de la table de
fichiers survient. Dans ce cas, les traces sont envoyées à l'ancien
fichier de traces jusqu'à la réussite de la rotation du fichier de trace.
Si logrotate est configuré pour compresser le
fichier de trace et le supprimer, le serveur pourrait perdre les messages
tracées pendant cette fenêtre de temps. Pour éviter ce problème, vous
pouvez configurer le collecteur de traces pour qu'il affecte dynamiquement
les noms des fichiers de trace et utilise un script
prerotate pour ignorer les fichiers de trace ouverts.
Une autre approche de production pour la gestion des journaux de trace est
de les envoyer à syslog et de laisser syslog
gérer la rotation des fichiers. Pour cela, initialisez le paramètre de
configuration log_destination à syslog (pour tracer
uniquement via syslog) dans postgresql.conf.
Ensuite, vous pouvez envoyer un signal SIGHUP au démon
syslog quand vous voulez le forcer à écrire dans un nouveau
fichier. Si vous voulez automatiser la rotation des journaux, le programme
logrotate peut être configuré pour fonctionner
avec les journaux de traces provenant de syslog.
Néanmoins, sur beaucoup de systèmes, syslog n'est pas très
fiable, particulièrement avec les messages très gros ; il pourrait
tronquer ou supprimer des messages au moment où vous en aurez le plus besoin.
De plus, sur Linux, syslog synchronisera tout
message sur disque, amenant des performances assez pauvres. (Vous pouvez
utiliser un « - » au début du nom de fichier dans le fichier de
configuration syslog pour désactiver la synchronisation.)
Notez que toutes les solutions décrites ci-dessus font attention à lancer de nouveaux journaux de traces à des intervalles configurables mais ils ne gèrent pas la suppression des vieux fichiers de traces, qui ne sont probablement plus très utiles. Vous voudrez probablement configurer un script pour supprimer périodiquement les anciens journaux. Une autre possibilité est de configurer le programme de rotation pour que les anciens journaux de traces soient écrasés de façon cyclique.
pgBadger est un projet externe qui analyse les journaux applicatifs d'une façon très poussée. check_postgres fournit des alertes Nagios quand des messages importants apparaît dans les journaux applicatifs, mais détecte aussi de nombreux autres cas.