[infra] Le dépôt quotidien dans le conteneur d'archive est supervisé #235

New issue

Open

opened 2026-09-09 09:41:19 +00:00 by justine · 0 comments

justine commented

2026-09-09 09:41:19 +00:00

Member

Exigence couverte

ENF-08

Épreuve servie

EC04 · Cloud et sécurisation

Ce qu'on veut obtenir

La supervision couvre l'hôte, les conteneurs, PostgreSQL et le métier — quatre
tableaux de bord et cinq alertes. Pas un seul indicateur ne porte sur Azure. Le
jour où le #71 posera l'envoi quotidien de l'archive, il tournera sans que personne ne
sache s'il tourne : une sauvegarde hors site dont l'échec est silencieux ne vaut pas
mieux que pas de sauvegarde, et c'est exactement le défaut que le #92 a déjà rencontré
une fois — une copie planifiée à une heure où la machine était éteinte, qui n'existait
que sur le papier.

On veut une métrique, un panneau, une alerte : l'âge du dernier objet déposé dans le
conteneur archive, visible sur le tableau de bord socle, et une alerte quand il
dépasse une journée et demie.

C'est aussi le seul des cinq critères d'évaluation qui, côté cloud, n'est pas
seulement à rendre visible : il est à créer.

Critères d'acceptation

Une métrique porte l'âge en secondes du dernier objet déposé dans le
conteneur archive, exposée à Prometheus (collecteur textfile de
node-exporter, ou sonde dédiée — le choix est libre, la métrique ne l'est pas).
Une seconde métrique porte le nombre d'octets cumulés du conteneur, pour que
la croissance du §6 du plan de migration se
constate au lieu d'être extrapolée.
La sonde n'ouvre aucun flux entrant depuis Azure et n'écrit aucun secret en
clair : elle lit avec le jeton du #70, rendu comme les autres secrets sous
/etc/enervision/ en 0640 root:deploy.
Le tableau de bord socle porte un panneau « Archive cloud — âge du dernier
dépôt », provisionné au fichier et non créé à la main dans Grafana.
Une sixième alerte existe : dépôt absent depuis plus de 36 heures, avec seuil,
destinataire nommé et action écrite, dans
infra/compose/supervision/grafana/provisioning/alerting/rules.yaml.
L'échec de la sonde elle-même est visible : une sonde muette ne doit pas se
lire comme un dépôt sain. Métrique d'horodatage de dernière exécution, ou règle
sur l'absence de série.
tests/ci/test-supervision.sh compte six alertes au lieu de cinq et vérifie la
présence du panneau.

Comment on le vérifie

# Banc statique, celui qui garde déjà la pile
bash tests/ci/test-supervision.sh

# Sur le serveur, la métrique est là et bouge
curl -s http://127.0.0.1:9090/api/v1/query \
  --data-urlencode 'query=enervision_archive_cloud_age_secondes'

# L'alerte se déclenche pour de vrai : suspendre l'envoi une journée, ou
# décaler l'horodatage de la métrique, puis constater la notification dans la forge

Preuve à joindre : la capture du panneau avec une série non vide, et la notification
d'alerte reçue lors du test de déclenchement. Une alerte qu'on n'a jamais vue partir
n'est pas une alerte.

Manuel d'exploitation à mettre à jour

docs/runbooks/supervision.md — la sixième alerte : ce qu'elle veut dire, quoi
regarder en premier, et le fait qu'un jeton SAS expiré (#70) en est la cause la plus
probable avant la panne de réseau.
docs/runbooks/stockage-minio.md ou un nouveau runbook d'archive cloud, selon où le
#71 aura posé la manœuvre d'envoi.

Risque et retour arrière

Le risque est l'alerte qui ment. Si la sonde échoue en silence — jeton expiré,
az absent, réseau coupé — l'absence de métrique peut se lire comme « rien à
signaler ». C'est pourquoi le sixième critère ci-dessus n'est pas optionnel : il faut
une règle qui se déclenche sur l'absence de série, pas seulement sur une valeur
haute.

Second risque : la sonde interroge Azure à chaque intervalle de collecte. La garder
rare — une fois par heure suffit pour un dépôt quotidien — sinon on paie des
opérations de lecture pour rien et on ajoute une dépendance réseau à la supervision.

Retour arrière : retirer le fichier de règle et le panneau, rejouer
ansible-playbook site.yml --tags app. Le provisioning au fichier est idempotent,
deleteDatasources et le rechargement de Grafana font le reste.

### Exigence couverte ENF-08 ### Épreuve servie EC04 · Cloud et sécurisation ### Ce qu'on veut obtenir La supervision couvre l'hôte, les conteneurs, PostgreSQL et le métier — quatre tableaux de bord et cinq alertes. **Pas un seul indicateur ne porte sur Azure.** Le jour où le #71 posera l'envoi quotidien de l'archive, il tournera sans que personne ne sache s'il tourne : une sauvegarde hors site dont l'échec est silencieux ne vaut pas mieux que pas de sauvegarde, et c'est exactement le défaut que le #92 a déjà rencontré une fois — une copie planifiée à une heure où la machine était éteinte, qui n'existait que sur le papier. On veut une métrique, un panneau, une alerte : l'âge du dernier objet déposé dans le conteneur `archive`, visible sur le tableau de bord `socle`, et une alerte quand il dépasse une journée et demie. C'est aussi le seul des cinq critères d'évaluation qui, côté cloud, n'est pas seulement à rendre visible : il est à créer. ### Critères d'acceptation - [ ] Une métrique porte **l'âge en secondes du dernier objet déposé** dans le conteneur `archive`, exposée à Prometheus (collecteur `textfile` de node-exporter, ou sonde dédiée — le choix est libre, la métrique ne l'est pas). - [ ] Une seconde métrique porte le **nombre d'octets cumulés** du conteneur, pour que la croissance du §6 du [plan de migration](../PLAN-MIGRATION-CLOUD.md) se constate au lieu d'être extrapolée. - [ ] La sonde n'ouvre **aucun flux entrant** depuis Azure et n'écrit aucun secret en clair : elle lit avec le jeton du #70, rendu comme les autres secrets sous `/etc/enervision/` en `0640 root:deploy`. - [ ] Le tableau de bord `socle` porte un panneau « Archive cloud — âge du dernier dépôt », provisionné **au fichier** et non créé à la main dans Grafana. - [ ] Une sixième alerte existe : dépôt absent depuis plus de 36 heures, avec seuil, destinataire nommé et action écrite, dans `infra/compose/supervision/grafana/provisioning/alerting/rules.yaml`. - [ ] **L'échec de la sonde elle-même est visible** : une sonde muette ne doit pas se lire comme un dépôt sain. Métrique d'horodatage de dernière exécution, ou règle sur l'absence de série. - [ ] `tests/ci/test-supervision.sh` compte six alertes au lieu de cinq et vérifie la présence du panneau. ### Comment on le vérifie ```bash # Banc statique, celui qui garde déjà la pile bash tests/ci/test-supervision.sh # Sur le serveur, la métrique est là et bouge curl -s http://127.0.0.1:9090/api/v1/query \ --data-urlencode 'query=enervision_archive_cloud_age_secondes' # L'alerte se déclenche pour de vrai : suspendre l'envoi une journée, ou # décaler l'horodatage de la métrique, puis constater la notification dans la forge ``` Preuve à joindre : la capture du panneau avec une série non vide, et la notification d'alerte reçue lors du test de déclenchement. Une alerte qu'on n'a jamais vue partir n'est pas une alerte. ### Manuel d'exploitation à mettre à jour - `docs/runbooks/supervision.md` — la sixième alerte : ce qu'elle veut dire, quoi regarder en premier, et le fait qu'un jeton SAS expiré (#70) en est la cause la plus probable avant la panne de réseau. - `docs/runbooks/stockage-minio.md` ou un nouveau runbook d'archive cloud, selon où le #71 aura posé la manœuvre d'envoi. ### Risque et retour arrière **Le risque est l'alerte qui ment.** Si la sonde échoue en silence — jeton expiré, `az` absent, réseau coupé — l'absence de métrique peut se lire comme « rien à signaler ». C'est pourquoi le sixième critère ci-dessus n'est pas optionnel : il faut une règle qui se déclenche sur *l'absence de série*, pas seulement sur une valeur haute. Second risque : la sonde interroge Azure à chaque intervalle de collecte. La garder rare — une fois par heure suffit pour un dépôt quotidien — sinon on paie des opérations de lecture pour rien et on ajoute une dépendance réseau à la supervision. Retour arrière : retirer le fichier de règle et le panneau, rejouer `ansible-playbook site.yml --tags app`. Le provisioning au fichier est idempotent, `deleteDatasources` et le rechargement de Grafana font le reste.

justine added the

Kind/Infra

EC04

Kind/Cloud

labels

2026-09-09 09:41:19 +00:00