[infra] Combler les angles morts de la supervision : tâches non instrumentées, sondes non affichées, front non sondé

gabriel commented

2026-09-09 08:17:19 +00:00

Member

Exigence couverte

ENF-08

Épreuve servie

EC03 · CI/CD et qualité

Charge estimée

0,5 j.h

Ce qu'on veut obtenir

La supervision est verte de bout en bout, et c'est le problème : elle est verte
sur ce qu'elle regarde, pas sur ce qui peut casser. Relevé sur la production le
09/09 :

Six des sept tâches cron ne publient aucune métrique. Seul
collecte-current.sh écrit un .prom. Si l'ETL argent, l'ETL or, le
chargement PostgreSQL, la prévision ou les recommandations s'arrêtent, rien
ne le dit.
Treize métriques probe_* sont collectées et affichées dans aucun
panneau. La disponibilité et la latence de l'API, de la forge et de
Grafana sont invisibles.
Le front n'est sondé nulle part. Les sondes visent chaque service sur son
écoute directe : elles resteraient vertes avec un Caddy arrêté, un vhost mal
routé ou un /srv/www/app vide — les trois cas où plus personne ne peut
ouvrir l'application. MLflow et MinIO ne sont pas sondés non plus.
Les sorties du produit ne sont pas monitorées. Les tables prevision,
recommandation, alerte et qualite_jour n'ont aucun panneau.
Notre API n'a aucune alerte alors que l'API source en a une.
La métrique de sauvegarde PostgreSQL porte une alerte mais aucun panneau.

Critères d'acceptation

Les sept tâches d'exploitation publient toutes une métrique textfile de
dernière tentative, dernière réussite et code de retour.
Un tableau de bord « disponibilité » montre l'état et la latence de
chaque sonde, l'âge des sauvegardes et les alertes en cours.
Le front, l'API vue à travers Caddy, MLflow et MinIO sont sondés, et une
sonde en échec se voit dans le tableau de bord.
Les prévisions, recommandations et alertes produites ont chacune un
panneau de fraîcheur et de volume.
Une alerte couvre notre API, une le front, une PostgreSQL injoignable,
une le retard de la chaîne ETL, une le retard de la prévision.
Aucun service n'écoute ailleurs que sur 127.0.0.1 après le changement.

Comment on le vérifie

Commande arrêter un conteneur sondé (docker stop ev-mlflow), attendre deux passes
Attendu la sonde passe à zéro dans le tableau de bord, l'alerte correspondante s'arme
Preuve capture du tableau de bord disponibilité, sonde rouge et horodatée

Commande curl -s 127.0.0.1:9090/api/v1/targets | grep -c '"health":"up"'
Attendu onze cibles au lieu de neuf
Preuve la sortie de la commande

Manuel d'exploitation à mettre à jour

docs/runbooks/supervision.md — tableau des sondes, tableau des alertes, et la
marche à suivre quand une tâche d'exploitation cesse de publier sa métrique.

Hors de ce ticket

Trois trous restent ouverts et sont volontairement laissés de côté à deux jours
du jury, parce que leur correctif touche l'API ou le Caddy de la forge :

l'API n'expose aucune métrique applicative (/metrics) : ni taux d'erreur
5xx ni latence par route, donc l'ENF-04 n'est mesuré en continu nulle part.
Le correctif demande une dépendance de plus (réinstallation du venv au
déploiement) et une règle Caddy pour ne pas exposer la route publiquement ;
aucune agrégation de journaux : sept fichiers dans /var/log/enervision,
lus à la main ;
les métriques HTTP par vhost de Caddy ne sont pas activées.

À reprendre en Portée/Post-jury.

Risque et retour arrière

Le rechargement de Prometheus et le redémarrage de blackbox sont sans effet sur
les services supervisés. Les tableaux de bord sont provisionnés en lecture
seule : un JSON invalide est refusé au chargement, il ne casse pas les autres.
Le point sensible est l'ajout de la publication de métriques dans les six
scripts d'exploitation : la publication est faite APRÈS la capture du code de
retour et n'en change pas la valeur, et l'échec de la publication est avalé
(|| true) — une tâche ne peut donc pas échouer à cause de sa supervision.
Retour arrière : git revert de la PR puis redéploiement --tags app,proxy.

### Exigence couverte ENF-08 ### Épreuve servie EC03 · CI/CD et qualité ### Charge estimée 0,5 j.h ### Ce qu'on veut obtenir La supervision est verte de bout en bout, et c'est le problème : elle est verte sur ce qu'elle regarde, pas sur ce qui peut casser. Relevé sur la production le 09/09 : - **Six des sept tâches cron ne publient aucune métrique.** Seul `collecte-current.sh` écrit un `.prom`. Si l'ETL argent, l'ETL or, le chargement PostgreSQL, la prévision ou les recommandations s'arrêtent, rien ne le dit. - **Treize métriques `probe_*` sont collectées et affichées dans aucun panneau.** La disponibilité et la latence de l'API, de la forge et de Grafana sont invisibles. - **Le front n'est sondé nulle part.** Les sondes visent chaque service sur son écoute directe : elles resteraient vertes avec un Caddy arrêté, un vhost mal routé ou un `/srv/www/app` vide — les trois cas où plus personne ne peut ouvrir l'application. MLflow et MinIO ne sont pas sondés non plus. - **Les sorties du produit ne sont pas monitorées.** Les tables `prevision`, `recommandation`, `alerte` et `qualite_jour` n'ont aucun panneau. - **Notre API n'a aucune alerte** alors que l'API source en a une. - La métrique de sauvegarde PostgreSQL porte une alerte mais aucun panneau. ### Critères d'acceptation - [ ] Les sept tâches d'exploitation publient toutes une métrique textfile de dernière tentative, dernière réussite et code de retour. - [ ] Un tableau de bord « disponibilité » montre l'état et la latence de chaque sonde, l'âge des sauvegardes et les alertes en cours. - [ ] Le front, l'API vue à travers Caddy, MLflow et MinIO sont sondés, et une sonde en échec se voit dans le tableau de bord. - [ ] Les prévisions, recommandations et alertes produites ont chacune un panneau de fraîcheur et de volume. - [ ] Une alerte couvre notre API, une le front, une PostgreSQL injoignable, une le retard de la chaîne ETL, une le retard de la prévision. - [ ] Aucun service n'écoute ailleurs que sur `127.0.0.1` après le changement. ### Comment on le vérifie Commande arrêter un conteneur sondé (`docker stop ev-mlflow`), attendre deux passes Attendu la sonde passe à zéro dans le tableau de bord, l'alerte correspondante s'arme Preuve capture du tableau de bord disponibilité, sonde rouge et horodatée Commande `curl -s 127.0.0.1:9090/api/v1/targets | grep -c '"health":"up"'` Attendu onze cibles au lieu de neuf Preuve la sortie de la commande ### Manuel d'exploitation à mettre à jour docs/runbooks/supervision.md — tableau des sondes, tableau des alertes, et la marche à suivre quand une tâche d'exploitation cesse de publier sa métrique. ### Hors de ce ticket Trois trous restent ouverts et sont volontairement laissés de côté à deux jours du jury, parce que leur correctif touche l'API ou le Caddy de la forge : - l'API n'expose aucune métrique applicative (`/metrics`) : ni taux d'erreur 5xx ni latence par route, donc l'ENF-04 n'est mesuré en continu nulle part. Le correctif demande une dépendance de plus (réinstallation du venv au déploiement) et une règle Caddy pour ne pas exposer la route publiquement ; - aucune agrégation de journaux : sept fichiers dans `/var/log/enervision`, lus à la main ; - les métriques HTTP par vhost de Caddy ne sont pas activées. À reprendre en `Portée/Post-jury`. ### Risque et retour arrière Le rechargement de Prometheus et le redémarrage de blackbox sont sans effet sur les services supervisés. Les tableaux de bord sont provisionnés en lecture seule : un JSON invalide est refusé au chargement, il ne casse pas les autres. Le point sensible est l'ajout de la publication de métriques dans les six scripts d'exploitation : la publication est faite APRÈS la capture du code de retour et n'en change pas la valeur, et l'échec de la publication est avalé (`|| true`) — une tâche ne peut donc pas échouer à cause de sa supervision. Retour arrière : `git revert` de la PR puis redéploiement `--tags app,proxy`.

gabriel added this to the J2 — 09/09 démontrable milestone

2026-09-09 08:17:19 +00:00

gabriel added the

labels

2026-09-09 08:17:24 +00:00

gabriel self-assigned this

2026-09-09 08:19:15 +00:00

gabriel added this to the EnerVision project