Contexte

Chaque ligne du fichier de log d’une instance PostgreSQL est catégorisée selon le format suivant :

<CATEGORIE:> <MESSAGE>

Les différentes catégories peuvent être LOG, WARNING, CRITICAL, FATAL, PANIC…

Exemples de messages :

LOG: automatic vacuum of table "mon_schema.ma_table": index scans: 1
WARNING: there is no transaction in progress
ERROR: relation "ma_table" does not exist at character 15

 

Besoin

Comment superviser efficacement la log d’une instance PostgreSQL pour être informé d’un dysfonctionnement ou d’un comportement anormal de PostgreSQL ?

Généralement, on se contente de monitorer le fichier de log et de ne remonter que les messages qui contiennent l’un des mots-clé WARNING, CRITICAL, FATAL ou PANIC, en faisant par exemple un simple script qui fait un « grep ».

Malheureusement, lorsque l’on fait cela, on se retrouve vite noyé de messages d’alerte jugés inutiles, car ils concernent des messages remontés aux utilisateurs suite à une erreur de syntaxe dans une requête, une table qui n’existe pas, un droit manquant, un mauvais format de colonne ou de donnée, etc.

Exemples de messages liés à des erreurs utilisateurs :

ERROR: invalid input syntax for integer
ERROR: column XXX must appear in the GROUP BY clause
ERROR: permission denied for relation XXX
ERROR: insert or update on table "XXX" violates foreign key constraint
ERROR: more than one row returned by a subquery used as an expression
WARNING: TIME(10) precision reduced to maximum allowed, 6

Ceci est dû à la valeur par défaut du paramètre d’instance ci-dessous dans le fichier postgresql.conf, ce qui est souvent jugé trop verbeux pour une supervision efficace lorsque l’on administre des instances en production :

log_min_messages = warning

 

Solution

L’astuce consiste donc, dans le fichier postgresql.conf, à modifier la valeur de ce paramètre pour mettre :

log_min_messages=log

Ensuite, on fait un reload de la configuration PostgreSQL pour prise en compte de la modification.

Ainsi, les messages WARNING et ERROR, liés à des erreurs sur des sessions utilisateurs, ne seront plus affichés dans le fichier de log de l’instance.