Monitoring PostgreSQL : les métriques essentielles à surveiller

Pourquoi le monitoring PostgreSQL demande une approche spécifique

PostgreSQL expose une quantité considérable de données via ses vues pg_stat_* (activity, database, statements, bgwriter...), mais ne fournit ni tableau de bord natif, ni notion de comparaison avant/après, ni score de santé consolidé : chaque vue doit être interrogée et interprétée séparément. Un monitoring efficace consiste donc à choisir un petit nombre de métriques réellement décisives, plutôt que de collecter chaque compteur disponible sans hiérarchie.

Charge CPU et parallélisme (Load)

Le nombre de sessions actives en simultané (pg_stat_activity, état 'active') rapporté à max_worker_processes donne une estimation directe de la pression sur le CPU disponible : au-delà de ce plafond, les sessions actives se disputent des ressources déjà saturées plutôt que de progresser en parallèle.

Une charge qui dépasse durablement 1x cette limite est un signal fort d'un goulot d'étranglement CPU, souvent provoqué par une ou plusieurs requêtes coûteuses plutôt que par un volume global de trafic.

IO et cache hit ratio

Le cache hit ratio (part des lectures servies depuis shared_buffers plutôt que depuis le disque, calculé à partir de blks_hit et blks_read de pg_stat_database) est l'un des indicateurs les plus parlants sur le dimensionnement mémoire d'une instance : un ratio qui descend sous 95% mérite d'être surveillé, sous 90% il devient franchement préoccupant sur la plupart des workloads.

Une chute soudaine du cache hit ratio accompagnée d'une hausse des requêtes lentes pointe généralement vers une requête précise qui lit un volume de données inhabituel, plutôt que vers une dégradation globale et diffuse.

Connexions et pool de connexions

Le nombre de connexions clientes actives rapporté à max_connections signale une saturation du pool avant qu'elle ne se traduise par des erreurs de connexion refusée côté application. Ce n'est pas seulement une question de capacité : un pool proche de la saturation augmente aussi la latence de toutes les requêtes, y compris celles qui seraient rapides en temps normal.

Verrous (locks) et sessions bloquées

Une session en attente d'un verrou détenu par une autre transaction (wait_event_type = 'Lock' dans pg_stat_activity) n'est pas lente : elle est bloquée. La distinction compte, car la correction est totalement différente — optimiser une requête ne résout rien si le vrai problème est une transaction qui retient un verrou trop longtemps.

Les sessions bloquées ont un effet de contagion immédiat : chacune peut elle-même retenir des ressources et bloquer d'autres sessions en cascade, ce qui en fait l'une des métriques à surveiller en priorité absolue.

Un score de santé unique : le Health Score

Multiplier les graphiques est utile pour l'investigation détaillée, mais peu pratique pour un coup d'œil quotidien. PWR combine Load, sessions bloquées, connexions utilisées, latence P95 et cache hit ratio en un score unique de 0 à 100, avec une pondération qui reflète leur impact réel (les sessions bloquées, par exemple, pèsent plus lourd que le taux de cache, car leur effet de contagion est plus immédiat).

Ce score est ensuite traduit en un badge simple (Sain, Warning, Critique) qui permet de savoir en une seconde si une base nécessite une attention immédiate, avant même d'ouvrir le détail des métriques individuelles.

PostgreSQL face à AWR Oracle : ce qui change

Oracle propose depuis longtemps l'Automatic Workload Repository (AWR), un rapport de référence basé sur la comparaison de deux snapshots. PostgreSQL n'a jamais eu d'équivalent officiel : chaque équipe doit assembler elle-même ses propres requêtes de diagnostic à partir des vues pg_stat_*.

PWR reprend la logique éprouvée d'AWR (snapshots comparables, cause racine plutôt que collecte brute) tout en y ajoutant ce qu'Oracle ne propose pas nativement : un moteur de santé qui tourne en continu sans attendre qu'un rapport soit généré manuellement, des transitions d'état tracées automatiquement, et des alertes envoyées dès qu'un incident se confirme.