PgBadger¶

PgBagder est un script en Perl développé par Gilles Darold, avec la contribution de la communauté PostgreSQL.

Il analyse les traces applicatives de PostgreSQL et génère un rapport contenant les informations suivantes :

Statistiques globales
Nombre de connexions par base, client, utilisateur, application
Activité du moteur : checkpoints, autovacuum, autoanalyze
Statistiques sur le nombre de fichiers temporaires générés par les requêtes
Analyse des durées d’exécution des requêtes normalisées
Analyse des verrous
Erreurs
…

En modifiant quelques directives de configuration de PostgreSQL, on peut tracer l’ensemble de l’activité du serveur des journaux applicatifs (logs). pgBadger est conçu pour analyser ces fichiers de logs et identifier rapidement les événements problématiques, ou simplement surveiller l’état général du système. Une bibliothèque javascript offre l’accès à des graphiques dans lesquels il est possible de zoomer pour un meilleur niveau de détails.

Pour voir un exemple de rapport généré par pgBadger, vous pouvez consulter la page d’exemple sur le site du projet.

Installation¶

Pré-requis : perl doit être présent sur le serveur

Il est possible d’installer pgBadger à partir des dépôts PGDG avec les commandes habituelles du système :

yum install pgbadger
dnf install pgbadger 
apt-get install pgbadger   # Debian, Ubuntu

Pour installer la dernière version, si elle n'est pas présente dans les dépôts, il est possible de télécharger l’archive au format tar.gz présente sur le site https://github.com/darold/pgbadger/releases

L'installation est alors classique :

```bash
tar xzf pgbadger-X.X.tar.gz
cd pgbadger-X.X/
perl Makefile.PL
make
sudo make install

À noter qu’il n’est pas nécessaire d’installer de paquets, le script pgbadger peut être utilisé directement depuis l’archive.

Configuration de PostgreSQL¶

Pour pouvoir utiliser pgBadger, vous devez modifier certaines directives de configuration dans le fichier postgresql.conf :

log_connections = on : Ce paramètre permet de tracer les connexions. Il est ainsi possible de savoir qui se connecte à quelle base et à partir de quelle machine.
log_disconnections = on : Ce paramètre permet de tracer les
déconnexions. En plus des informations utilisateur, base, machine, cela permet d’obtenir la durée des sessions. Ceci est très utile, surtout si on cherche à savoir si un pooler de connexions est conseillé.
log_checkpoints = on : Ce paramètre permet de remonter des informations à propos de l’activité des CHECKPOINT. Il est intéressant de le passer à on pour connaître le comportement du checkpointer vis-à-vis des checkpoints, son temps d’exécution, le nombre de pages écrites sur disque, etc.
log_lock_waits = on : Ce paramètre permet de tracer les informations à propos d’une requête ayant attendu l’obtention d’un verrou pendant une période plus longue que deadlock_timeout. Il peut être intéressant de l’activer pour diagnostiquer des comportements anormaux de l’applicatif, ou réagir en cas de blocage qui ne soit pas une situation de verrou inter-bloquants.
log_temp_files = 0 : Ce paramètre permet de tracer la création de fichiers temporaires d’une taille supérieure à la valeur indiquée. 0 permet donc de tracer tous les fichiers temporaires créés. Il est très intéressant de l’activer en production afin de déterminer si la valeur positionnée pour work_mem doit être augmentée (si cela est encore possible) lorsque de nombreux fichiers temporaires sont créés.
log_autovacuum_min_duration = 0 : Ce paramètre permet de tracer l’activité du processus autovacuum quand son exécution dépasse la durée indiquée (en millisecondes). En le configurant à 0, il est possible de savoir quelles tables sont traitées avec les opérations de VACUUM et d’ ANALYZE.
log_min_duration_statement = 0 : Ce paramètre permet de tracer les requêtes dont le temps d’exécution dépasse la durée indiquée (en millisecondes). Il peut être intéressant de tracer les requêtes lentes en production afin de les remonter aux développeurs pour optimisation ou pour tenter de déterminer la cause et le moment d’un ralentissement global du système. Il faut être prudent sur la valeur de ce paramètre, une valeur trop faible peut produire un important volume de logs et impacter le serveur. La valeur 0 permet de logger toutes les requêtes.
lc_messages = 'C' : Cette configuration permet d’avoir les traces en anglais. Cela facilite les recherches sur internet, les demandes d’aide sur les listes de discussion et les forums web, mais surtout, cela permet d’utiliser les outils d’analyse des journaux applicatifs. Ce genre d’outils ne gère que les traces en anglais.
log_line_prefix = '%t [%p]: db=%d,user=%u,app=%a,client=%h ' : Ce paramètre permet d’ajouter un préfixe à tout message tracé dans les journaux applicatifs. Ce préfixe permet de connaître la base de données, l’utilisateur, et un grand nombre d’autres informations intéressantes. Cette configuration est suffisante pour pouvoir utiliser pgBadger sur les traces. Il peut être intéressant d’ajouter la trace du nom de l’application. Cela permettrait de savoir d’où viennent les requêtes.
log_recovery_conflict_waits = on : trace les conflits de réplication avec un secondaire.

Pour la gestion des traces par syslog, le log_line_prefix est plus simple car l’horodatage, le numéro de processus (PID) et le numéro de transaction sont déjà présents :

log_line_prefix = 'db=%d,user=%u,app=%a,client=%h '

Si log_destination a été modifié, il faut redémarrer le serveur PostgreSQL. Dans le cas contraire, un simple rechargement de la configuration suffit.

Génération du rapport¶

pgbadger sert à analyser les logs produits par Postgres. Dans la plupart des cas, il est capable de détecter automatiquement le format du fichier de trace.

Cependant quelques options peuvent être utiles :

-j | –jobs number : permet d’indiquer le nombre de CPU à utiliser. Cette option peut accélérer grandement la génération du rapport lorsque les logs sont volumineux. Attention, cela peut entraîner une charge importante.
-O | –outdir path : Répertoire de destination, par défaut pgbadger produit un fichier html out.html dans le répertoire courant.
-p | –prefix string : Valeur du paramètre log_line_prefix.

./pgbadger --prefix '%t [%p]: [%l-1] db=%d,user=%u,app=%a,client=%h ' /var/lib/pgsql/15/data/log/*.log
[========================>] Parsed 53459 bytes of 53459 (100.00%), queries: 255, events: 6
LOG: Ok, generating html report...

Si le volume est trop important il est préférable de lancer la génération sur une autre machine, il est également possible d’utiliser l’option -j pour qu’il utilise plusieurs cœurs et accélérer le traitement.

Note : pgBadger sait également analyser les logs de PgBouncer, les deux type de log (PostgreSQL et PgBouncer) peuvent d’ailleurs être utilisés au sein d’un même rapport pour corréler les informations provenant des deux applications.

Voir la documentation de pgBadger sur son site web.