background success stories

PostgreSQL : superviser efficacement la log de l’instance

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.