[infra] La supervision voit que l'ETL tourne, pas ce qu'il transforme

gabriel commented

2026-09-09 12:28:35 +00:00

Member

Exigence couverte : ENF-08 (Observabilité)

Épreuve servie : EC05 · Data, ETL et BI

Ce qu'on veut obtenir

Le #228 a instrumenté les sept tâches planifiées : on sait qu'une passe a tourné, quand, combien de temps, et avec quel code. Ce qu'on ne sait toujours pas, c'est ce qu'elle a fait — une passe argent qui rend 0 en n'écrivant rien ressemble en supervision à une passe qui a traité 5 040 lignes.

Deux conséquences concrètes : une journée refusée par verifier_taux_de_trous (TauxDeTrousAnormal) sort proprement et reste invisible ; et quand la chaîne décroche, le tableau de bord chaine-donnee montre la zone or en retard sans dire lequel des trois maillons — argent, or, chargement — a lâché. Le diagnostic se fait aujourd'hui en tail sur /var/log/enervision/silver.log.

Grafana ne peut pas aller chercher ces volumes : l'argent et l'or vivent dans DuckDB et MinIO, que Grafana ne lit jamais (§ 7 de docs/EXIGENCES-collectives.md). Ils doivent donc être publiés par les passes elles-mêmes, par le mécanisme textfile déjà en place dans bin/_metriques-ops.sh.

Critères d'acceptation

Chacune des trois passes (argent, or, chargement) publie à chaque exécution, en métrique ev_etl_* relevée par node-exporter, le jour traité et le nombre de lignes écrites.
Une journée refusée (taux de trous anormal) se distingue d'un échec technique : deux séries différentes, lisibles sans ouvrir le journal.
Un tableau de bord Grafana etl provisionné montre, pour les trois passes : dernière réussite, durée, lignes écrites, et le retard de chaque zone. On y lit lequel des trois maillons s'est arrêté, sans requête manuelle.
Sur une machine sans répertoire textfile (poste de dev), les trois passes rendent le même code de retour qu'aujourd'hui : rien n'est publié, aucune passe n'échoue.
tests/ci/test-supervision.sh échoue si le tableau de bord est absent, non provisionné, ou s'il référence une source de données non déclarée.

Comment on le vérifie

bash tests/ci/test-supervision.sh
pytest tests/unit/silver/ tests/unit/gold/ -v

Et sur le serveur, après une passe au quart d'heure :

curl -s 127.0.0.1:9100/metrics | grep '^ev_etl_'

Preuve à joindre : la sortie du grep, et une capture du tableau de bord etl pendant que la zone or est volontairement en retard d'un quart d'heure.

Manuel d'exploitation à mettre à jour

docs/runbooks/supervision.md (§ métriques déposées en fichier, tableau des tableaux de bord) et docs/runbooks/etl.md (§ « la passe n'a rien écrit : refus ou panne »).

Risque et retour arrière

node-exporter concatène tout le répertoire textfile : deux fichiers déclarant le même couple nom de métrique + étiquettes font échouer la collecte entière, donc emportent aussi les métriques des six autres tâches. Un fichier par passe, étiquette zone, lignes HELP et TYPE écrites à un seul endroit — c'est la règle déjà tenue par bin/_metriques-ops.sh, à ne pas contourner.

Retour arrière : retirer le tableau de bord et les fichiers ev_etl_*.prom. Aucune alerte ni aucun autre tableau ne dépend de ces séries.

**Exigence couverte** : ENF-08 (Observabilité) **Épreuve servie** : EC05 · Data, ETL et BI ## Ce qu'on veut obtenir Le #228 a instrumenté les sept tâches planifiées : on sait qu'une passe a tourné, quand, combien de temps, et avec quel code. Ce qu'on ne sait toujours pas, c'est ce qu'elle a fait — une passe argent qui rend 0 en n'écrivant rien ressemble en supervision à une passe qui a traité 5 040 lignes. Deux conséquences concrètes : une journée refusée par `verifier_taux_de_trous` (`TauxDeTrousAnormal`) sort proprement et reste invisible ; et quand la chaîne décroche, le tableau de bord `chaine-donnee` montre la zone or en retard sans dire lequel des trois maillons — argent, or, chargement — a lâché. Le diagnostic se fait aujourd'hui en `tail` sur `/var/log/enervision/silver.log`. Grafana ne peut pas aller chercher ces volumes : l'argent et l'or vivent dans DuckDB et MinIO, que Grafana ne lit jamais (§ 7 de `docs/EXIGENCES-collectives.md`). Ils doivent donc être publiés par les passes elles-mêmes, par le mécanisme textfile déjà en place dans `bin/_metriques-ops.sh`. ## Critères d'acceptation - [ ] Chacune des trois passes (argent, or, chargement) publie à chaque exécution, en métrique `ev_etl_*` relevée par node-exporter, le jour traité et le nombre de lignes écrites. - [ ] Une journée **refusée** (taux de trous anormal) se distingue d'un **échec technique** : deux séries différentes, lisibles sans ouvrir le journal. - [ ] Un tableau de bord Grafana `etl` provisionné montre, pour les trois passes : dernière réussite, durée, lignes écrites, et le retard de chaque zone. On y lit lequel des trois maillons s'est arrêté, sans requête manuelle. - [ ] Sur une machine sans répertoire textfile (poste de dev), les trois passes rendent le même code de retour qu'aujourd'hui : rien n'est publié, aucune passe n'échoue. - [ ] `tests/ci/test-supervision.sh` échoue si le tableau de bord est absent, non provisionné, ou s'il référence une source de données non déclarée. ## Comment on le vérifie ``` bash tests/ci/test-supervision.sh pytest tests/unit/silver/ tests/unit/gold/ -v ``` Et sur le serveur, après une passe au quart d'heure : ``` curl -s 127.0.0.1:9100/metrics | grep '^ev_etl_' ``` Preuve à joindre : la sortie du `grep`, et une capture du tableau de bord `etl` pendant que la zone or est volontairement en retard d'un quart d'heure. ## Manuel d'exploitation à mettre à jour `docs/runbooks/supervision.md` (§ métriques déposées en fichier, tableau des tableaux de bord) et `docs/runbooks/etl.md` (§ « la passe n'a rien écrit : refus ou panne »). ## Risque et retour arrière node-exporter **concatène** tout le répertoire textfile : deux fichiers déclarant le même couple nom de métrique + étiquettes font échouer la collecte entière, donc emportent aussi les métriques des six autres tâches. Un fichier par passe, étiquette `zone`, lignes HELP et TYPE écrites à un seul endroit — c'est la règle déjà tenue par `bin/_metriques-ops.sh`, à ne pas contourner. Retour arrière : retirer le tableau de bord et les fichiers `ev_etl_*.prom`. Aucune alerte ni aucun autre tableau ne dépend de ces séries.

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

2026-09-09 12:28:35 +00:00

gabriel self-assigned this

2026-09-09 12:28:35 +00:00

gabriel added the

labels

2026-09-09 12:28:40 +00:00