[infra] Prometheus applique une configuration vieille de 4 jours : un montage de fichier suit l'inode, pas le chemin

lenaic commented

2026-09-08 07:42:04 +00:00

Owner

Exigence couverte

ENF-08

Épreuve servie

EC03 · CI/CD et qualité

Charge estimée

0,5 j.h

Ce qu'on veut obtenir

Prometheus tourne depuis 4 jours avec la configuration du 3 septembre. Le job blackbox est dans le fichier côté hôte, quatre fois ; le conteneur en voit zéro.

cibles Prometheus     cadvisor, node, postgres, prometheus
probe_success         0 résultat
ev-blackbox-exporter  Up 18 h, répond 200
fichier hôte          4 occurrences de blackbox
fichier vu du conteneur   0

La cause est générale, pas propre à Prometheus. prometheus.yml est monté fichier par fichier. Quand Ansible met le dépôt à jour, git ne modifie pas le fichier en place : il en écrit un neuf et le renomme, donc nouvel inode. Un montage de fichier suit l'inode, pas le chemin. Le conteneur garde l'ancien contenu tant qu'il n'est pas recréé, et rien ne le signale.

Conséquence immédiate : la cinquième alerte du #42, « latence et disponibilité de l'API », n'a aucune donnée sur laquelle se déclencher. Elle est provisionnée et muette.

Le même piège vaut pour tout montage de fichier unique de nos piles : Caddyfile, datasources.yml, relais.py, openssh-down. Le déploiement les met à jour côté hôte sans que les conteneurs les relisent.

Critères d'acceptation

probe_success rend au moins une série dans Prometheus, et la cible de l'API y figure.
Le job blackbox apparaît dans les cibles de Prometheus, à l'état up.
Un tableau de bord Grafana montre la disponibilité et la latence de l'API mock et de la nôtre.
Le rôle Ansible recrée les conteneurs dont un fichier monté a changé, ou la pile monte des répertoires plutôt que des fichiers. Un redémarrage manuel ne compte pas comme correctif.
Le manuel docs/runbooks/supervision.md dit comment reconnaître le cas : fichier à jour côté hôte, ancien côté conteneur.

Comment on le vérifie

Commande curl -s 127.0.0.1:9090/api/v1/targets | grep blackbox
Commande docker exec ev-prometheus grep -c blackbox /etc/prometheus/prometheus.yml
Preuve les deux comptes concordent, et probe_success rend une série

Manuel d'exploitation à mettre à jour

Le correctif immédiat est un docker compose up -d --force-recreate prometheus dans /opt/enervision/.repo/infra/compose/supervision. Le TSDB vit dans un volume nommé, rien n'est perdu.

Ce geste ne ferme pas le ticket : il rétablit une fois, il n'empêche pas la prochaine dérive.

Risque et retour arrière

Recréer Prometheus coupe la collecte de métriques quelques secondes. Sans effet sur les données déjà écrites.

Le risque de ne rien faire est plus grand : une pile de supervision qui affiche une configuration qu'elle n'applique pas est pire qu'une absence de supervision, parce qu'on lui fait confiance.

### Exigence couverte ENF-08 ### Épreuve servie EC03 · CI/CD et qualité ### Charge estimée 0,5 j.h ### Ce qu'on veut obtenir Prometheus tourne depuis **4 jours** avec la configuration du 3 septembre. Le job `blackbox` est dans le fichier côté hôte, quatre fois ; le conteneur en voit **zéro**. ``` cibles Prometheus cadvisor, node, postgres, prometheus probe_success 0 résultat ev-blackbox-exporter Up 18 h, répond 200 fichier hôte 4 occurrences de blackbox fichier vu du conteneur 0 ``` **La cause est générale, pas propre à Prometheus.** `prometheus.yml` est monté fichier par fichier. Quand Ansible met le dépôt à jour, git ne modifie pas le fichier en place : il en écrit un neuf et le renomme, donc **nouvel inode**. Un montage de fichier suit l'inode, pas le chemin. Le conteneur garde l'ancien contenu tant qu'il n'est pas recréé, et rien ne le signale. Conséquence immédiate : la cinquième alerte du #42, « latence et disponibilité de l'API », n'a aucune donnée sur laquelle se déclencher. Elle est provisionnée et muette. Le même piège vaut pour **tout montage de fichier unique** de nos piles : `Caddyfile`, `datasources.yml`, `relais.py`, `openssh-down`. Le déploiement les met à jour côté hôte sans que les conteneurs les relisent. ### Critères d'acceptation - [ ] `probe_success` rend au moins une série dans Prometheus, et la cible de l'API y figure. - [ ] Le job `blackbox` apparaît dans les cibles de Prometheus, à l'état `up`. - [ ] Un tableau de bord Grafana montre la disponibilité et la latence de l'API mock et de la nôtre. - [ ] Le rôle Ansible recrée les conteneurs dont un fichier monté a changé, ou la pile monte des **répertoires** plutôt que des fichiers. Un redémarrage manuel ne compte pas comme correctif. - [ ] Le manuel `docs/runbooks/supervision.md` dit comment reconnaître le cas : fichier à jour côté hôte, ancien côté conteneur. ### Comment on le vérifie Commande curl -s 127.0.0.1:9090/api/v1/targets | grep blackbox Commande docker exec ev-prometheus grep -c blackbox /etc/prometheus/prometheus.yml Preuve les deux comptes concordent, et probe_success rend une série ### Manuel d'exploitation à mettre à jour Le correctif immédiat est un `docker compose up -d --force-recreate prometheus` dans `/opt/enervision/.repo/infra/compose/supervision`. Le TSDB vit dans un volume nommé, rien n'est perdu. Ce geste ne ferme pas le ticket : il rétablit une fois, il n'empêche pas la prochaine dérive. ### Risque et retour arrière Recréer Prometheus coupe la collecte de métriques quelques secondes. Sans effet sur les données déjà écrites. Le risque de ne rien faire est plus grand : une pile de supervision qui affiche une configuration qu'elle n'applique pas est pire qu'une absence de supervision, parce qu'on lui fait confiance.

lenaic added the

labels

2026-09-08 07:42:04 +00:00

lenaic self-assigned this

2026-09-08 07:42:04 +00:00

lenaic commented

2026-09-08 07:43:03 +00:00

Author

Owner

Correctif immédiat appliqué, le ticket reste ouvert : il rétablit une fois, il n'empêche pas la prochaine dérive.

docker compose up -d --force-recreate prometheus

Avant / après

                              avant   après
blackbox vu du conteneur        0       4
cibles Prometheus               4       7
probe_success                 aucune   3 séries

Les trois sondes répondent :

http://10.105.200.45:8000/health    probe_success 1    3 ms   ← l'API source (mock)
http://127.0.0.1:3000/api/healthz   probe_success 1    2 ms   ← la forge
http://127.0.0.1:3001/api/health    probe_success 1    4 ms   ← Grafana

La cinquième alerte du #42 a enfin de quoi se déclencher.

Ce que le correctif ne fait pas, et qui appartient à ce ticket

Notre propre API n'est pas sondée. Les trois cibles ci-dessus datent d'avant le #113 : 127.0.0.1:8000 n'y figure pas, alors que c'est le service dont la latence intéresse le jury. Une ligne à ajouter dans prometheus.yml, mais elle ne servira à rien tant que le conteneur ne relit pas son fichier, ce qui est justement le sujet.

Et le piège reste entier pour les autres montages de fichier : Caddyfile, datasources.yml, relais.py, openssh-down. Le déploiement les met à jour côté hôte sans que les conteneurs les relisent. C'est déjà ce qui a coûté le 404 du tableau de bord hier : la composition de la forge datait du 1er septembre.

Les cinq critères d'acceptation restent à cocher, le quatrième en particulier : un redémarrage manuel ne compte pas comme correctif.

Correctif immédiat appliqué, le ticket reste ouvert : il rétablit une fois, il n'empêche pas la prochaine dérive. ``` docker compose up -d --force-recreate prometheus ``` ## Avant / après ``` avant après blackbox vu du conteneur 0 4 cibles Prometheus 4 7 probe_success aucune 3 séries ``` Les trois sondes répondent : ``` http://10.105.200.45:8000/health probe_success 1 3 ms ← l'API source (mock) http://127.0.0.1:3000/api/healthz probe_success 1 2 ms ← la forge http://127.0.0.1:3001/api/health probe_success 1 4 ms ← Grafana ``` La cinquième alerte du #42 a enfin de quoi se déclencher. ## Ce que le correctif ne fait pas, et qui appartient à ce ticket **Notre propre API n'est pas sondée.** Les trois cibles ci-dessus datent d'avant le #113 : `127.0.0.1:8000` n'y figure pas, alors que c'est le service dont la latence intéresse le jury. Une ligne à ajouter dans `prometheus.yml`, mais elle ne servira à rien tant que le conteneur ne relit pas son fichier, ce qui est justement le sujet. **Et le piège reste entier pour les autres montages de fichier** : `Caddyfile`, `datasources.yml`, `relais.py`, `openssh-down`. Le déploiement les met à jour côté hôte sans que les conteneurs les relisent. C'est déjà ce qui a coûté le 404 du tableau de bord hier : la composition de la forge datait du 1er septembre. Les cinq critères d'acceptation restent à cocher, le quatrième en particulier : un redémarrage manuel ne compte pas comme correctif.

lenaic referenced this issue from a commit

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

infra: les conteneurs relisent les fichiers du dépôt à chaque déploiement (#176)

lenaic referenced this issue

2026-09-08 07:47:24 +00:00

infra : les conteneurs relisent les fichiers du dépôt à chaque déploiement (#176) #177

lenaic referenced this issue

2026-09-08 07:55:36 +00:00

infra : la sauvegarde PostgreSQL redevient observable, l'alerte disait faux (#172) #178

lenaic referenced this issue from a commit

2026-09-08 08:22:22 +00:00

infra: la recréation se décide pile par pile, pas globalement (#176)

lenaic referenced this issue from a commit

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

Merge pull request 'infra : les conteneurs relisent les fichiers du dépôt à chaque déploiement (#176)' (#177) from lenaic/176-montages-fichiers into develop

lenaic referenced this issue

2026-09-08 09:31:18 +00:00

Jalon : la chaîne IA en production, prévision et recommandations en cron #188

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

2026-09-08 21:32:24 +00:00

lenaic commented

2026-09-09 09:32:35 +00:00

Author

Owner

Fermé : le défaut n'existe plus, vérifié sur le serveur plutôt que déduit.

sudo docker exec ev-prometheus md5sum /etc/prometheus/prometheus.yml
634f52bb7d96ac075c3138dca1647bb3

sudo md5sum /opt/enervision/.repo/infra/compose/supervision/prometheus/prometheus.yml
634f52bb7d96ac075c3138dca1647bb3

Même empreinte des deux côtés. La configuration servie est celle du dépôt, datée du dernier déploiement et non d'il y a quatre jours.

La cause était le montage de fichier unique, qui suit l'inode et non le chemin : un git mv laissait le conteneur sur l'ancien contenu. Le passage en montage de répertoire l'a réglé. Le #228 vient d'ajouter cinq sondes par-dessus, et Prometheus les voit — 13 cibles sur 13 en ce moment, contre 8 avant.

Fermé : le défaut n'existe plus, vérifié sur le serveur plutôt que déduit. ``` sudo docker exec ev-prometheus md5sum /etc/prometheus/prometheus.yml 634f52bb7d96ac075c3138dca1647bb3 sudo md5sum /opt/enervision/.repo/infra/compose/supervision/prometheus/prometheus.yml 634f52bb7d96ac075c3138dca1647bb3 ``` Même empreinte des deux côtés. La configuration servie est celle du dépôt, datée du dernier déploiement et non d'il y a quatre jours. La cause était le montage de fichier unique, qui suit l'inode et non le chemin : un `git mv` laissait le conteneur sur l'ancien contenu. Le passage en montage de répertoire l'a réglé. Le #228 vient d'ajouter cinq sondes par-dessus, et Prometheus les voit — 13 cibles sur 13 en ce moment, contre 8 avant.

lenaic closed this issue

2026-09-09 09:32:35 +00:00

Rows
Columns

[infra] Prometheus applique une configuration vieille de 4 jours : un montage de fichier suit l'inode, pas le chemin #176

Exigence couverte

Épreuve servie

Charge estimée

Ce qu'on veut obtenir

Critères d'acceptation

Comment on le vérifie

Manuel d'exploitation à mettre à jour

Risque et retour arrière

Avant / après

Ce que le correctif ne fait pas, et qui appartient à ce ticket