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]>
Demande : « ne pas avoir le basic auth Traefik quand on est sur le Wi-Fi partagé
avec le homelab ». La réponse intuitive — une règle `ClientIP(192.168.1.0/24)` —
ne peut pas marcher, et la variante « je regarde CF-Connecting-IP » est un
contournement d'authentification. Ce commit écrit la mesure pour qu'on ne
re-découvre ni l'une ni l'autre.
Mesuré (2026-07-28, homelab) :
- `kadans.arcodange.fr` résout vers Cloudflare MÊME depuis le LAN, et redescend
par le tunnel cloudflared. L'adresse de socket vue par Traefik est donc
toujours celle d'un pod, en 10.42.x.x.
- Traefik SAIT qui est le vrai client (journal d'accès : l'IPv6 de la maison,
`2a01:cb04:dff:cf00::/64` — pas l'IPv4 qu'`ipify` injecte dans `localIp`), car
l'entrypoint `web` fait confiance aux en-têtes venant de 10.42.0.0/16.
- Mais le matcher de routeur `ClientIP()`, lui, juge la SOCKET. Prouvé par trois
routeurs temporaires vers un Service sans endpoint (503 = règle matchée,
401 = repli sur le routeur normal) : témoin 503, `ClientIP(<IPv6 maison>)` 401,
`ClientIP(10.42.0.0/16)` 503. Sondes retirées après mesure.
D'où deux pièges, écrits là où on les rencontrerait :
- `localIp@file` sur un routeur `.fr` laisserait entrer Internet entier, parce
que `10.42.0.0/16` est dans son `sourceRange` et qu'`ipAllowList` juge lui
aussi la socket. Vérifié : aucun routeur `.fr` ne le porte aujourd'hui — le
piège est latent, et les cinq endroits d'où on pourrait le recopier
(2 gabarits `.fr`, 3 values `.lab`) portent désormais l'avertissement.
- Un en-tête posé par le client ne peut pas piloter une exemption d'auth :
Cloudflare ne retire pas les en-têtes inconnus, et Traefik reste joignable en
direct sur 192.168.1.201.
Voie retenue, et pourquoi celle-là : la décision « suis-je à la maison ? » doit
être prise là où la vraie IP est native et non falsifiable, donc au bord, chez
Cloudflare. Une règle de transformation y pré-remplit l'en-tête `Authorization`
pour les IP du foyer. Traefik ne bouge pas, aucun certificat public à produire,
aucun changement DNS. Surface d'attaque ajoutée : AUCUNE — `kadans:kkadans` est
déjà en clair dans le chart de kadans, Cloudflare ne fait que le taper à notre
place. Et quand l'IP du foyer dérive, la règle cesse de matcher : le navigateur
redemande le mot de passe. Dégradation douce, pas de panne.
Le doc écrit l'action Cloudflare mot pour mot (expression, en-tête, valeur, et
l'équivalent Terraform pour `cms/cloudflare`) plutôt que de la supposer faite,
avec les deux commandes qui la vérifient — et nomme le repli si Cloudflare
refuse de modifier `Authorization` : Cloudflare Access avec une politique de
bypass, PAS un en-tête secret.
Enfin, un contre-exemple utile : le bouncer CrowdSec, lui, juge la VRAIE IP
(journal à l'appui). Son `clientTrustedIPs` contient `10.42.0.0/16` sans que ce
soit un trou — noté pour que personne ne « corrige » cette ligne en croyant y
reproduire le piège.
⚠ Aucun des réglages en cause ne vit dans ce dépôt : les valeurs Helm de
Traefik, `dynamic.yaml`/`localIp` et le Middleware crowdsec sont dans `factory`
(ansible), le tunnel et le DNS dans `cms`. Ce dépôt reçoit la mesure et les
garde-fous parce que c'est lui qui héberge les gabarits `.fr` et les
consommateurs de `localIp@file`.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01GdUCA5Uz8QyMwa2P4Pg2hK
- prometheus : cible statique kadans-worker-mac (192.168.1.103:9105, tier
laptop). Un scrape raté n'est PAS un incident : le Mac dort, up==0 raconte
la latence — ne pas alerter dessus. ⚠ réserver l'IP au routeur (DHCP).
- grafana : provider + dashboard « Kadans — jobs d'analyse » (uid
kadans-jobs-analyse) : worker en écoute / dernier poll / file pending + âge
du plus ancien (seuils 1 h / 24 h = le SLO), file par statut et publications
par issue (couleurs de STATUT sémantiques), lanes exécutées et durée moyenne
par lane. La façade, elle, arrive par les annotations de son pod
(kadans-jobs#3) — zéro config ici.
Co-Authored-By: Claude Fable 5 <[email protected]>
Aligne le dashboard « Prospection — pipeline BI missions » sur le cahier
des charges de supervision :
- jauge 0–100 pour le meilleur score d'opportunité (au lieu d'une stat)
- nouvelle stat « Offres du brief » (prospection_brief_offres)
- bar charts « Durée par étape » et « Items par étape » sur le dernier run
(prospection_step_duration_seconds / prospection_step_items)
- cadence quotidienne : refresh 30m et plage par défaut now-7d
Provisionné via le provider Grafana « prospection » (JSON inline dans
grafana/values.yaml), datasource Prometheus (${DS_PROMETHEUS}).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Grafana tourne en SQLite sur emptyDir → migration complète du schéma à chaque
démarrage de pod, > 160 s sur Raspberry Pi. La liveson (initialDelay 60 + 10×10s)
tuait Grafana en pleine migration → CrashLoop du nouveau pod à chaque rollout
(révélé par le rollout du dashboard prospection). Ajoute une startupProbe (~10 min)
et relève failureThreshold de la liveness (filet si le chart n'expose pas startupProbe).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Consomme les métriques poussées par le pipeline prospection au Pushgateway
(job=prospection, déjà scrapé). Additif — n'affecte aucun dashboard existant.
- grafana : provider + dashboard « Prospection — pipeline BI missions » inliné
(grafana.dashboards.prospection, json) — vue d'ensemble (fraîcheur/statut/durée/
erreurs/missions/score), collecte par étape (table + historique), modèle de
données (opportunités A/B, offres/entités), livraison (brief/Telegram) + panneau
Alertes actives. Inline plutôt que ConfigMap externe : grafana est déployé via un
HelmChart CRD (tool lib), l'inline évite toute hypothèse de namespace.
- prometheus : groupe d'alertes `prospection` (serverFiles.alerting_rules.yml) —
RunStale (>25h), RunFailed, StepError, NoOffers, BriefNotSent.
NB : la livraison des alertes (Alertmanager → Telegram) n'est pas câblée dans le
cluster (server.alertmanagers vide, aucun receiver) ; les règles restent visibles
dans Prometheus /alerts + le dashboard. Câblage delivery = décision séparée.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
arcodangeandClaude Fable 5.1