[infra] Tableaux de bord Grafana métier et enrichissement de la supervision

gabriel commented

2026-09-03 11:18:56 +00:00

Member

Exigence couverte

ENF-08

Épreuve servie

EC03 · CI/CD et qualité

Charge estimée

1 j.h, à étaler : chaque tableau de bord se fait quand sa source existe.

Ce qu'on veut obtenir

Le ticket #31 a posé Prometheus, Grafana, node-exporter, cAdvisor et
postgres-exporter, avec quatre tableaux de bord (socle, hote, conteneurs,
postgresql). Trois autres tableaux de bord ont un contenu déjà connu mais une
source qui n'existe pas encore. Ce ticket les fixe à l'avance et les branche au
fil de la livraison de leurs tickets producteurs.

Critères d'acceptation

Tableau de bord chaine-donnee : fraîcheur par site, volume ingéré par heure en zone bronze, complétude par site, part de points imputés par régime. Chaque panneau renvoie une valeur dès que #33 et #34 écrivent en base.
Tableau de bord modele : erreur glissante prévu/réel, dérive des variables d'entrée, latence et volume d'inférence, version du modèle promu. Chaque panneau renvoie une valeur dès que #37 journalise ses prédictions.
Tableau de bord sauvegardes : âge du dernier vidage PostgreSQL, dernier état, taille du dump, âge de la dernière copie hors-serveur. Alimenté par le collecteur textfile de node-exporter.
GRANT pg_monitor TO grafana posé par une migration db/migrations/ : pg_stat_replication et le texte des requêtes des autres sessions cessent d'être masqués dans le tableau de bord postgresql.
Chaque tableau de bord n'est ajouté au provisioning que lorsque sa source est en service, jamais vide en démonstration.

Comment on le vérifie

Commande bash tests/ci/test-supervision.sh, puis panneau par panneau via l'API Grafana une fois le ticket producteur livré
Attendu aucun panneau du tableau de bord concerné ne reste sur « No data »
Preuve capture de chaque tableau de bord rempli

Dépendances

chaine-donnee attend #33 (zone bronze), #34 (journal de qualité), #35 (zone or)
modele attend #36 (modèle promu) et #37 (prédictions et dérive)
sauvegardes attend #71 (copie hors-serveur)
#42 (cinq alertes) consomme ces mêmes métriques pour poser ses seuils

Suggestions, hors périmètre

blackbox_exporter : sondes HTTP sur forge., grafana., app., api
exporter GPU (DCGM) pour le Tesla T4 pendant l'entraînement (#36)
scraper les /metrics déjà exposés par MinIO, Caddy et Forgejo (trois blocs static_configs)
cAdvisor en privileged: true si les cgroups du LXC ne sont pas lisibles autrement

Manuel d'exploitation à mettre à jour

docs/runbooks/supervision.md : section « Ajouter une source ou un tableau de bord », le collecteur textfile (chemin, format), et le GRANT pg_monitor avec son REVOKE de retour arrière.

Risque et retour arrière

pg_monitor est un rôle prédéfini restreint aux statistiques : risque faible, retour arrière REVOKE pg_monitor FROM grafana. Un fichier textfile mal formé fait échouer le scrape node-exporter : le valider avec promtool check metrics avant de poser le cron.

### Exigence couverte ENF-08 ### Épreuve servie EC03 · CI/CD et qualité ### Charge estimée 1 j.h, à étaler : chaque tableau de bord se fait quand sa source existe. ### Ce qu'on veut obtenir Le ticket #31 a posé Prometheus, Grafana, node-exporter, cAdvisor et postgres-exporter, avec quatre tableaux de bord (`socle`, `hote`, `conteneurs`, `postgresql`). Trois autres tableaux de bord ont un contenu déjà connu mais une source qui n'existe pas encore. Ce ticket les fixe à l'avance et les branche au fil de la livraison de leurs tickets producteurs. ### Critères d'acceptation - [ ] Tableau de bord `chaine-donnee` : fraîcheur par site, volume ingéré par heure en zone bronze, complétude par site, part de points imputés par régime. Chaque panneau renvoie une valeur dès que #33 et #34 écrivent en base. - [ ] Tableau de bord `modele` : erreur glissante prévu/réel, dérive des variables d'entrée, latence et volume d'inférence, version du modèle promu. Chaque panneau renvoie une valeur dès que #37 journalise ses prédictions. - [ ] Tableau de bord `sauvegardes` : âge du dernier vidage PostgreSQL, dernier état, taille du dump, âge de la dernière copie hors-serveur. Alimenté par le collecteur `textfile` de node-exporter. - [ ] `GRANT pg_monitor TO grafana` posé par une migration `db/migrations/` : `pg_stat_replication` et le texte des requêtes des autres sessions cessent d'être masqués dans le tableau de bord `postgresql`. - [ ] Chaque tableau de bord n'est ajouté au provisioning que lorsque sa source est en service, jamais vide en démonstration. ### Comment on le vérifie Commande `bash tests/ci/test-supervision.sh`, puis panneau par panneau via l'API Grafana une fois le ticket producteur livré Attendu aucun panneau du tableau de bord concerné ne reste sur « No data » Preuve capture de chaque tableau de bord rempli ### Dépendances - `chaine-donnee` attend #33 (zone bronze), #34 (journal de qualité), #35 (zone or) - `modele` attend #36 (modèle promu) et #37 (prédictions et dérive) - `sauvegardes` attend #71 (copie hors-serveur) - #42 (cinq alertes) consomme ces mêmes métriques pour poser ses seuils ### Suggestions, hors périmètre - `blackbox_exporter` : sondes HTTP sur `forge.`, `grafana.`, `app.`, `api` - exporter GPU (DCGM) pour le Tesla T4 pendant l'entraînement (#36) - scraper les `/metrics` déjà exposés par MinIO, Caddy et Forgejo (trois blocs `static_configs`) - `cAdvisor` en `privileged: true` si les cgroups du LXC ne sont pas lisibles autrement ### Manuel d'exploitation à mettre à jour `docs/runbooks/supervision.md` : section « Ajouter une source ou un tableau de bord », le collecteur `textfile` (chemin, format), et le `GRANT pg_monitor` avec son `REVOKE` de retour arrière. ### Risque et retour arrière `pg_monitor` est un rôle prédéfini restreint aux statistiques : risque faible, retour arrière `REVOKE pg_monitor FROM grafana`. Un fichier `textfile` mal formé fait échouer le scrape node-exporter : le valider avec `promtool check metrics` avant de poser le cron.

gabriel added the

labels

2026-09-03 11:19:01 +00:00

gabriel self-assigned this

2026-09-03 11:23:50 +00:00

gabriel added this to the J3 — 11/09 livraison milestone

2026-09-03 12:40:42 +00:00

gabriel added the due date 2026-09-11

2026-09-03 12:41:04 +00:00

gabriel added this to the EnerVision project

2026-09-03 15:19:36 +00:00

gabriel referenced this issue from a commit

2026-09-04 08:09:51 +00:00

docs: réaligne PRD et BACKLOG sur l'état réel de la forge

gabriel referenced this issue from a commit

2026-09-04 08:10:54 +00:00

docs: réaligne PRD et BACKLOG sur l'état réel de la forge

gabriel referenced this issue from a commit

2026-09-08 08:40:40 +00:00

infra: tableau de bord Grafana chaîne-donnée (#112)

gabriel referenced this issue

2026-09-08 08:40:52 +00:00

infra : tableau de bord Grafana chaîne-donnée (#112) #183

gabriel commented

2026-09-08 08:41:07 +00:00

Author

Member

PR #183 : tableau de bord chaine-donnee (fraîcheur, volume ingéré/h, complétude, régime d'imputation), branché sur postgres-metier maintenant que #33/#34/#35 sont closes. Vérifié en local, tous les panneaux rendent une valeur.

modele et sauvegardes restent hors de ce PR : bloqués respectivement par #36/#37 (ouverts) et #71 (ouvert, Post-jury). Sur sauvegardes, même la partie déjà livrée ne remonte rien pour l'instant : voir #172, qui est en NoData depuis le 07/09.

Autre écart relevé en creusant le ticket : le GRANT pg_monitor TO grafana est déjà appliqué en prod, mais via une tâche Ansible (roles/app/tasks/main.yml, mergée avec la pile app le 07/09) et non via une migration db/migrations/ comme le demande le critère d'acceptation. Le runbook (docs/runbooks/supervision.md, section 6) dit encore « à coordonner », ce qui est obsolète. À trancher : formaliser en migration, ou assumer l'écart et mettre le runbook à jour.

PR #183 : tableau de bord `chaine-donnee` (fraîcheur, volume ingéré/h, complétude, régime d'imputation), branché sur postgres-metier maintenant que #33/#34/#35 sont closes. Vérifié en local, tous les panneaux rendent une valeur. `modele` et `sauvegardes` restent hors de ce PR : bloqués respectivement par #36/#37 (ouverts) et #71 (ouvert, Post-jury). Sur `sauvegardes`, même la partie déjà livrée ne remonte rien pour l'instant : voir #172, qui est en NoData depuis le 07/09. Autre écart relevé en creusant le ticket : le `GRANT pg_monitor TO grafana` est déjà appliqué en prod, mais via une tâche Ansible (`roles/app/tasks/main.yml`, mergée avec la pile app le 07/09) et non via une migration `db/migrations/` comme le demande le critère d'acceptation. Le runbook (`docs/runbooks/supervision.md`, section 6) dit encore « à coordonner », ce qui est obsolète. À trancher : formaliser en migration, ou assumer l'écart et mettre le runbook à jour.