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 peuvent contenir des informations sensibles et doivent donc être
protégées, peu importe où et comment ils sont enregistrées, ou la
destination où ils sont envoyés. Par exemple, certaines requêtes DDL
pourraient contenir des mots de passe en clair ou d'autres informations
d'authentification. Les requêtes tracées au niveau ERROR
pourraient afficher le source SQL des applications et pourraient aussi
contenir certaines parties des lignes de données. Enregistrer les données,
événements et les informations relatives est la fonction souhaitée de cette
fonctionnalité, donc ce n'est ni une information affichée sans raison ni un
bug. Merci de vous assurer que les traces du serveur sont visibles
uniquement aux personnes dûment autorisées.
Néanmoins, 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 la sortie stderr du
processus 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 20.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 ré-ouvre le
fichier existant, suivant la configuration des traces (voir Section 20.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 apparaissent dans les journaux applicatifs, mais détecte aussi de nombreux autres cas.