Documentation PostgreSQL 14.22 » Administration du serveur » Planifier les tâches de maintenance » Maintenance du fichier de traces

Précédent | Niveau supérieur | Suivant
25.2. Ré-indexation régulière | Sommaire | Chapitre 26. Sauvegardes et restaurations

## 25.3. Maintenance du fichier de traces

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.

### Note

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 soient 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).

### Note

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.