History

Daniel Allaire 90228cb55e supervision : la sonde se declare dans le role, comme le flux LE CONSTAT. 39 roles declarent leurs flux, 32 leur empreinte, 32 leur authentification — tous derives. Et 19 groupes sur 19 declaraient une surveillance en prose que RIEN n executait ; Icinga en surveillait deux. La carte disait ce qui etait surveille, et personne ne surveillait. LE MECANISME. Un role declare ses sondes dans meta/supervision.yml et depose lui-meme son script dans /usr/local/lib/setops/sondes/. Le porteur client_sante les fait toutes tourner et pousse un resultat passif par sonde, sans savoir ce qu elles mesurent. serveur_icinga derive les objets Service ET le filtre de permission d API des memes declarations. Ajouter une sonde ne demande de toucher ni au porteur ni a Icinga. PREMIERE SONDE : client_pki/certificat. Heures restantes sur le certificat reellement pose, chaine verifiee, et empreinte SERVIE comparee au disque quand un service le consomme. 14/14 au tenant, 7/7 au site. QUATRE OBSTACLES, ET TROIS SONT LA MEME LECON. La sonde a rendu 14/14 en CRITIQUE sur une PKI saine : openssl verify -CAfile racine ne trouve pas l intermediaire qui signe nos certificats. step certificate verify, lui, repond VALIDE. Deployee au site, elle a rendu 5/7 : le seuil d avertissement (12 h) etait AU-DESSUS du point de renouvellement (8 h, le tiers restant). Elle criait avant que le mecanisme ne soit cense agir. Seuils ramenes a 6 h et 3 h. Un seuil se DERIVE du moment ou le mecanisme surveille agit. Une alarme toujours allumee ne vaut pas mieux qu une alarme jamais allumee : elle apprend a ne plus regarder. Une sonde se prouve DEUX FOIS, verte sur le sain et rouge sur le casse. Le filtre d API etait ecrit avant la lecture des declarations : les services auraient existe et Icinga aurait refuse leurs resultats. Et mon controle negatif a casse un service reel : substituer le certificat d hote a fait propager un cert sans sa clef vers node_exporter. Un controle negatif se fait sur une COPIE. P64 tient les deux bouts : declaree sans etre deposee, ou deposee sans etre declaree. Trois controles negatifs rejoues. make prouver : CONFORME, 64 OK, 0 echec, 0 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q		2026-09-09 21:45:49 -04:00
..
defaults	supervision : la sonde se declare dans le role, comme le flux	2026-09-09 21:45:49 -04:00
handlers	supervision : systemctl --failed entre dans Icinga (role client_sante)	2026-09-09 20:32:08 -04:00
meta	supervision : systemctl --failed entre dans Icinga (role client_sante)	2026-09-09 20:32:08 -04:00
tasks	client_sante : retrait d une garde qui ne pouvait pas se declencher	2026-09-09 21:06:08 -04:00
templates	supervision : la sonde se declare dans le role, comme le flux	2026-09-09 21:45:49 -04:00
README.md	client_sante : retrait d une garde qui ne pouvait pas se declencher	2026-09-09 21:06:08 -04:00

README.md

client_sante

Le nœud rapporte à Icinga ses unités systemd en échec, par résultat passif.

Pourquoi

Trouvé le 2026-09-09 : openipmi.service échouait à chaque démarrage sur les quatorze machines de Chezlepro depuis le 2026-09-02. systemctl --failed rendait pourtant zéro partout — non parce qu'elles allaient bien, mais parce qu'aucune n'avait redémarré depuis. Six jours et vingt heures pour la première. Il a fallu qu'un humain redémarre une machine pour que le défaut existe aux yeux de quelqu'un.

Un contrôle qui ne peut échouer qu'au démarrage ne mesure rien tant que rien ne démarre.

Et le dégât n'est pas cosmétique : une unité en échec permanent use le seul signal qui devrait alerter. Le jour où une vraie unité tombe, le compte passe de 1 à 2 et personne ne fait la différence.

Passif, et à durée de vie

Un contrôle actif ne voit pas la machine muette : si elle ne répond plus, la sonde échoue et on met ça sur le compte du réseau. Ici c'est le nœud qui parle, et le ttl de son envoi fait la fraîcheur — sans nouvelle, Icinga périme le service tout seul. Le silence alerte autant que l'échec, et le silence est précisément ce qui n'a alerté personne.

Le minuteur déclenche au démarrage (OnBootSec=2min) autant que périodiquement : les échecs de cette famille naissent au boot, et attendre le premier quart d'heure laisserait une fenêtre pendant laquelle la machine est en panne et le tableau au vert.

Tolérances

client_sante_unites_tolerees nomme les unités acceptées une par une, jamais un motif large : un filtre qui cache une unité en cache d'autres, et on ne s'en aperçoit que le jour où l'on cherche pourquoi rien n'a alerté. Le défaut est la liste vide — une unité en échec est soit un vrai problème, soit du bruit à retirer ; dans les deux cas il faut agir.

Ce dont il dépend

Un hôte serveur_icinga dans l'écosystème, le secret vault_icinga_api_depot, et le flux TCP 5665 vers lui — déclaré des deux côtés. Le côté serveur (roles/serveur_icinga/meta/flux.yml) nomme le pair serveur_debian, pas client_sante : la frontière ne résout que les rôles que les machines portent au plan, et une intégration universelle n'y figure pas puisqu'elle est dérivée. L'oubli s'est payé le 2026-09-09 — déploiement à 7/7, et cinq rapports sur sept en TimeoutError.

Le rôle n'a pas de branche « et s'il n'y a pas de supervision ». Il n'en a pas besoin : instancier ne pose une intégration universelle que si son serveur existe, donc le groupe client_sante est absent d'un écosystème sans Icinga. À la place, un assert qui peut échouer, et qui dit lequel des deux manque.