10 Commits

Include renames

Author	SHA1	Message	Date
arcodangeandClaude Opus 5	01901e5903	Vault est resté scellé onze jours en silence, et c'était le pod le plus faible du cluster ... INCIDENT Le 30/08 à 11:35, pi3 passe de 3,6 Gio de mémoire disponible à 1,7 en cinq minutes. À 11:45 node-exporter ne répond plus, à 11:48 le nœud est NotReady, et 300 s plus tard — la tolérance `node.kubernetes.io/unreachable:NoExecute` — le node-lifecycle controller supprime quatre pods, dont hashicorp-vault-0. Vault repart SCELLÉ, comme le prévoit Shamir 1/1 sans auto-unseal. Personne ne le redescelle. Pendant onze jours le VSO répond 503 « Vault is sealed » et plus aucun Secret n'est réconcilié — découvert par hasard, en enquêtant sur autre chose. Ce qui a fonctionné ce jour-là : `NoeudInjoignable` a tiré à 11:46. L'infra a parlé. Ce qui a manqué : la CONSÉQUENCE. Le nœud est revenu, les pods ont été recréés, l'alerte s'est éteinte, et personne n'a su que Vault, lui, resterait scellé. Ce n'était ni un crash ni un OOMKill : `lastState: {}` et `restartCount: 0` sur un pod vieux de 11 jours. Et le StatefulSet n'a aucune livenessProbe — seulement une readiness `exec: vault status`, dont l'échec ne redémarre rien. D'où 196 906 events Unhealthy pour zéro redémarrage. 1. L'ALERTE QUI MANQUAIT — VaultIndisponible `kube_pod_status_ready{namespace="tools", pod=~"hashicorp-vault-[0-9]+"} == 0` pendant 10 min, avec `or absent(...)` pour couvrir la disparition du pod. Pourquoi kube-state-metrics et pas `vault_core_unsealed` : Vault n'expose ses métriques que via /v1/sys/metrics, qui exige un token ou l'ouverture d'un endpoint non authentifié. Or la readinessProbe du chart est littéralement `vault status` : un Vault scellé est NotReady. kube-state-metrics est déjà scrapé, ça ne coûte rien et ça ne touche pas à la configuration de Vault. ⚠ Le sélecteur est ancré sur `[0-9]+`, et c'est une correction, pas un détail : ma première version utilisait `hashicorp-vault-.*`, qui attrape aussi les pods du Vault Secrets Operator — dont un exemplaire terminé traîne en permanence. La règle tirait donc en continu. Vérifié contre le Prometheus du cluster : avec `[0-9]+` elle ne rend que hashicorp-vault-0 et ne tire pas. 2. VAULT N'EST PLUS LE POD LE PLUS FAIBLE DU CLUSTER Mesuré avant : `priorityClassName=""`, `priority=0`, QoS `BestEffort`. Dernier servi par le scheduler, premier évincé par le kubelet. Sur 114 pods, 78 sont BestEffort — Vault était noyé dedans, alors que tout le cluster dépend de lui et qu'il exige une intervention humaine pour revenir. - PriorityClass `vault-critical` à 900000000. Sous `longhorn-critical` (1000000000) parce que Vault stocke sur un PVC : le stockage doit survivre à Vault. Au-dessus de tout le reste. - `requests: {memory: 512Mi, cpu: 100m}`. Vault consomme 175 Mio : très en dessous de sa requête, donc tout en bas de la liste d'éviction. AUCUNE LIMITE, DÉLIBÉRÉMENT. Une limite trop basse déclenche un OOMKill, et un OOMKill sur ce pod coûte un descellement manuel. Or je n'ai pas pu établir de pic mémoire fiable : les séries cAdvisor de ce cluster rendent huit valeurs contradictoires pour ce pod, jusqu'à 2,3 Gio, ce qui est invraisemblable pour un Vault en storage "file". On ne pose pas une limite sur un chiffre auquel on ne croit pas. 3. LE PDB EXISTANT : GARDÉ, MAIS SON PIÈGE EST MAINTENANT ÉCRIT `maxUnavailable: 0` sur un StatefulSet à un réplica donne ALLOWED DISRUPTIONS: 0 en permanence. Un `kubectl drain` du nœud qui héberge Vault ne se terminera donc jamais. C'est le comportement voulu — il force à traiter Vault consciemment — mais la sortie de secours (`--disable-eviction`, ou suppression manuelle du pod) n'était écrite nulle part. Elle l'est. CE QUE ÇA NE RÉSOUT PAS, ET IL FAUT LE DIRE Ni la priorité ni les requests n'empêchent la suppression par le node-lifecycle controller quand un nœud devient injoignable — c'est exactement ce qui est arrivé le 30/08, et aucun réglage de pod ne l'évite. Ce cas-là est traité par l'alerte, pas par la protection. L'auto-unseal reste écarté : décision assumée, documentée dans factory vibe/guidebooks/lab-ecosystem/secrets-and-vault.md. Le descellement restera manuel ; c'est le délai de détection qui passe de onze jours à dix minutes. ⚠ APPLICATION : le StatefulSet est en `updateStrategy: OnDelete`. Les réglages du point 2 ne prendront effet qu'à la prochaine suppression du pod — laquelle rescellera Vault. À faire au moment choisi, clé sous la main. Vérifié : `helm template` rend la PriorityClass, le PDB et un StatefulSet portant `priorityClassName: vault-critical` et les requests ; `helm lint` passe ; la requête de l'alerte testée contre le Prometheus du cluster. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-11 12:56:19 +02:00
arcodangeandClaude Opus 5	dc48d48c1b	Un veilleur hors de Prometheus, pour que son silence cesse de ressembler au bon fonctionnement (#39) ... 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]>	2026-09-07 10:55:16 +02:00
arcodangeandClaude Fable 5	347ebee1b0	feat(observabilité) — jobs d'analyse Kadans : scrape du worker LAPTOP + dashboard Grafana ... - 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]>	2026-07-24 21:17:06 +02:00
arcodangeandClaude Fable 5	6f398f4ddc	feat(alerting): 5e règle homelab — CertificatNonRenouvele (<4 h restantes) ... Les 4 premières règles n'auraient rien vu le matin du 2026-07-24 : nœuds up, traefik up… mais wildcard 24 h expiré (renouvellement en échec silencieux depuis des heures). certmanager_certificate_expiration_timestamp_seconds est déjà scrapée (vérifié live : 2 séries). Cert-manager renouvelle à ~16 h d'âge ; <4 h restantes = plusieurs cycles ratés → critical, 15 min de grâce. Co-Authored-By: Claude Fable 5 <[email protected]>	2026-07-24 10:17:18 +02:00
arcodangeandClaude Fable 5	b9626d878b	feat(alerting): groupe homelab — alerté quand (ou juste avant que) le lab tombe ... Incident 2026-07-23 : un build CI sans limites a épuisé la RAM de pi1 (0 swap), load15 >100, traefik + apiserver affamés → tout *.arcodange.lab injoignable, Gitea compris (pourtant sain sur pi2). Personne n'est prévenu : on subit. Quatre règles, livrées par la chaîne Telegram déjà en place (testée live) : - NoeudInjoignable (critical) : node-exporter muet 3 min — nœud down ou noyé. - IngressLabIndisponible (critical) : 0 replica traefik dispo, ou métrique absente (kube-state-metrics vit sur pi1) — *.arcodange.lab est HS. - NoeudPressionMemoire (warning) : <500 Mo dispo 5 min — le précurseur exact de l'incident, déclenche avant le thrash. - NoeudEnSurcharge (warning) : load15 >8 pendant 10 min. Exprs validées contre le Prometheus live (parse + match) : pendant la rédaction, IngressLabIndisponible et NoeudEnSurcharge matchaient l'incident en cours. Prometheus (pi3) et Alertmanager (pi2) survivent à la perte de pi1. Co-Authored-By: Claude Fable 5 <[email protected]>	2026-07-24 00:12:37 +02:00
arcodangeandClaude Opus 4.8	8e236230d3	fix(alerting): alerte fiable sur l'échec de la vidéo quotidienne du brief ... ProspectionBriefNotSent (pushed==0, severity info) ne couvrait que la livraison et déclenchait à tort quand l'étape brief était volontairement sautée (metrics.py émet brief_rendered=0 aussi sur skip — seul step_status{step="brief"} distingue skip(2) d'erreur(0)). Remplacé par deux règles warning, gardées contre le skip : - ProspectionBriefFailed : rendered==0 AND step_status{brief}!=2 → la PRODUCTION de la vidéo a échoué (TTS/ffmpeg/PIL ou erreur amont) ; - ProspectionBriefNotSent : pushed==0 AND rendered==1 → vidéo produite mais PAS livrée sur Telegram (token/chat_id/API). Expressions validées en live sur Prometheus (match on(job) prouvé par requête témoin, les deux exprs vides sur l'état sain du jour). En-tête du groupe mis à jour : la livraison AM→Telegram est câblée et testée. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-07-23 22:05:45 +02:00
arcodangeandClaude Opus 4.8	4005d89c0c	fix(alerting): VaultAuth Telegram exige vaultConnectionRef dans le ns tools ... VSO refuse un VaultAuth sans vaultConnectionRef dans le ns tools (« vaultConnectionRef must be set on resources in the "tools" namespace »), contrairement au ns prospection qui hérite d'une connexion par défaut. On référence la VaultConnection `default` déjà présente dans tools. Sans ça, le Secret alertmanager-telegram n'est jamais synchronisé et le pod Alertmanager reste bloqué sur le montage manquant. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-07-08 23:23:07 +02:00
arcodangeandClaude Opus 4.8	714e2bc2ab	feat(alerting): livraison Telegram des alertes via Alertmanager ... Les règles d'alerte `prospection` s'évaluaient déjà dans Prometheus mais ne notifiaient nulle part. On câble Alertmanager pour livrer les alertes sur le bot Telegram de prospection, via `telegram_configs` natif d'Alertmanager. - iac Vault : policy read-only `alertmanager-telegram` sur kvv2/data/prospection/telegram + rôle k8s `alertmanager` (SA prometheus-alertmanager, ns tools). - VSO : VaultAuth + VaultStaticSecret resynchronisent kvv2/prospection/telegram vers un Secret `alertmanager-telegram` dans le ns tools (le Secret prospection est namespace-scoped, non réutilisable). rolloutRestartTargets sur le StatefulSet Alertmanager. - prometheus values : lien server -> Alertmanager (prometheus-alertmanager:9093), route + receiver `telegram` (bot_token_file monté, chat_id inline, parse_mode HTML, send_resolved), et montage du Secret via extraSecretMounts. Additif : ni grafana ni les règles d'alerte existantes ne sont touchés. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-07-08 23:20:00 +02:00
arcodangeandClaude Opus 4.8	e6fca752a2	feat(monitoring): dashboard Grafana + règles d'alerte prospection ... 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]>	2026-07-08 19:52:29 +02:00
arcodange	a762c8f90f	deploy prometheus	2026-03-18 16:21:31 +01:00