Daniel Allaire
90228cb55e
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
4.9 KiB
Supervision dérivée des rôles
Pour qui : celui qui ajoute un rôle à Set-OPS et se demande comment sa supervision arrive dans Icinga — et celui qui exploite et veut savoir d'où sortent les services qu'il voit.
La règle en une phrase. Un rôle déclare les sondes de sa propre supervision ; le moteur en dérive les objets Icinga, la permission d'API et les preuves. Comme
meta/flux.ymlengendre nftables et OPNsense.
Pourquoi
Le 2026-09-09, mesure du dépôt sur lui-même :
au 2026-09-09 :
39 rôles déclarent leurs flux -> nftables + OPNsense, dérivés
32 déclarent leur empreinte -> ressources des VM, dérivées
32 déclarent leur authentification -> habilitations, dérivées
19 groupes déclarent `surveillance:` -> RIEN
Au 2026-09-09, les dix-neuf lignes surveillance: de docs/dependances-groupes.yml sont écrites,
versionnées, relues — et aucune n'est exécutée. Icinga surveillait deux choses :
sauvegarde et sante.
C'est la classe d'échec que ce dépôt nomme partout ailleurs, en version documentaire : la carte dit ce qui est surveillé, et personne ne surveille. Une intention écrite n'est pas une mesure.
Le contrat d'une sonde
Une sonde est un script local, déposé par le rôle qui la possède, dans
/usr/local/lib/setops/sondes/<nom>.sh (0750, root).
| sortie standard | une ligne, le message lisible par un humain |
| code de sortie | 0 OK · 1 AVERTISSEMENT · 2 CRITIQUE |
| réseau | aucun besoin : c'est le porteur qui pousse le résultat |
| durée | courte ; le porteur passe toutes les 15 min |
Le rôle qui possède la sonde la déploie lui-même : il connaît ses chemins, ses
secrets, sa vérité de terrain. Il la déclare dans meta/supervision.yml, et c'est
cette déclaration que le moteur lit.
# roles/<rôle>/meta/supervision.yml
sondes:
- nom: certificat
ttl: 5400
raison: "..."
Passif, et à durée de vie — jamais actif
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. C'est exactement ce qui a manqué à
openipmi.service : une unité en échec à chaque démarrage pendant une semaine, et
systemctl --failed à zéro partout parce qu'aucune machine n'avait redémarré.
C'est aussi ce qu'impose la vérification suit la clé : la sonde tourne là où vit la vérité, pas sur le superviseur. Un dépôt de sauvegarde chiffré côté client ne peut être jugé que par qui détient la clé.
Ce qui n'a rien à faire ici
Une métrique à seuil — durée de collecte, volume de journaux, taux d'occupation — appartient à Prometheus et Grafana. Icinga répond à une seule question : est-ce cassé ? Mélanger les deux rendrait les deux moins lisibles.
Chaque sonde vient avec son contrôle négatif
Une sonde qu'on n'a jamais vue échouer n'est pas une sonde, c'est une habitude. Dix-neuf voyants verts non éprouvés seraient un recul par rapport à deux voyants prouvés : ils rassureraient.
Toute sonde ajoutée doit donc être accompagnée de la manière de la faire échouer pour de vrai, et cette manière doit être rejouée au moins une fois, sur une machine réelle. Le CHANGELOG en porte la trace.
Et contre un état sain, tout autant. La première version de la sonde du certificat a
rendu 14 machines sur 14 en CRITIQUE — sur une PKI qui se portait très bien. Elle
utilisait openssl verify -CAfile racine, alors que nos certificats sont signés par un
intermédiaire que seul step certificate verify sait retrouver. Une alarme toujours
allumée ne vaut pas mieux qu'une alarme jamais allumée : elle apprend à ne plus regarder.
Une sonde se prouve donc deux fois — verte sur le sain, rouge sur le cassé.
Un contrôle négatif ne doit pas pouvoir abîmer
Éprouver la sonde du certificat, le 2026-09-09, a consisté à remplacer le certificat
d'hôte par un auto-signé. La sonde a bien viré au rouge — et le script de synchronisation
a propagé ce certificat vers node_exporter, dont la clé était restée l'ancienne :
failed to load X509KeyPair: tls: private key does not match public key
Un service réel est tombé pour éprouver une sonde. Le contrôle avait un rayon d'action que je ne lui avais pas donné volontairement.
La règle qui en découle : un contrôle négatif se fait sur une copie, ou sur un chemin que la sonde accepte en paramètre — jamais en substituant l'artefact que d'autres consomment. Quand c'est impossible, on le fait sur la machine la moins critique, on l'annonce, et on vérifie l'état des consommateurs après, pas seulement celui de la sonde.