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.