Le 14/09 à 05:16:54Z, le volume prometheus-server (pvc-015eabf4-9baa-4b40-94f5-d20541e56209, 8 Gi) subit la même vague que MinIO. Son moteur est sur pi1, mais une de ses répliques est sur pi2, saturé en mémoire. ext4 abandonne son journal : /sys/fs/ext4/sdb sur pi1 affiche errors_count=1 et ext4_journal_check_start.
Le montage est ro depuis. Pendant 27 h, Prometheus journalise write to WAL: … input/output error, sans rien enregistrer.
À 08:52Z, la sonde de vivacité le redémarre. Depuis, le conteneur est en CrashLoopBackOff (16 redémarrages à 09:40Z) : open /data/queries.active: read-only file system puis panic: Unable to create mmap-ed active query log.
Un redémarrage de conteneur ne démonte pas le volume. C'est le même mécanisme que #50.
Rendu helm template (dépendances construites dans une copie) comparé avant/après : seul le bloc affinity du Deployment prometheus-server change. strategy: Recreate est confirmé.
Pourquoi une préférence forte pour un AUTRE nœud : avec Recreate, le pod neuf est créé dès que l'ancien est terminal, parfois avant le démontage du volume. Recréé sur pi1, il pourrait réutiliser le montage de staging mort. Un autre nœud force détachement, rattachement, puis fsck -a automatique de kubelet et rejeu du journal.
Aucune suppression de pod, PVC, volume ou réplique. Aucun fsck manuel.
Les échantillons des 27 h en lecture seule n'ont jamais été écrits : ils sont perdus depuis le 14/09, pas par cette PR. Au redémarrage, Prometheus peut tronquer un segment de WAL illisible (réparation normale).
Elle ne traite pas la mémoire de pi2 : une issue dédiée suit.
Accord du fondateur : « Oui, même remède, sans perte » (2026-09-15).
## Cause (relevée pendant la clôture de tools#49)
- Le **14/09 à 05:16:54Z**, le volume `prometheus-server` (`pvc-015eabf4-9baa-4b40-94f5-d20541e56209`, 8 Gi) subit la même vague que MinIO. Son moteur est sur pi1, mais **une de ses répliques est sur pi2**, saturé en mémoire. ext4 abandonne son journal : `/sys/fs/ext4/sdb` sur pi1 affiche `errors_count=1` et `ext4_journal_check_start`.
- Le montage est **`ro`** depuis. Pendant 27 h, Prometheus journalise `write to WAL: … input/output error`, sans rien enregistrer.
- À **08:52Z**, la sonde de vivacité le redémarre. Depuis, le conteneur est en **CrashLoopBackOff** (16 redémarrages à 09:40Z) : `open /data/queries.active: read-only file system` puis `panic: Unable to create mmap-ed active query log`.
- Un redémarrage de conteneur ne démonte pas le volume. C'est le même mécanisme que #50.
## Ce que fait la PR
- `prometheus/values.yaml` → `server.affinity` :
- `nodeAffinity` **requise** `kubernetes.io/hostname NotIn [pi2]` ;
- **préférence de poids 100** pour pi3.
- Rendu `helm template` (dépendances construites dans une copie) comparé avant/après : **seul le bloc `affinity` du Deployment `prometheus-server` change**. `strategy: Recreate` est confirmé.
- **Pourquoi une préférence forte pour un AUTRE nœud** : avec `Recreate`, le pod neuf est créé dès que l'ancien est terminal, parfois avant le démontage du volume. Recréé sur pi1, il pourrait réutiliser le montage de staging mort. Un autre nœud force détachement, rattachement, puis `fsck -a` automatique de kubelet et rejeu du journal.
- Mémoire relevée (`kubectl top nodes`, 09:40Z) : pi1 76 %, **pi3 63 %**, pi2 106 %.
## Ce qu'elle ne fait pas
- Aucune suppression de pod, PVC, volume ou réplique. Aucun `fsck` manuel.
- Les échantillons des 27 h en lecture seule n'ont jamais été écrits : ils sont perdus depuis le 14/09, pas par cette PR. Au redémarrage, Prometheus peut tronquer un segment de WAL illisible (réparation normale).
- Elle ne traite pas la mémoire de pi2 : une issue dédiée suit.
Accord du fondateur : « Oui, même remède, sans perte » (2026-09-15).
Refs arcodange-org/tools#49
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Le 14/09 à 05:16Z, le volume `prometheus-server` (moteur sur pi1, une
réplique sur pi2 saturé en mémoire) a vu ext4 abandonner son journal et
remonter en lecture seule. Prometheus a échoué à écrire son WAL pendant
27 h, puis panique en boucle (« Unable to create mmap-ed active query
log ») depuis que la sonde de vivacité l'a redémarré. Un redémarrage de
conteneur ne démonte pas le volume.
Affinité requise `NotIn [pi2]` et préférence forte pour pi3 : recréé sur
un autre nœud, le volume est détaché puis rattaché, et ext4 rejoue son
journal. Sur le même nœud, le pod neuf pourrait réutiliser le montage de
staging mort.
Refs arcodange-org/tools#49
Co-Authored-By: Claude Opus 5 <[email protected]>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Cause (relevée pendant la clôture de tools#49)
prometheus-server(pvc-015eabf4-9baa-4b40-94f5-d20541e56209, 8 Gi) subit la même vague que MinIO. Son moteur est sur pi1, mais une de ses répliques est sur pi2, saturé en mémoire. ext4 abandonne son journal :/sys/fs/ext4/sdbsur pi1 afficheerrors_count=1etext4_journal_check_start.rodepuis. Pendant 27 h, Prometheus journalisewrite to WAL: … input/output error, sans rien enregistrer.open /data/queries.active: read-only file systempuispanic: Unable to create mmap-ed active query log.Ce que fait la PR
prometheus/values.yaml→server.affinity:nodeAffinityrequisekubernetes.io/hostname NotIn [pi2];helm template(dépendances construites dans une copie) comparé avant/après : seul le blocaffinitydu Deploymentprometheus-serverchange.strategy: Recreateest confirmé.Recreate, le pod neuf est créé dès que l'ancien est terminal, parfois avant le démontage du volume. Recréé sur pi1, il pourrait réutiliser le montage de staging mort. Un autre nœud force détachement, rattachement, puisfsck -aautomatique de kubelet et rejeu du journal.kubectl top nodes, 09:40Z) : pi1 76 %, pi3 63 %, pi2 106 %.Ce qu'elle ne fait pas
fsckmanuel.Accord du fondateur : « Oui, même remède, sans perte » (2026-09-15).
Refs arcodange-org/tools#49
🤖 Generated with Claude Code