g2/enervision

Watch

Fork 0

supervision : deux panneaux mesuraient juste et se lisaient faux (#112) #197

Merged

lenaic merged 1 commit from lenaic/112-fraicheur-lisible into develop

2026-09-08 12:09:56 +00:00

lenaic commented

2026-09-08 11:49:58 +00:00

Owner

Trouvé en regardant le tableau de bord en production. Les deux chiffres sont exacts, ce sont leurs titres qui font conclure à une panne.

« Fraîcheur par site » : 45,9 minutes sur les sept sites

Ce n'est pas l'âge de la collecte, c'est celui de la zone or, et la chaîne est horaire par construction : argent à :00, or à :17, chargement en base à :27.

collecte, vraie fraîcheur    84 secondes    mesurée à l'instant
public.mesure, dernier       10:59          46 minutes
dernier chargement en base   11:27

La valeur oscille donc entre 28 et 88 minutes selon le moment. Quelqu'un qui ouvre Grafana à 12h25 lira « 88 minutes » sous un panneau intitulé « Fraîcheur » et conclura que la collecte est morte.

« Volume ingéré par heure » : 0, puis 33, puis 302

La grille est toujours complète :

heure     lignes  avec valeur brute  avec valeur_kw
10:00        420          302             415
09:00        420           33              42
08:00        420            0               4
07:00        420          316             380

Ce qui varie n'est pas le volume collecté mais la part que la source rend exploitable. À 08 h, 416 relevés sur 420 étaient marqués critical par la source simulée. Le collecteur, lui, a écrit 7/7 objets avec charge utile à chaque minute, zéro erreur au journal.

Un creux n'est donc pas une panne de la chaîne : c'est une heure de source dégradée, et c'est précisément ce que R3 sert à rendre visible. Le titre dit maintenant « relevés exploitables », et la description porte le chiffre.

Un panneau de plus, qui ne coûte rien

ev_ops_collecte_derniere_reussite_timestamp_seconds existe dans Prometheus depuis le #42, republiée par node-exporter, et personne ne l'affichait. Elle donne la fraîcheur réelle de la collecte, en secondes, avec les seuils de l'alerte du #42 : orange à 3 minutes, rouge à 5.

Ce que ça ne change pas

Aucune requête SQL n'a bougé. Trois titres, deux descriptions, un panneau. tests/ci/test-supervision.sh reste vert, et l'uid prometheus est bien celui de la source provisionnée.

Trouvé en regardant le tableau de bord en production. **Les deux chiffres sont exacts, ce sont leurs titres qui font conclure à une panne.** ## « Fraîcheur par site » : 45,9 minutes sur les sept sites Ce n'est pas l'âge de la collecte, c'est celui de la **zone or**, et la chaîne est horaire par construction : argent à `:00`, or à `:17`, chargement en base à `:27`. ``` collecte, vraie fraîcheur 84 secondes mesurée à l'instant public.mesure, dernier 10:59 46 minutes dernier chargement en base 11:27 ``` La valeur oscille donc entre 28 et 88 minutes selon le moment. Quelqu'un qui ouvre Grafana à 12h25 lira « 88 minutes » sous un panneau intitulé « Fraîcheur » et conclura que la collecte est morte. ## « Volume ingéré par heure » : 0, puis 33, puis 302 La grille est **toujours** complète : ``` heure lignes avec valeur brute avec valeur_kw 10:00 420 302 415 09:00 420 33 42 08:00 420 0 4 07:00 420 316 380 ``` Ce qui varie n'est pas le volume collecté mais la part que la source rend exploitable. À 08 h, **416 relevés sur 420 étaient marqués `critical`** par la source simulée. Le collecteur, lui, a écrit 7/7 objets avec charge utile à chaque minute, zéro erreur au journal. Un creux n'est donc pas une panne de la chaîne : c'est une heure de source dégradée, et c'est précisément ce que R3 sert à rendre visible. Le titre dit maintenant « relevés exploitables », et la description porte le chiffre. ## Un panneau de plus, qui ne coûte rien `ev_ops_collecte_derniere_reussite_timestamp_seconds` existe dans Prometheus depuis le #42, republiée par node-exporter, et **personne ne l'affichait**. Elle donne la fraîcheur réelle de la collecte, en secondes, avec les seuils de l'alerte du #42 : orange à 3 minutes, rouge à 5. ## Ce que ça ne change pas Aucune requête SQL n'a bougé. Trois titres, deux descriptions, un panneau. `tests/ci/test-supervision.sh` reste vert, et l'`uid` `prometheus` est bien celui de la source provisionnée.

lenaic self-assigned this

2026-09-08 11:49:58 +00:00

lenaic added 1 commit

2026-09-08 11:49:59 +00:00

supervision: deux panneaux mesuraient juste et se lisaient faux (#112 )

Intégration / Tableau de bord — dépendances, tests et construction (pull_request) Successful in 40s

Details

Intégration / Contrôles statiques du dépôt (pull_request) Successful in 7s

Details

Intégration / Workflows — lint et audit de sécurité (pull_request) Successful in 17s

Details

Intégration / Python — qualité, tests et dépendances (pull_request) Successful in 5m38s

Details

6459a8f39d

Signalé en regardant le tableau de bord en production. Les deux chiffres sont
exacts, ce sont leurs titres qui font conclure à une panne.

1. « Fraîcheur par site » affichait 45,9 minutes sur les sept sites.

   Ce n'est pas l'âge de la collecte, c'est celui de la ZONE OR, et la chaîne
   est horaire par construction : argent à :00, or à :17, chargement en base à
   :27. La valeur oscille donc normalement entre 28 et 88 minutes, et un
   chiffre élevé juste avant :27 est attendu.

   Pendant ce temps la collecte est fraîche à 84 secondes, mesurée à l'instant.
   Un lecteur qui ouvre Grafana à 12h25 lit « 88 minutes » sous un panneau
   intitulé « Fraîcheur » et conclut que la collecte est morte.

2. « Volume ingéré par heure » affichait 0, puis 33, puis 302.

   La grille est TOUJOURS complète, 420 lignes par heure pour sept sites. Ce
   qui varie est la part que la source rend exploitable : le 08/09 à 08 h, 416
   relevés sur 420 étaient marqués « critical » par la source simulée. Le
   collecteur, lui, a écrit 7/7 objets avec charge utile à chaque minute, sans
   une seule erreur au journal.

   Un creux n'est donc pas une panne de la chaîne, c'est une heure de source
   dégradée — précisément ce que la règle R3 sert à rendre visible. Le titre
   dit maintenant « relevés exploitables », et la description donne le chiffre.

3. Un panneau de plus : la fraîcheur RÉELLE de la collecte.

   Elle existait déjà dans Prometheus depuis le #42,
   ev_ops_collecte_derniere_reussite_timestamp_seconds, republiée par
   node-exporter et personne ne l'affichait. Elle se compte en secondes, avec
   les seuils de l'alerte du #42 : vert, orange à 3 minutes, rouge à 5.

Aucune requête n'a changé. Ce sont trois titres, deux descriptions et un
panneau. Le banc de supervision reste vert.

gabriel requested review from gabriel

2026-09-08 11:58:25 +00:00

gabriel approved these changes

2026-09-08 12:04:01 +00:00

gabriel left a comment

Relu, rien de bloquant.

Vérifié :

JSON valide, id 5 unique, gridPos y:18 sans chevauchement (les panneaux 3 et 4 finissent à 18).
uid: prometheus correspond bien à la source provisionnée (grafana/provisioning/datasources/datasources.yml).
ev_ops_collecte_derniere_reussite_timestamp_seconds est réellement produite par services/collector/bin/collecte-current.sh et exposée par le textfile node-exporter monté dans le compose ; un seul target node scrapé, donc l'expression sans max() ne rend qu'une série et le stat ne peut pas afficher deux valeurs.
Seuils 180/300 s cohérents avec l'alerte ev_ops_collecte_arretee (> 300).
tests/ci/test-supervision.sh ne vérifie que la présence de postgres-metier dans ce fichier : toujours là, test vert.
Les nouveaux titres collent aux requêtes (le panneau 2 compte bien valeur_brute IS NOT NULL), aucune requête modifiée, aucun runbook ne cite les anciens titres.

Un détail pour plus tard, pas de quoi bloquer : la description du panneau « Fraîcheur de la ZONE OR » renvoie au « panneau à côté » alors que le nouveau stat est en pleine largeur en bas.

On merge.

Relu, rien de bloquant. Vérifié : - JSON valide, `id` 5 unique, `gridPos y:18` sans chevauchement (les panneaux 3 et 4 finissent à 18). - `uid: prometheus` correspond bien à la source provisionnée (`grafana/provisioning/datasources/datasources.yml`). - `ev_ops_collecte_derniere_reussite_timestamp_seconds` est réellement produite par `services/collector/bin/collecte-current.sh` et exposée par le textfile node-exporter monté dans le compose ; un seul target `node` scrapé, donc l'expression sans `max()` ne rend qu'une série et le stat ne peut pas afficher deux valeurs. - Seuils 180/300 s cohérents avec l'alerte `ev_ops_collecte_arretee` (> 300). - `tests/ci/test-supervision.sh` ne vérifie que la présence de `postgres-metier` dans ce fichier : toujours là, test vert. - Les nouveaux titres collent aux requêtes (le panneau 2 compte bien `valeur_brute IS NOT NULL`), aucune requête modifiée, aucun runbook ne cite les anciens titres. Un détail pour plus tard, pas de quoi bloquer : la description du panneau « Fraîcheur de la ZONE OR » renvoie au « panneau à côté » alors que le nouveau stat est en pleine largeur en bas. On merge.

lenaic merged commit 71f9f7ee5c into develop

2026-09-08 12:09:56 +00:00

lenaic deleted branch lenaic/112-fraicheur-lisible

2026-09-08 12:09:56 +00:00

lenaic referenced this pull request from a commit

2026-09-08 12:09:57 +00:00

Merge pull request 'supervision : deux panneaux mesuraient juste et se lisaient faux (#112)' (#197) from lenaic/112-fraicheur-lisible into develop