Live Health Banner : définition précise de chaque indicateur temps réel

Le Live Health Banner : un instantané indépendant des snapshots

Contrairement au reste du rapport PWR (basé sur la comparaison de deux snapshots historisés), le Live Health Banner affiche l'état de la base à l'instant présent, recalculé à chaque rafraîchissement depuis pg_stat_database, pg_stat_activity et pg_settings via l'endpoint /api/kpi/live. C'est le premier bloc à regarder pour savoir si la base va bien maintenant, avant même de lancer une comparaison de snapshots.

En haut du bandeau, un score de santé global (Health Score, 0 à 100) résume l'état de 5 sous-métriques pondérées : Load (30%), Blocking / sessions bloquées (25%), Connections Used (20%), P95 Latency (15%) et Cache Hit (10%). Chaque sous-métrique reçoit désormais un sous-score continu de 0 à 100, obtenu par interpolation linéaire entre son seuil « vert » (100 points) et son seuil « rouge » (0 point) détaillés plus bas pour chaque indicateur — deux valeurs proches mais situées de part et d'autre d'un même seuil (ex. une P95 à 19 ms contre 21 ms) produisent ainsi des sous-scores voisins, au lieu de sauter brutalement d'un palier à l'autre comme avec un simple classement vert/orange/rouge. Les sous-scores sont ensuite combinés selon leur poids. Si une métrique est indisponible (ex. p95 non calculable faute de requête active), elle est simplement exclue et les poids restants sont proportionnellement réajustés, pour que le score reste représentatif même avec des données partielles.

Le score obtenu est ensuite traduit en un badge de sévérité : SAIN (score ≥ 80, vert, "la base de données est en bonne santé"), WARNING (60 à 79, orange, "attention requise") ou CRITIQUE (< 60, rouge, "intervention urgente"). Sur la capture ci-dessous, le score est de 45/100 (CRITIQUE), tiré vers le bas par une P95 Latency de 12958 ms et de nombreuses requêtes actives dépassant 10 secondes.

Load (Sessions actives / CPU limit)

Cet indicateur rapporte le nombre de sessions actives en ce moment (active_sessions, c'est-à-dire les connexions dont l'état pg_stat_activity est 'active') à une limite de référence appelée CPU limit dans l'interface : concrètement la valeur du paramètre PostgreSQL max_worker_processes, utilisée comme plafond approximatif de parallélisme que l'instance peut soutenir sans saturer ses processeurs.

Le ratio obtenu (sessions actives ÷ CPU limit) est affiché en "x" (ex. 7.00x signifie 7 fois la limite de référence). Pour l'affichage du badge, il passe au rouge au-delà de 1.2x, à l'orange entre 0.8x et 1.2x, et reste vert en dessous de 0.8x ; pour le Health Score, ces deux mêmes bornes (vert 0.8x, rouge 1.2x) servent de repères à une interpolation continue, si bien qu'un ratio de 1.0x pèse moins lourd qu'un ratio de 1.2x plutôt que d'être classé de la même façon tant qu'il reste sous 1.2x. Sur l'exemple (56 sessions actives / limite 8), le ratio de 7.00x, très au-delà du seuil rouge, explique à lui seul une grande partie du score CRITIQUE global : la base traite bien plus de sessions actives en parallèle que ce que sa configuration est censée absorber efficacement.

Connections Used

Ce pourcentage mesure la pression sur le pool de connexions clientes : nombre de connexions clientes actuelles (client_conn, en excluant les processus internes comme autovacuum ou le wal writer) rapporté à max_connections, le plafond configuré côté PostgreSQL (client_conn_used_pct dans l'API).

Les seuils de couleur sont : rouge au-dessus de 90%, orange entre 70% et 90%, vert en dessous de 70%. Ces mêmes deux bornes (vert 70%, rouge 90%) servent aussi de repères à l'interpolation continue utilisée pour le sous-score entrant dans le Health Score. Sur l'exemple, 54% (54 clients / max 100) reste dans la zone verte — la pression sur ce point précis n'est donc pas la cause du problème observé par ailleurs.

P95 Latency

Le P95 Latency instantané est le 95e centile du temps déjà écoulé (en millisecondes) pour les requêtes actuellement actives (query_start jusqu'à maintenant) — à ne pas confondre avec un temps de réponse total une fois la requête terminée. Il répond à la question : parmi les requêtes en cours en ce moment, 95% d'entre elles tournent depuis moins de combien de temps ?

Seuils : rouge au-dessus de 100 ms, orange entre 20 et 100 ms, vert en dessous de 20 ms — ces deux bornes (vert 20 ms, rouge 100 ms) servent également de repères à l'interpolation continue utilisée pour le sous-score P95 entrant dans le Health Score. Sur l'exemple, 12958 ms (près de 13 secondes) est très largement au-delà du seuil rouge et pèse donc pour 0 point dans le score : cela signifie qu'une part significative des requêtes actives est déjà bloquée ou très lente au moment de la mesure, cohérent avec le grand nombre de requêtes de plus de 10 secondes vues plus bas.

Débit transactionnel (TPS)

Le débit transactionnel affiche le nombre de transactions par seconde (tx/s) actuellement traitées par l'instance, ainsi qu'un mini-graphique (sparkline) montrant sa tendance récente. Il ne participe pas au calcul du Health Score : c'est un indicateur de contexte, pas de sévérité.

Un TPS qui s'effondre pendant qu'un incident est par ailleurs signalé (P95 élevé, requêtes lentes nombreuses) confirme souvent que les requêtes lentes bloquent le débit global plutôt que de simplement ralentir isolément — c'est un des premiers graphiques à croiser avec la répartition des requêtes lentes.

Taux d'erreur transactionnel

Ce pourcentage est calculé à partir des compteurs cumulatifs xact_commit et xact_rollback de pg_stat_database : c'est la part des transactions qui se terminent par un ROLLBACK plutôt qu'un COMMIT sur la fenêtre glissante récente, avec son propre historique en sparkline.

Ce n'est pas une mesure d'erreurs applicatives au sens large (ex. contraintes violées côté client avant même d'atteindre la base), mais un indicateur de la proportion de transactions annulées côté PostgreSQL. Un taux élevé et soudain accompagne souvent des conflits de verrous, des deadlocks résolus par rollback automatique, ou des transactions annulées explicitement par l'application suite à des timeouts.

Sessions bloquées (Blocking)

Cet indicateur compte les sessions actuellement en attente d'un verrou détenu par une autre transaction (wait_event_type = 'Lock' dans pg_stat_activity) — affiché sous la forme "N session(s) bloquée(s)".

Seuils du badge : rouge au-delà de 5 sessions bloquées, orange dès 1, vert à 0. Pour le Health Score, le sous-score interpole en continu entre 0 session (100 points) et 5 sessions ou plus (0 point) : par exemple 1 session bloquée retire déjà 20 points, 3 sessions en retirent 60, sans attendre le palier des 5. C'est l'une des métriques les plus lourdement pondérées dans le Health Score (25%) car des sessions bloquées ont un effet de contagion immédiat : elles retiennent elles-mêmes des ressources et peuvent en bloquer d'autres en cascade.

Répartition des Wait Events

Ce bloc décompose, au même instant, toutes les sessions actives par type d'attente (wait_event_type de pg_stat_activity) : CPU (aucun wait_event_type renseigné — la session utilise réellement le processeur), IO (attente disque), Lock (attente d'un verrou applicatif), LWLock (verrou interne léger de PostgreSQL), BufferPin, Network et Extension. Le total affiché est la somme de ces sept catégories, c'est-à-dire le nombre de sessions actives au total à cet instant.

Sur l'exemple (56 sessions : CPU 10, IO 45, LWLock 1), la très large majorité des sessions actives attend sur de l'IO — un signal fort pour orienter le diagnostic vers un goulot d'étranglement disque/cache plutôt que vers un simple pic de calcul CPU. Cette répartition ne participe pas directement au Health Score, mais explique la cause probable des sous-métriques Load et P95 déjà dégradées.

Cache Hit

Le cache hit ratio est la part des lectures de blocs servies depuis le cache mémoire (shared_buffers, via blks_hit de pg_stat_database) plutôt que depuis le disque (blks_read) : 100 × blks_hit ÷ (blks_hit + blks_read).

Contrairement aux autres jauges, ses seuils sont inversés (une valeur haute est bonne) : vert à partir de 95%, orange entre 90% et 95%, rouge en dessous de 90%. Ces mêmes bornes (vert 95%, rouge 90%) alimentent aussi une interpolation continue pour le sous-score Cache Hit du Health Score, dans le sens inverse des autres métriques (plus le ratio est élevé, plus le sous-score est haut). Sur l'exemple, 89.4% est en dessous du seuil rouge et pèse donc pour 0 point dans le score — un ratio à surveiller si la base sert habituellement au-delà de 95%.

Répartition des Requêtes Lentes (1–5s / 5–10s / >10s)

Cette barre empilée compte les requêtes actives dont le temps déjà écoulé (clock_timestamp() - query_start) dépasse 1 seconde, ventilées en trois tranches : 1–5 secondes (jaune), 5–10 secondes (orange) et plus de 10 secondes (rouge). Seules les connexions clientes sont comptées (les processus internes comme autovacuum sont exclus). Le total affiché à droite est la somme des trois tranches.

Chaque segment de la barre affiche désormais une infobulle au survol avec le libellé, le nombre exact de requêtes et son pourcentage du total. Sur l'exemple (49 requêtes lentes : 1 en 1-5s, 3 en 5-10s, 45 en plus de 10 secondes), l'écrasante majorité des requêtes lentes dépasse déjà 10 secondes — un signal de blocage ou de contention active plutôt qu'un simple ralentissement passager, cohérent avec le P95 de ~13 secondes et le score CRITIQUE du Health Score.