Le cluster n'avait AUCUNE collecte de journaux : la seule lecture possible
était `kubectl logs`, c'est-à-dire le tampon du kubelet, qui tourne. Mesuré
le 2026-09-07 en demandant à chaque journal jusqu'où il remonte :
kube-system/traefik pod démarré il y a 12 j — journal remontant à 10 MIN
tools/clickhouse-0 pod démarré il y a 8 j — journal remontant à 2 MIN
Les deux composants les plus bavards du cluster gardent entre deux et dix
minutes d'histoire. C'est pire que ce que l'issue supposait.
Ce lot pose Loki (binaire unique, stockage fichier sur Longhorn) et Alloy
(l'agent, un pod par nœud), et branche la source de données au Grafana qui
tourne déjà.
L'AGENT : Alloy, pas Promtail — et c'est mesuré, pas une préférence. L'index
Helm de Grafana marque le chart `promtail` `deprecated: true`, dernière
publication 2025-10-31. Alloy : 2026-08-27. On n'installe pas à neuf un agent
que l'amont a déjà rangé.
LA RÉTENTION : 30 jours, sur un débit mesuré de ~305 Mio/jour bruts pour tout
le cluster, soit 0,9 à 1,8 Gio compressés. 7 jours auraient perdu le début des
deux pannes qui motivent ce lot (kadans#1033, des SEMAINES ; tools#36, 3 jours).
LES PLAFONDS NE SONT PAS OPTIONNELS : pi2 est mesuré à 108 % de sa mémoire
allouable. Les défauts amont du chart Loki y auraient posé un memcached
réclamant 8 Gio (`chunksCache.allocatedMemory: 8192`), un second memcached, un
nginx, un DaemonSet canari et trois jeux de répliques. Chaque extinction est
nommée dans `loki/values.yaml`, avec sa raison.
⚠ La CI de ce dépôt monte une matrice CODÉE EN DUR : un chart absent de la
liste n'est jamais construit et sa PR est verte quand même (tools#32). `loki`
et `alloy` y sont ajoutés — sans ça, ce lot n'aurait aucune preuve.
Deux découvertes faites en déployant, pas en lisant :
- `admin_api_directory` est accepté par le chart mais REFUSÉ par le binaire
OSS (champ d'édition entreprise) : CrashLoopBackOff jusqu'à ce qu'on l'ôte ;
- le chart ajoute un side-car `loki-sc-rules` SANS aucune limite de
ressources — un conteneur non plafonné dans un pod plafonné annule le
plafond. Éteint (le ruler est à 0 réplique).
Closes#38🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Fable 5.1 <[email protected]>
Un CronJob toutes les 5 minutes interroge Prometheus depuis dehors et pousse
lui-même sur Telegram. Il couvre les trois morts, dont celle qui est arrivée :
répondre parfaitement en n'enregistrant rien.
Éprouvé en vrai sur le cluster : 187 s entre la panne armée et le message
accepté par Telegram, mesuré deux fois. Contre 4620 minutes de silence réel.
Ferme #36.
Co-Authored-By: Claude Opus 5 <[email protected]>
Co-authored-by: Gabriel Radureau <[email protected]>
Quatre runs d'une branche déjà mergée ont bloqué, ce matin, l'apply qu'on
attendait. Deux causes, indépendantes :
1. Les workflows tofu (minio, vault, crowdsec, plausible) s'authentifient à
Vault par un flux OIDC dont un HUMAIN doit ouvrir le lien. Déclenchés tout
seuls, ils ne peuvent qu'occuper un runner jusqu'au timeout. Ils font en
plus `apply` en `auto_approve` CONTRE LA PROD : partir sur le push d'une
branche, c'est appliquer du code que personne n'a relu. → `workflow_dispatch`
seul, ce qui écrit enfin ce qu'ils faisaient déjà.
(crowdsec et plausible passaient de toute façon par une ancre YAML, donc
leurs triggers étaient INERTES — issues 113 → 117 de kadans.)
2. `push` sur toutes les branches + `pull_request` = DEUX runs par commit dès
qu'une branche a une PR. Vérifié : runs 258/259 et 260/261 portent le même
SHA. helmcharts, qui travaille seul et mérite de rester automatique, prend
la forme éprouvée de la CI de kadans : push sur `main`, PR pour la branche.
Chaque clé de trigger porte un corps explicite : un `pull_request:` nu n'est
pas une forme éprouvée ici, et son mode d'échec est le silencieux.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
arcodangeandClaude Fable 5.1