Set-OPS-Public/roles/client_sante/templates/setops-sante.sh.j2

162 lines
8.1 KiB
Text
Raw Normal View History

supervision : systemctl --failed entre dans Icinga (role client_sante) CE QU IL FERME. openipmi.service echouait a chaque demarrage sur les quatorze machines depuis le 2026-09-02, et systemctl --failed rendait ZERO partout : non parce qu elles allaient bien, mais parce qu aucune n avait redemarre depuis. Il a fallu qu un humain redemarre une machine pour que le defaut existe aux yeux de quelqu un. Un controle qui ne peut echouer qu au demarrage ne mesure rien tant que rien ne demarre. PASSIF, ET A DUREE DE VIE. Un controle actif ne voit pas la machine MUETTE. Ici c est le noeud qui parle, et le ttl de son envoi fait la fraicheur : sans nouvelle, Icinga perime le service tout seul. Le silence alerte autant que l echec. Le minuteur declenche AU DEMARRAGE autant que toutes les 15 min : les echecs de cette famille naissent au boot. CRITIQUE DES LA PREMIERE UNITE, jamais un seuil — une unite en echec est soit un vrai probleme soit du bruit a retirer, et un seuil ferait vivre le bruit. Les tolerances se nomment une par une, vide par defaut. CONTROLE NEGATIF. Unite factice sur obs-01, etat relu dans IcingaDB : CRITICAL, et le verdict NOMME l unite. Les treize autres OK. Apres nettoyage : 14/14 OK. UN CONFLIT EVITE. setops-sauvegardes.conf definissait les object Host ; un second fichier de controle aurait redefini les memes, et Icinga refuse un objet en double — la configuration entiere aurait ete rejetee, donc AUCUNE supervision, en voulant en ajouter. Les hotes vivent maintenant dans setops-hotes.conf, definis une fois. TROIS OBSTACLES. ${#tableau[@]} contient {# que Jinja lit comme un debut de commentaire (remede : comment_start_string en tete du gabarit). Ma premiere sonde a traduit un 403 « Missing permission: objects/query/service » en « 0 service » — encore un echec qui ecrasait permission ; l etat se lit dans IcingaDB. Et un echec apt transitoire sur mon-01, local et disparu au second essai : mesure avant conclusion. NON FAIT : le SITE n a pas recu client_sante. make prouver : CONFORME, 63 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 20:32:08 -04:00
#jinja2: comment_start_string:'{=#', comment_end_string:'#=}'
#!/bin/bash
# GENERE par Set-OPS (role client_sante). Ne pas editer a la main.
#
# (Le gabarit redefinit le delimiteur de commentaire Jinja : `${#tableau[@]}` contient
# la sequence `{#`, que Jinja lirait comme un debut de commentaire — et le rendu
# echouait sur « Missing end of comment tag ». Le shell a besoin de `${#...}` ; c'est
# donc a Jinja de s'ecarter.)
#
# CE NOEUD RAPPORTE SES UNITES EN ECHEC — parce que personne d'autre ne peut le voir.
#
# CE QUI A REVELE LE BESOIN (2026-09-09). `openipmi.service` echouait a CHAQUE demarrage
# sur les quatorze machines depuis le 2026-09-02. `systemctl --failed` rendait pourtant
# ZERO partout — non parce qu'elles allaient bien, mais parce qu'aucune n'avait REDEMARRE
# depuis. Six jours et vingt heures pour la premiere. Il a fallu qu'un humain redemarre
# une machine pour que le defaut existe aux yeux de quelqu'un.
#
# Un controle qui ne peut echouer qu'au demarrage ne mesure rien tant que rien ne demarre.
#
# POURQUOI UN RAPPORT PASSIF, ET PAS UN CONTROLE ACTIF. Un controle actif ne voit pas la
# machine MUETTE : si elle ne repond plus, la sonde echoue et on croit a un probleme de
# reseau. Ici c'est le noeud qui parle, avec un `ttl` : sans nouvelle, Icinga perime le
# service tout seul. Le silence alerte autant que l'echec — et le silence est precisement
# ce qui n'a alerte personne.
set -uo pipefail
le site surveille enfin sa fabric La supervision du site voyait ses sept VM et rien d autre. Au depart, depuis site-mon-01, les trois hyperviseurs, les neuf pattes de la frontiere et sa PROPRE passerelle par defaut rendaient tous 100 pourcent de perte au ping. 16 hotes UP sur 16 dont 9 pattes de frontiere en controle ACTIF 11 cibles Prometheus dont 3 hyperviseurs, job fabric separe LE PARTAGE. Les hyperviseurs portent node_exporter - D-48 l autorise - et exposent 1005 unites systemd avec leur etat, soit ce que la sonde sante mesurait, plus la charge et le disque. Ils n entrent PAS dans le socle : leur appliquer serveur_durci reecrirait le pare-feu, le SSH et les sysctl de la machine qui tient tout le reste. La frontiere, elle, n accueille aucun agent : controle actif, une entree par PATTE, parce qu une interface eteinte coupe une zone pendant que les autres vont bien. ON TIRE, ON NE POUSSE PAS. J avais propose du passif et il avait ete valide ; la mesure a dit non. Un hyperviseur envoie vers un routeur qui ne connait pas les reseaux du site, et sa route par defaut est GELEE (D-57). Le porteur de sante y expirait en 20 s. LE VRAI DEFAUT ETAIT UNE LISTE QUI N A PAS SUIVI. Le mecanisme de routage existait deja sur vmbr0, avec un commentaire du 2026-08-26 tenant exactement le raisonnement qu on venait de refaire. Sa liste s arretait a 10.0.34.0/24 quand le site en declare six : les zones sauvegarde et supervision sont nees, les routes n ont pas suivi. Le symptome ne ressemblait pas a une route manquante - il ressemblait a un pare-feu, puis a un probleme de reseau chez l exploitant. make routes-fabric-etat compare desormais TROIS choses : zones declarees, routes declarees dans /etc/network/interfaces, routes vivantes dans le noyau. Le cas le plus traitre est vivante mais non declaree : tout fonctionne, la supervision est verte, et la panne attend la prochaine maintenance. Eprouvee dans les deux sens. Deux defauts trouves en construisant. bifrost-2 est un nom RESERVE, pas un boitier - l underlay le disait en prose, illisible par le moteur ; il porte desormais etat: reserve. Et un service passif n existe que pour un hote qui peut POUSSER : l appartenance a un groupe sert deux choses qui ne coincident pas toujours, a qui l on deploie et de qui l on attend un rapport. Les commutateurs restent dehors, choix de l exploitant, coherent avec D-48. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-10 18:50:43 -04:00
API="{{ client_sante_icinga_url }}"
supervision : systemctl --failed entre dans Icinga (role client_sante) CE QU IL FERME. openipmi.service echouait a chaque demarrage sur les quatorze machines depuis le 2026-09-02, et systemctl --failed rendait ZERO partout : non parce qu elles allaient bien, mais parce qu aucune n avait redemarre depuis. Il a fallu qu un humain redemarre une machine pour que le defaut existe aux yeux de quelqu un. Un controle qui ne peut echouer qu au demarrage ne mesure rien tant que rien ne demarre. PASSIF, ET A DUREE DE VIE. Un controle actif ne voit pas la machine MUETTE. Ici c est le noeud qui parle, et le ttl de son envoi fait la fraicheur : sans nouvelle, Icinga perime le service tout seul. Le silence alerte autant que l echec. Le minuteur declenche AU DEMARRAGE autant que toutes les 15 min : les echecs de cette famille naissent au boot. CRITIQUE DES LA PREMIERE UNITE, jamais un seuil — une unite en echec est soit un vrai probleme soit du bruit a retirer, et un seuil ferait vivre le bruit. Les tolerances se nomment une par une, vide par defaut. CONTROLE NEGATIF. Unite factice sur obs-01, etat relu dans IcingaDB : CRITICAL, et le verdict NOMME l unite. Les treize autres OK. Apres nettoyage : 14/14 OK. UN CONFLIT EVITE. setops-sauvegardes.conf definissait les object Host ; un second fichier de controle aurait redefini les memes, et Icinga refuse un objet en double — la configuration entiere aurait ete rejetee, donc AUCUNE supervision, en voulant en ajouter. Les hotes vivent maintenant dans setops-hotes.conf, definis une fois. TROIS OBSTACLES. ${#tableau[@]} contient {# que Jinja lit comme un debut de commentaire (remede : comment_start_string en tete du gabarit). Ma premiere sonde a traduit un 403 « Missing permission: objects/query/service » en « 0 service » — encore un echec qui ecrasait permission ; l etat se lit dans IcingaDB. Et un echec apt transitoire sur mon-01, local et disparu au second essai : mesure avant conclusion. NON FAIT : le SITE n a pas recu client_sante. make prouver : CONFORME, 63 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 20:32:08 -04:00
TTL={{ client_sante_ttl_icinga }}
MOI="{{ inventory_hostname }}"
MOTDEPASSE="$(cat /etc/setops/icinga-api.pass)"
sondes : le contrat ETAIT celui de Nagios, sans le savoir Question posee : « tu connais le paquet monitoring-plugins ? » Oui — et le contrat que docs/supervision-conception.md decrivait quelques heures plus tot EST le sien, mot pour mot. Je l avais reinvente sans le nommer, alors que positionnement.md dit l inverse : adopter aux seuils, ne pas reimplementer. Le document nomme desormais l API des greffons Nagios, ajoute le code 3 (INCONNU) et la partie « | metriques » qui manquaient, et dit la consequence : un greffon standard EST une sonde valide, sans colle. Le paquet en fournit 54. On n ecrit du shell que lorsque la verite a mesurer est propre a Set-OPS. Le porteur separe maintenant texte et performance_data. ESSAYER UN VRAI GREFFON A REVELE DEUX DEFAUTS DU PORTEUR. Un envoi refuse faisait taire TOUTES les sondes suivantes : rapporter sortait en exit 1. Une sonde deposee mais non declaree supprimait le rapport des autres, sante comprise — le tableau ne devenait pas rouge, il devenait vide, et le ttl le perimait des heures plus tard sans dire pourquoi. Aucun delai de garde sur les sondes. check_disk 2.4.0-3+deb13u1 sur mon-01 tourne sans fin (etat R) quels que soient ses arguments : un greffon STANDARD, sur une machine saine, qui boucle. Sans garde il figeait le rapport entier toutes les quinze minutes. Chaque sonde tourne desormais sous timeout 20 ; au-dela on rapporte INCONNU en le disant. La lecon n est pas que les greffons standards sont mauvais : c est qu adopter un standard ne dispense pas de l eprouver, et que le porteur doit survivre a une sonde qui se comporte mal. CONSTATE AU PASSAGE, NON CORRIGE : la configuration d exemple d Icinga crie en permanence sur mon-01 — swap sur une VM sans swap, http sur un port ou rien n ecoute, apt pour un paquet. Trois alarmes qui ne peuvent que rester rouges, dans le seul endroit qui doit rester lisible. Etat : certificat 14/14, sante 14/14 au tenant ; 7/7 au site. 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 22:14:30 -04:00
# Compte des envois refuses : l'unite systemd doit finir en echec si le rapporteur n'a
# pas pu parler, sinon rien ne distingue « tout va bien » de « personne n'ecoute ».
ECHECS_RAPPORT=0
supervision : systemctl --failed entre dans Icinga (role client_sante) CE QU IL FERME. openipmi.service echouait a chaque demarrage sur les quatorze machines depuis le 2026-09-02, et systemctl --failed rendait ZERO partout : non parce qu elles allaient bien, mais parce qu aucune n avait redemarre depuis. Il a fallu qu un humain redemarre une machine pour que le defaut existe aux yeux de quelqu un. Un controle qui ne peut echouer qu au demarrage ne mesure rien tant que rien ne demarre. PASSIF, ET A DUREE DE VIE. Un controle actif ne voit pas la machine MUETTE. Ici c est le noeud qui parle, et le ttl de son envoi fait la fraicheur : sans nouvelle, Icinga perime le service tout seul. Le silence alerte autant que l echec. Le minuteur declenche AU DEMARRAGE autant que toutes les 15 min : les echecs de cette famille naissent au boot. CRITIQUE DES LA PREMIERE UNITE, jamais un seuil — une unite en echec est soit un vrai probleme soit du bruit a retirer, et un seuil ferait vivre le bruit. Les tolerances se nomment une par une, vide par defaut. CONTROLE NEGATIF. Unite factice sur obs-01, etat relu dans IcingaDB : CRITICAL, et le verdict NOMME l unite. Les treize autres OK. Apres nettoyage : 14/14 OK. UN CONFLIT EVITE. setops-sauvegardes.conf definissait les object Host ; un second fichier de controle aurait redefini les memes, et Icinga refuse un objet en double — la configuration entiere aurait ete rejetee, donc AUCUNE supervision, en voulant en ajouter. Les hotes vivent maintenant dans setops-hotes.conf, definis une fois. TROIS OBSTACLES. ${#tableau[@]} contient {# que Jinja lit comme un debut de commentaire (remede : comment_start_string en tete du gabarit). Ma premiere sonde a traduit un 403 « Missing permission: objects/query/service » en « 0 service » — encore un echec qui ecrasait permission ; l etat se lit dans IcingaDB. Et un echec apt transitoire sur mon-01, local et disparu au second essai : mesure avant conclusion. NON FAIT : le SITE n a pas recu client_sante. make prouver : CONFORME, 63 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 20:32:08 -04:00
sondes : le contrat ETAIT celui de Nagios, sans le savoir Question posee : « tu connais le paquet monitoring-plugins ? » Oui — et le contrat que docs/supervision-conception.md decrivait quelques heures plus tot EST le sien, mot pour mot. Je l avais reinvente sans le nommer, alors que positionnement.md dit l inverse : adopter aux seuils, ne pas reimplementer. Le document nomme desormais l API des greffons Nagios, ajoute le code 3 (INCONNU) et la partie « | metriques » qui manquaient, et dit la consequence : un greffon standard EST une sonde valide, sans colle. Le paquet en fournit 54. On n ecrit du shell que lorsque la verite a mesurer est propre a Set-OPS. Le porteur separe maintenant texte et performance_data. ESSAYER UN VRAI GREFFON A REVELE DEUX DEFAUTS DU PORTEUR. Un envoi refuse faisait taire TOUTES les sondes suivantes : rapporter sortait en exit 1. Une sonde deposee mais non declaree supprimait le rapport des autres, sante comprise — le tableau ne devenait pas rouge, il devenait vide, et le ttl le perimait des heures plus tard sans dire pourquoi. Aucun delai de garde sur les sondes. check_disk 2.4.0-3+deb13u1 sur mon-01 tourne sans fin (etat R) quels que soient ses arguments : un greffon STANDARD, sur une machine saine, qui boucle. Sans garde il figeait le rapport entier toutes les quinze minutes. Chaque sonde tourne desormais sous timeout 20 ; au-dela on rapporte INCONNU en le disant. La lecon n est pas que les greffons standards sont mauvais : c est qu adopter un standard ne dispense pas de l eprouver, et que le porteur doit survivre a une sonde qui se comporte mal. CONSTATE AU PASSAGE, NON CORRIGE : la configuration d exemple d Icinga crie en permanence sur mon-01 — swap sur une VM sans swap, http sur un port ou rien n ecoute, apt pour un paquet. Trois alarmes qui ne peuvent que rester rouges, dans le seul endroit qui doit rester lisible. Etat : certificat 14/14, sante 14/14 au tenant ; 7/7 au site. 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 22:14:30 -04:00
rapporter() { # $1=service $2=code $3=texte[|metriques] $4=ttl
supervision : systemctl --failed entre dans Icinga (role client_sante) CE QU IL FERME. openipmi.service echouait a chaque demarrage sur les quatorze machines depuis le 2026-09-02, et systemctl --failed rendait ZERO partout : non parce qu elles allaient bien, mais parce qu aucune n avait redemarre depuis. Il a fallu qu un humain redemarre une machine pour que le defaut existe aux yeux de quelqu un. Un controle qui ne peut echouer qu au demarrage ne mesure rien tant que rien ne demarre. PASSIF, ET A DUREE DE VIE. Un controle actif ne voit pas la machine MUETTE. Ici c est le noeud qui parle, et le ttl de son envoi fait la fraicheur : sans nouvelle, Icinga perime le service tout seul. Le silence alerte autant que l echec. Le minuteur declenche AU DEMARRAGE autant que toutes les 15 min : les echecs de cette famille naissent au boot. CRITIQUE DES LA PREMIERE UNITE, jamais un seuil — une unite en echec est soit un vrai probleme soit du bruit a retirer, et un seuil ferait vivre le bruit. Les tolerances se nomment une par une, vide par defaut. CONTROLE NEGATIF. Unite factice sur obs-01, etat relu dans IcingaDB : CRITICAL, et le verdict NOMME l unite. Les treize autres OK. Apres nettoyage : 14/14 OK. UN CONFLIT EVITE. setops-sauvegardes.conf definissait les object Host ; un second fichier de controle aurait redefini les memes, et Icinga refuse un objet en double — la configuration entiere aurait ete rejetee, donc AUCUNE supervision, en voulant en ajouter. Les hotes vivent maintenant dans setops-hotes.conf, definis une fois. TROIS OBSTACLES. ${#tableau[@]} contient {# que Jinja lit comme un debut de commentaire (remede : comment_start_string en tete du gabarit). Ma premiere sonde a traduit un 403 « Missing permission: objects/query/service » en « 0 service » — encore un echec qui ecrasait permission ; l etat se lit dans IcingaDB. Et un echec apt transitoire sur mon-01, local et disparu au second essai : mesure avant conclusion. NON FAIT : le SITE n a pas recu client_sante. make prouver : CONFORME, 63 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 20:32:08 -04:00
local charge reponse
sondes : le contrat ETAIT celui de Nagios, sans le savoir Question posee : « tu connais le paquet monitoring-plugins ? » Oui — et le contrat que docs/supervision-conception.md decrivait quelques heures plus tot EST le sien, mot pour mot. Je l avais reinvente sans le nommer, alors que positionnement.md dit l inverse : adopter aux seuils, ne pas reimplementer. Le document nomme desormais l API des greffons Nagios, ajoute le code 3 (INCONNU) et la partie « | metriques » qui manquaient, et dit la consequence : un greffon standard EST une sonde valide, sans colle. Le paquet en fournit 54. On n ecrit du shell que lorsque la verite a mesurer est propre a Set-OPS. Le porteur separe maintenant texte et performance_data. ESSAYER UN VRAI GREFFON A REVELE DEUX DEFAUTS DU PORTEUR. Un envoi refuse faisait taire TOUTES les sondes suivantes : rapporter sortait en exit 1. Une sonde deposee mais non declaree supprimait le rapport des autres, sante comprise — le tableau ne devenait pas rouge, il devenait vide, et le ttl le perimait des heures plus tard sans dire pourquoi. Aucun delai de garde sur les sondes. check_disk 2.4.0-3+deb13u1 sur mon-01 tourne sans fin (etat R) quels que soient ses arguments : un greffon STANDARD, sur une machine saine, qui boucle. Sans garde il figeait le rapport entier toutes les quinze minutes. Chaque sonde tourne desormais sous timeout 20 ; au-dela on rapporte INCONNU en le disant. La lecon n est pas que les greffons standards sont mauvais : c est qu adopter un standard ne dispense pas de l eprouver, et que le porteur doit survivre a une sonde qui se comporte mal. CONSTATE AU PASSAGE, NON CORRIGE : la configuration d exemple d Icinga crie en permanence sur mon-01 — swap sur une VM sans swap, http sur un port ou rien n ecoute, apt pour un paquet. Trois alarmes qui ne peuvent que rester rouges, dans le seul endroit qui doit rester lisible. Etat : certificat 14/14, sante 14/14 au tenant ; 7/7 au site. 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 22:14:30 -04:00
# LES METRIQUES SONT SEPAREES DU TEXTE, parce que le contrat des greffons Nagios les
# separe : `TEXTE | cle=valeur;avert;crit;min;max`. Tout pousser dans `plugin_output`
# afficherait une ligne illisible a l'ecran ET priverait Icinga de donnees qu'il sait
# tracer. C'est en adoptant le contrat qu'on herite de ce qu'il porte.
charge=$(python3 -c 'import json,sys
texte, _, perf = sys.argv[3].partition("|")
charge = {"type": "Service", "service": sys.argv[1], "exit_status": int(sys.argv[2]),
"plugin_output": texte.strip() or "(aucun message)", "ttl": int(sys.argv[4])}
if perf.strip():
charge["performance_data"] = perf.split()
print(json.dumps(charge))' \
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
"${MOI}!$1" "$2" "$3" "$4")
supervision : systemctl --failed entre dans Icinga (role client_sante) CE QU IL FERME. openipmi.service echouait a chaque demarrage sur les quatorze machines depuis le 2026-09-02, et systemctl --failed rendait ZERO partout : non parce qu elles allaient bien, mais parce qu aucune n avait redemarre depuis. Il a fallu qu un humain redemarre une machine pour que le defaut existe aux yeux de quelqu un. Un controle qui ne peut echouer qu au demarrage ne mesure rien tant que rien ne demarre. PASSIF, ET A DUREE DE VIE. Un controle actif ne voit pas la machine MUETTE. Ici c est le noeud qui parle, et le ttl de son envoi fait la fraicheur : sans nouvelle, Icinga perime le service tout seul. Le silence alerte autant que l echec. Le minuteur declenche AU DEMARRAGE autant que toutes les 15 min : les echecs de cette famille naissent au boot. CRITIQUE DES LA PREMIERE UNITE, jamais un seuil — une unite en echec est soit un vrai probleme soit du bruit a retirer, et un seuil ferait vivre le bruit. Les tolerances se nomment une par une, vide par defaut. CONTROLE NEGATIF. Unite factice sur obs-01, etat relu dans IcingaDB : CRITICAL, et le verdict NOMME l unite. Les treize autres OK. Apres nettoyage : 14/14 OK. UN CONFLIT EVITE. setops-sauvegardes.conf definissait les object Host ; un second fichier de controle aurait redefini les memes, et Icinga refuse un objet en double — la configuration entiere aurait ete rejetee, donc AUCUNE supervision, en voulant en ajouter. Les hotes vivent maintenant dans setops-hotes.conf, definis une fois. TROIS OBSTACLES. ${#tableau[@]} contient {# que Jinja lit comme un debut de commentaire (remede : comment_start_string en tete du gabarit). Ma premiere sonde a traduit un 403 « Missing permission: objects/query/service » en « 0 service » — encore un echec qui ecrasait permission ; l etat se lit dans IcingaDB. Et un echec apt transitoire sur mon-01, local et disparu au second essai : mesure avant conclusion. NON FAIT : le SITE n a pas recu client_sante. make prouver : CONFORME, 63 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 20:32:08 -04:00
reponse=$(curl -sS --cacert "{{ client_sante_ca_verification }}" --max-time 20 \
-u "{{ client_sante_icinga_utilisateur }}:${MOTDEPASSE}" \
-H 'Accept: application/json' -H 'Content-Type: application/json' \
-X POST "${API}/v1/actions/process-check-result" -d "${charge}" 2>&1)
if ! printf '%s' "${reponse}" | grep -q '"code": *200'; then
sondes : le contrat ETAIT celui de Nagios, sans le savoir Question posee : « tu connais le paquet monitoring-plugins ? » Oui — et le contrat que docs/supervision-conception.md decrivait quelques heures plus tot EST le sien, mot pour mot. Je l avais reinvente sans le nommer, alors que positionnement.md dit l inverse : adopter aux seuils, ne pas reimplementer. Le document nomme desormais l API des greffons Nagios, ajoute le code 3 (INCONNU) et la partie « | metriques » qui manquaient, et dit la consequence : un greffon standard EST une sonde valide, sans colle. Le paquet en fournit 54. On n ecrit du shell que lorsque la verite a mesurer est propre a Set-OPS. Le porteur separe maintenant texte et performance_data. ESSAYER UN VRAI GREFFON A REVELE DEUX DEFAUTS DU PORTEUR. Un envoi refuse faisait taire TOUTES les sondes suivantes : rapporter sortait en exit 1. Une sonde deposee mais non declaree supprimait le rapport des autres, sante comprise — le tableau ne devenait pas rouge, il devenait vide, et le ttl le perimait des heures plus tard sans dire pourquoi. Aucun delai de garde sur les sondes. check_disk 2.4.0-3+deb13u1 sur mon-01 tourne sans fin (etat R) quels que soient ses arguments : un greffon STANDARD, sur une machine saine, qui boucle. Sans garde il figeait le rapport entier toutes les quinze minutes. Chaque sonde tourne desormais sous timeout 20 ; au-dela on rapporte INCONNU en le disant. La lecon n est pas que les greffons standards sont mauvais : c est qu adopter un standard ne dispense pas de l eprouver, et que le porteur doit survivre a une sonde qui se comporte mal. CONSTATE AU PASSAGE, NON CORRIGE : la configuration d exemple d Icinga crie en permanence sur mon-01 — swap sur une VM sans swap, http sur un port ou rien n ecoute, apt pour un paquet. Trois alarmes qui ne peuvent que rester rouges, dans le seul endroit qui doit rester lisible. Etat : certificat 14/14, sante 14/14 au tenant ; 7/7 au site. 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 22:14:30 -04:00
# ON N'INTERROMPT PAS — mesure du 2026-09-09.
#
# `exit 1` ici faisait taire TOUTES LES SONDES SUIVANTES. Une sonde inconnue d'Icinga
# (deposee mais pas declaree, donc refusee par le filtre d'API) suffisait a supprimer
# le rapport de toutes les autres — y compris `sante`. Le tableau ne devenait pas
# rouge : il devenait VIDE, et le `ttl` le perimait des heures plus tard sans que rien
# ne dise pourquoi.
#
# Un rapporteur qui ne peut pas dire UNE chose doit quand meme dire les autres.
echo "ECHEC du rapport Icinga pour « $1 » : ${reponse}" >&2
ECHECS_RAPPORT=$((ECHECS_RAPPORT + 1))
return 1
supervision : systemctl --failed entre dans Icinga (role client_sante) CE QU IL FERME. openipmi.service echouait a chaque demarrage sur les quatorze machines depuis le 2026-09-02, et systemctl --failed rendait ZERO partout : non parce qu elles allaient bien, mais parce qu aucune n avait redemarre depuis. Il a fallu qu un humain redemarre une machine pour que le defaut existe aux yeux de quelqu un. Un controle qui ne peut echouer qu au demarrage ne mesure rien tant que rien ne demarre. PASSIF, ET A DUREE DE VIE. Un controle actif ne voit pas la machine MUETTE. Ici c est le noeud qui parle, et le ttl de son envoi fait la fraicheur : sans nouvelle, Icinga perime le service tout seul. Le silence alerte autant que l echec. Le minuteur declenche AU DEMARRAGE autant que toutes les 15 min : les echecs de cette famille naissent au boot. CRITIQUE DES LA PREMIERE UNITE, jamais un seuil — une unite en echec est soit un vrai probleme soit du bruit a retirer, et un seuil ferait vivre le bruit. Les tolerances se nomment une par une, vide par defaut. CONTROLE NEGATIF. Unite factice sur obs-01, etat relu dans IcingaDB : CRITICAL, et le verdict NOMME l unite. Les treize autres OK. Apres nettoyage : 14/14 OK. UN CONFLIT EVITE. setops-sauvegardes.conf definissait les object Host ; un second fichier de controle aurait redefini les memes, et Icinga refuse un objet en double — la configuration entiere aurait ete rejetee, donc AUCUNE supervision, en voulant en ajouter. Les hotes vivent maintenant dans setops-hotes.conf, definis une fois. TROIS OBSTACLES. ${#tableau[@]} contient {# que Jinja lit comme un debut de commentaire (remede : comment_start_string en tete du gabarit). Ma premiere sonde a traduit un 403 « Missing permission: objects/query/service » en « 0 service » — encore un echec qui ecrasait permission ; l etat se lit dans IcingaDB. Et un echec apt transitoire sur mon-01, local et disparu au second essai : mesure avant conclusion. NON FAIT : le SITE n a pas recu client_sante. make prouver : CONFORME, 63 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 20:32:08 -04:00
fi
}
# `--plain` et `--no-legend` : la sortie doit etre analysable, pas jolie. Sans eux,
# systemd insere une puce « ● » en tete de ligne, qui devient le premier champ.
supervision : le site rapporte aussi — et deux corrections pour que ca MARCHE 7 machines du site deployees, 0 echec au playbook — et CINQ rapports sur sept en TimeoutError. Un playbook vert ne prouve pas qu une chose fonctionne ; seul l essai de bout en bout l a dit. 1. LE PAIR DE LA FRONTIERE. Le role client declarait son egress 5665, la politique de sortie etait accept, la regle d entree de l hote autorisait la source — et les paquets mouraient ENTRE les deux. La frontiere filtre l inter-zones du site et ne resout que les roles que les machines PORTENT AU PLAN ; une integration universelle n y figure pas, elle est derivee. pair: client_sante produisait donc une regle est-ouest correcte et AUCUNE regle a la frontiere. Le pair devient serveur_debian — le vocabulaire du depot pour « tout noeud », que le generateur traite deja comme tel, et exact au sens strict. Six regles creees, zero retiree, une par patte de zone. 2. LE RAPPORTEUR S ACCUSAIT LUI-MEME. Pendant l heure de blocage, setops-sante.service a echoue ; une fois debloque, cinq machines ont rapporte CRITIQUE en citant leur propre rapporteur, et systemd garde l etat failed jusqu a un reset-failed. Sa propre unite est desormais exclue du compte — non par complaisance : sa sante est deja mesuree, et mieux, par la FRAICHEUR de ses envois. S il ne peut plus parler, le ttl perime le service, ce qui se voit precisement quand il ne peut PAS ecrire. ETAT FINAL : 7/7 au site, 14/14 au tenant, tous OK. Controle negatif rejoue sur les deux flottes. make prouver : CONFORME, 63 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 20:48:36 -04:00
# SA PROPRE UNITE EST EXCLUE, ET CE N'EST PAS SE MENAGER.
#
# Mesure du 2026-09-09 sur le site : le pare-feu a bloque les rapports pendant une heure,
# `setops-sante.service` a donc echoue, et cinq machines se sont mises a rapporter
# CRITIQUE en citant... leur propre rapporteur. Le blocage corrige, l'accusation restait :
# systemd garde l'etat `failed` jusqu'a un `reset-failed`. Un rapporteur qui trebuche une
# fois s'accuserait indefiniment.
#
# La sante du rapporteur est DEJA mesuree, et mieux : par la FRAICHEUR de ses envois. S'il
# ne peut plus parler, Icinga perime le service tout seul (`ttl`) — ce qui se voit
# precisement quand il ne peut PAS ecrire, alors que sa propre unite en echec ne se voit
# que quand il le peut. Se compter soi-meme, c'est mesurer deux fois la meme chose, dont
# une fois mal.
supervision : systemctl --failed entre dans Icinga (role client_sante) CE QU IL FERME. openipmi.service echouait a chaque demarrage sur les quatorze machines depuis le 2026-09-02, et systemctl --failed rendait ZERO partout : non parce qu elles allaient bien, mais parce qu aucune n avait redemarre depuis. Il a fallu qu un humain redemarre une machine pour que le defaut existe aux yeux de quelqu un. Un controle qui ne peut echouer qu au demarrage ne mesure rien tant que rien ne demarre. PASSIF, ET A DUREE DE VIE. Un controle actif ne voit pas la machine MUETTE. Ici c est le noeud qui parle, et le ttl de son envoi fait la fraicheur : sans nouvelle, Icinga perime le service tout seul. Le silence alerte autant que l echec. Le minuteur declenche AU DEMARRAGE autant que toutes les 15 min : les echecs de cette famille naissent au boot. CRITIQUE DES LA PREMIERE UNITE, jamais un seuil — une unite en echec est soit un vrai probleme soit du bruit a retirer, et un seuil ferait vivre le bruit. Les tolerances se nomment une par une, vide par defaut. CONTROLE NEGATIF. Unite factice sur obs-01, etat relu dans IcingaDB : CRITICAL, et le verdict NOMME l unite. Les treize autres OK. Apres nettoyage : 14/14 OK. UN CONFLIT EVITE. setops-sauvegardes.conf definissait les object Host ; un second fichier de controle aurait redefini les memes, et Icinga refuse un objet en double — la configuration entiere aurait ete rejetee, donc AUCUNE supervision, en voulant en ajouter. Les hotes vivent maintenant dans setops-hotes.conf, definis une fois. TROIS OBSTACLES. ${#tableau[@]} contient {# que Jinja lit comme un debut de commentaire (remede : comment_start_string en tete du gabarit). Ma premiere sonde a traduit un 403 « Missing permission: objects/query/service » en « 0 service » — encore un echec qui ecrasait permission ; l etat se lit dans IcingaDB. Et un echec apt transitoire sur mon-01, local et disparu au second essai : mesure avant conclusion. NON FAIT : le SITE n a pas recu client_sante. make prouver : CONFORME, 63 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 20:32:08 -04:00
mapfile -t echecs < <(systemctl list-units --state=failed --plain --no-legend 2>/dev/null \
supervision : le site rapporte aussi — et deux corrections pour que ca MARCHE 7 machines du site deployees, 0 echec au playbook — et CINQ rapports sur sept en TimeoutError. Un playbook vert ne prouve pas qu une chose fonctionne ; seul l essai de bout en bout l a dit. 1. LE PAIR DE LA FRONTIERE. Le role client declarait son egress 5665, la politique de sortie etait accept, la regle d entree de l hote autorisait la source — et les paquets mouraient ENTRE les deux. La frontiere filtre l inter-zones du site et ne resout que les roles que les machines PORTENT AU PLAN ; une integration universelle n y figure pas, elle est derivee. pair: client_sante produisait donc une regle est-ouest correcte et AUCUNE regle a la frontiere. Le pair devient serveur_debian — le vocabulaire du depot pour « tout noeud », que le generateur traite deja comme tel, et exact au sens strict. Six regles creees, zero retiree, une par patte de zone. 2. LE RAPPORTEUR S ACCUSAIT LUI-MEME. Pendant l heure de blocage, setops-sante.service a echoue ; une fois debloque, cinq machines ont rapporte CRITIQUE en citant leur propre rapporteur, et systemd garde l etat failed jusqu a un reset-failed. Sa propre unite est desormais exclue du compte — non par complaisance : sa sante est deja mesuree, et mieux, par la FRAICHEUR de ses envois. S il ne peut plus parler, le ttl perime le service, ce qui se voit precisement quand il ne peut PAS ecrire. ETAT FINAL : 7/7 au site, 14/14 au tenant, tous OK. Controle negatif rejoue sur les deux flottes. make prouver : CONFORME, 63 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 20:48:36 -04:00
| awk '{print $1}' | grep -vx 'setops-sante.service')
supervision : systemctl --failed entre dans Icinga (role client_sante) CE QU IL FERME. openipmi.service echouait a chaque demarrage sur les quatorze machines depuis le 2026-09-02, et systemctl --failed rendait ZERO partout : non parce qu elles allaient bien, mais parce qu aucune n avait redemarre depuis. Il a fallu qu un humain redemarre une machine pour que le defaut existe aux yeux de quelqu un. Un controle qui ne peut echouer qu au demarrage ne mesure rien tant que rien ne demarre. PASSIF, ET A DUREE DE VIE. Un controle actif ne voit pas la machine MUETTE. Ici c est le noeud qui parle, et le ttl de son envoi fait la fraicheur : sans nouvelle, Icinga perime le service tout seul. Le silence alerte autant que l echec. Le minuteur declenche AU DEMARRAGE autant que toutes les 15 min : les echecs de cette famille naissent au boot. CRITIQUE DES LA PREMIERE UNITE, jamais un seuil — une unite en echec est soit un vrai probleme soit du bruit a retirer, et un seuil ferait vivre le bruit. Les tolerances se nomment une par une, vide par defaut. CONTROLE NEGATIF. Unite factice sur obs-01, etat relu dans IcingaDB : CRITICAL, et le verdict NOMME l unite. Les treize autres OK. Apres nettoyage : 14/14 OK. UN CONFLIT EVITE. setops-sauvegardes.conf definissait les object Host ; un second fichier de controle aurait redefini les memes, et Icinga refuse un objet en double — la configuration entiere aurait ete rejetee, donc AUCUNE supervision, en voulant en ajouter. Les hotes vivent maintenant dans setops-hotes.conf, definis une fois. TROIS OBSTACLES. ${#tableau[@]} contient {# que Jinja lit comme un debut de commentaire (remede : comment_start_string en tete du gabarit). Ma premiere sonde a traduit un 403 « Missing permission: objects/query/service » en « 0 service » — encore un echec qui ecrasait permission ; l etat se lit dans IcingaDB. Et un echec apt transitoire sur mon-01, local et disparu au second essai : mesure avant conclusion. NON FAIT : le SITE n a pas recu client_sante. make prouver : CONFORME, 63 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 20:32:08 -04:00
{% if client_sante_unites_tolerees %}
# UNITES TOLEREES, NOMMEES UNE PAR UNE. Jamais un motif large : un filtre qui cache une
# unite en cache d'autres, et on ne s'en apercoit que le jour ou l'on cherche pourquoi
# rien n'a alerte.
tolerees=({% for u in client_sante_unites_tolerees %}"{{ u }}" {% endfor %})
restantes=()
for u in "${echecs[@]}"; do
garder=1
for t in "${tolerees[@]}"; do [[ "$u" == "$t" ]] && garder=0 && break; done
[[ $garder -eq 1 ]] && restantes+=("$u")
done
echecs=("${restantes[@]}")
{% endif %}
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
# LES SONDES DES ROLES, APRES LA SIENNE.
#
# Chaque role depose SA sonde dans ce repertoire ; le porteur ne sait pas ce qu'elles
# mesurent, et c'est le but : ajouter une sonde n'oblige pas a toucher a ce script.
# Contrat : une ligne sur stdout, 0/1/2 en code de sortie
# (docs/supervision-conception.md).
#
# UNE SONDE QUI JETTE N'EST PAS UNE SONDE VERTE. Sans ce traitement, un script casse
# sortirait en 127 et Icinga recevrait un code hors bornes — ou rien. On rapporte donc
# CRITIQUE, en le disant : le pire serait qu'un script mort produise un service muet, que
# le `ttl` finirait par perimer sans que personne sache pourquoi.
sondes() { # $1=repertoire $2=ttl des resultats
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
local f nom sortie code
for f in "$1"/*.sh; do
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
[[ -x "$f" ]] || continue
nom=$(basename "$f" .sh)
sondes : le contrat ETAIT celui de Nagios, sans le savoir Question posee : « tu connais le paquet monitoring-plugins ? » Oui — et le contrat que docs/supervision-conception.md decrivait quelques heures plus tot EST le sien, mot pour mot. Je l avais reinvente sans le nommer, alors que positionnement.md dit l inverse : adopter aux seuils, ne pas reimplementer. Le document nomme desormais l API des greffons Nagios, ajoute le code 3 (INCONNU) et la partie « | metriques » qui manquaient, et dit la consequence : un greffon standard EST une sonde valide, sans colle. Le paquet en fournit 54. On n ecrit du shell que lorsque la verite a mesurer est propre a Set-OPS. Le porteur separe maintenant texte et performance_data. ESSAYER UN VRAI GREFFON A REVELE DEUX DEFAUTS DU PORTEUR. Un envoi refuse faisait taire TOUTES les sondes suivantes : rapporter sortait en exit 1. Une sonde deposee mais non declaree supprimait le rapport des autres, sante comprise — le tableau ne devenait pas rouge, il devenait vide, et le ttl le perimait des heures plus tard sans dire pourquoi. Aucun delai de garde sur les sondes. check_disk 2.4.0-3+deb13u1 sur mon-01 tourne sans fin (etat R) quels que soient ses arguments : un greffon STANDARD, sur une machine saine, qui boucle. Sans garde il figeait le rapport entier toutes les quinze minutes. Chaque sonde tourne desormais sous timeout 20 ; au-dela on rapporte INCONNU en le disant. La lecon n est pas que les greffons standards sont mauvais : c est qu adopter un standard ne dispense pas de l eprouver, et que le porteur doit survivre a une sonde qui se comporte mal. CONSTATE AU PASSAGE, NON CORRIGE : la configuration d exemple d Icinga crie en permanence sur mon-01 — swap sur une VM sans swap, http sur un port ou rien n ecoute, apt pour un paquet. Trois alarmes qui ne peuvent que rester rouges, dans le seul endroit qui doit rester lisible. Etat : certificat 14/14, sante 14/14 au tenant ; 7/7 au site. 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 22:14:30 -04:00
# DELAI DE GARDE SUR CHAQUE SONDE — mesure du 2026-09-09.
#
# Sans lui, une sonde qui BOUCLE fige le rapport entier, toutes les quinze minutes,
# indefiniment. Ce n'est pas theorique : `check_disk` 2.4.0-3+deb13u1 tourne sans fin
# sur `mon-01`, quels que soient ses arguments (etat `R`, pas un blocage d'E/S).
# Un greffon STANDARD, sur une machine saine.
#
# Une sonde qui n'a pas rendu son verdict en 20 s n'a pas de verdict : on rapporte
# INCONNU (3) en le disant, plutot que de laisser le porteur mourir en silence.
sortie=$(timeout {{ client_sante_delai_sonde }} "$f" 2>&1); code=$?
if (( code == 124 )); then
rapporter "$nom" 3 "Sonde ${nom} sans reponse apres {{ client_sante_delai_sonde }} s — aucun verdict." "$2"
sondes : le contrat ETAIT celui de Nagios, sans le savoir Question posee : « tu connais le paquet monitoring-plugins ? » Oui — et le contrat que docs/supervision-conception.md decrivait quelques heures plus tot EST le sien, mot pour mot. Je l avais reinvente sans le nommer, alors que positionnement.md dit l inverse : adopter aux seuils, ne pas reimplementer. Le document nomme desormais l API des greffons Nagios, ajoute le code 3 (INCONNU) et la partie « | metriques » qui manquaient, et dit la consequence : un greffon standard EST une sonde valide, sans colle. Le paquet en fournit 54. On n ecrit du shell que lorsque la verite a mesurer est propre a Set-OPS. Le porteur separe maintenant texte et performance_data. ESSAYER UN VRAI GREFFON A REVELE DEUX DEFAUTS DU PORTEUR. Un envoi refuse faisait taire TOUTES les sondes suivantes : rapporter sortait en exit 1. Une sonde deposee mais non declaree supprimait le rapport des autres, sante comprise — le tableau ne devenait pas rouge, il devenait vide, et le ttl le perimait des heures plus tard sans dire pourquoi. Aucun delai de garde sur les sondes. check_disk 2.4.0-3+deb13u1 sur mon-01 tourne sans fin (etat R) quels que soient ses arguments : un greffon STANDARD, sur une machine saine, qui boucle. Sans garde il figeait le rapport entier toutes les quinze minutes. Chaque sonde tourne desormais sous timeout 20 ; au-dela on rapporte INCONNU en le disant. La lecon n est pas que les greffons standards sont mauvais : c est qu adopter un standard ne dispense pas de l eprouver, et que le porteur doit survivre a une sonde qui se comporte mal. CONSTATE AU PASSAGE, NON CORRIGE : la configuration d exemple d Icinga crie en permanence sur mon-01 — swap sur une VM sans swap, http sur un port ou rien n ecoute, apt pour un paquet. Trois alarmes qui ne peuvent que rester rouges, dans le seul endroit qui doit rester lisible. Etat : certificat 14/14, sante 14/14 au tenant ; 7/7 au site. 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 22:14:30 -04:00
continue
fi
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
if (( code > 3 )); then
rapporter "$nom" 2 "Sonde ${nom} en erreur (code ${code}) : ${sortie:0:160}" "$2"
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
else
rapporter "$nom" "$code" "${sortie:-(aucun message)}" "$2"
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
fi
done
}
# LE MODE MINUTE (2026-09-30). Certaines sondes doivent battre a la minute — `connectivite`,
# qui dit qu'un flux est coupe des qu'il l'est. Elles vivent dans leur propre repertoire,
# HORS de celui-ci : sinon ce rapport-ci les rejouerait au quart d'heure avec un `ttl` de
# 90 min, et leur silence ne se verrait plus avant une heure et demie. Meme rapporteur, meme
# compte, aucun second script a tenir aligne.
if [[ "${1:-}" == "minute" ]]; then
sondes "{{ client_sante_repertoire_minute }}" "{{ client_sante_ttl_minute }}"
exit $(( ECHECS_RAPPORT > 0 ? 1 : 0 ))
fi
supervision : systemctl --failed entre dans Icinga (role client_sante) CE QU IL FERME. openipmi.service echouait a chaque demarrage sur les quatorze machines depuis le 2026-09-02, et systemctl --failed rendait ZERO partout : non parce qu elles allaient bien, mais parce qu aucune n avait redemarre depuis. Il a fallu qu un humain redemarre une machine pour que le defaut existe aux yeux de quelqu un. Un controle qui ne peut echouer qu au demarrage ne mesure rien tant que rien ne demarre. PASSIF, ET A DUREE DE VIE. Un controle actif ne voit pas la machine MUETTE. Ici c est le noeud qui parle, et le ttl de son envoi fait la fraicheur : sans nouvelle, Icinga perime le service tout seul. Le silence alerte autant que l echec. Le minuteur declenche AU DEMARRAGE autant que toutes les 15 min : les echecs de cette famille naissent au boot. CRITIQUE DES LA PREMIERE UNITE, jamais un seuil — une unite en echec est soit un vrai probleme soit du bruit a retirer, et un seuil ferait vivre le bruit. Les tolerances se nomment une par une, vide par defaut. CONTROLE NEGATIF. Unite factice sur obs-01, etat relu dans IcingaDB : CRITICAL, et le verdict NOMME l unite. Les treize autres OK. Apres nettoyage : 14/14 OK. UN CONFLIT EVITE. setops-sauvegardes.conf definissait les object Host ; un second fichier de controle aurait redefini les memes, et Icinga refuse un objet en double — la configuration entiere aurait ete rejetee, donc AUCUNE supervision, en voulant en ajouter. Les hotes vivent maintenant dans setops-hotes.conf, definis une fois. TROIS OBSTACLES. ${#tableau[@]} contient {# que Jinja lit comme un debut de commentaire (remede : comment_start_string en tete du gabarit). Ma premiere sonde a traduit un 403 « Missing permission: objects/query/service » en « 0 service » — encore un echec qui ecrasait permission ; l etat se lit dans IcingaDB. Et un echec apt transitoire sur mon-01, local et disparu au second essai : mesure avant conclusion. NON FAIT : le SITE n a pas recu client_sante. make prouver : CONFORME, 63 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 20:32:08 -04:00
n=${#echecs[@]}
if [[ $n -eq 0 ]]; then
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
rapporter "sante" 0 "Aucune unite systemd en echec." "${TTL}"
sondes /usr/local/lib/setops/sondes "{{ client_sante_ttl_sondes }}"
sondes : le contrat ETAIT celui de Nagios, sans le savoir Question posee : « tu connais le paquet monitoring-plugins ? » Oui — et le contrat que docs/supervision-conception.md decrivait quelques heures plus tot EST le sien, mot pour mot. Je l avais reinvente sans le nommer, alors que positionnement.md dit l inverse : adopter aux seuils, ne pas reimplementer. Le document nomme desormais l API des greffons Nagios, ajoute le code 3 (INCONNU) et la partie « | metriques » qui manquaient, et dit la consequence : un greffon standard EST une sonde valide, sans colle. Le paquet en fournit 54. On n ecrit du shell que lorsque la verite a mesurer est propre a Set-OPS. Le porteur separe maintenant texte et performance_data. ESSAYER UN VRAI GREFFON A REVELE DEUX DEFAUTS DU PORTEUR. Un envoi refuse faisait taire TOUTES les sondes suivantes : rapporter sortait en exit 1. Une sonde deposee mais non declaree supprimait le rapport des autres, sante comprise — le tableau ne devenait pas rouge, il devenait vide, et le ttl le perimait des heures plus tard sans dire pourquoi. Aucun delai de garde sur les sondes. check_disk 2.4.0-3+deb13u1 sur mon-01 tourne sans fin (etat R) quels que soient ses arguments : un greffon STANDARD, sur une machine saine, qui boucle. Sans garde il figeait le rapport entier toutes les quinze minutes. Chaque sonde tourne desormais sous timeout 20 ; au-dela on rapporte INCONNU en le disant. La lecon n est pas que les greffons standards sont mauvais : c est qu adopter un standard ne dispense pas de l eprouver, et que le porteur doit survivre a une sonde qui se comporte mal. CONSTATE AU PASSAGE, NON CORRIGE : la configuration d exemple d Icinga crie en permanence sur mon-01 — swap sur une VM sans swap, http sur un port ou rien n ecoute, apt pour un paquet. Trois alarmes qui ne peuvent que rester rouges, dans le seul endroit qui doit rester lisible. Etat : certificat 14/14, sante 14/14 au tenant ; 7/7 au site. 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 22:14:30 -04:00
exit $(( ECHECS_RAPPORT > 0 ? 1 : 0 ))
supervision : systemctl --failed entre dans Icinga (role client_sante) CE QU IL FERME. openipmi.service echouait a chaque demarrage sur les quatorze machines depuis le 2026-09-02, et systemctl --failed rendait ZERO partout : non parce qu elles allaient bien, mais parce qu aucune n avait redemarre depuis. Il a fallu qu un humain redemarre une machine pour que le defaut existe aux yeux de quelqu un. Un controle qui ne peut echouer qu au demarrage ne mesure rien tant que rien ne demarre. PASSIF, ET A DUREE DE VIE. Un controle actif ne voit pas la machine MUETTE. Ici c est le noeud qui parle, et le ttl de son envoi fait la fraicheur : sans nouvelle, Icinga perime le service tout seul. Le silence alerte autant que l echec. Le minuteur declenche AU DEMARRAGE autant que toutes les 15 min : les echecs de cette famille naissent au boot. CRITIQUE DES LA PREMIERE UNITE, jamais un seuil — une unite en echec est soit un vrai probleme soit du bruit a retirer, et un seuil ferait vivre le bruit. Les tolerances se nomment une par une, vide par defaut. CONTROLE NEGATIF. Unite factice sur obs-01, etat relu dans IcingaDB : CRITICAL, et le verdict NOMME l unite. Les treize autres OK. Apres nettoyage : 14/14 OK. UN CONFLIT EVITE. setops-sauvegardes.conf definissait les object Host ; un second fichier de controle aurait redefini les memes, et Icinga refuse un objet en double — la configuration entiere aurait ete rejetee, donc AUCUNE supervision, en voulant en ajouter. Les hotes vivent maintenant dans setops-hotes.conf, definis une fois. TROIS OBSTACLES. ${#tableau[@]} contient {# que Jinja lit comme un debut de commentaire (remede : comment_start_string en tete du gabarit). Ma premiere sonde a traduit un 403 « Missing permission: objects/query/service » en « 0 service » — encore un echec qui ecrasait permission ; l etat se lit dans IcingaDB. Et un echec apt transitoire sur mon-01, local et disparu au second essai : mesure avant conclusion. NON FAIT : le SITE n a pas recu client_sante. make prouver : CONFORME, 63 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 20:32:08 -04:00
fi
# CRITIQUE des la premiere, et non un seuil. Une unite en echec est soit un vrai
# probleme, soit du bruit qu'il faut retirer : dans les deux cas il faut agir. Un seuil
# ferait vivre le bruit indefiniment, et c'est exactement ce qu'on vient de corriger.
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
rapporter "sante" 2 "$n unite(s) systemd en echec : ${echecs[*]}" "${TTL}"
sondes /usr/local/lib/setops/sondes "{{ client_sante_ttl_sondes }}"
sondes : le contrat ETAIT celui de Nagios, sans le savoir Question posee : « tu connais le paquet monitoring-plugins ? » Oui — et le contrat que docs/supervision-conception.md decrivait quelques heures plus tot EST le sien, mot pour mot. Je l avais reinvente sans le nommer, alors que positionnement.md dit l inverse : adopter aux seuils, ne pas reimplementer. Le document nomme desormais l API des greffons Nagios, ajoute le code 3 (INCONNU) et la partie « | metriques » qui manquaient, et dit la consequence : un greffon standard EST une sonde valide, sans colle. Le paquet en fournit 54. On n ecrit du shell que lorsque la verite a mesurer est propre a Set-OPS. Le porteur separe maintenant texte et performance_data. ESSAYER UN VRAI GREFFON A REVELE DEUX DEFAUTS DU PORTEUR. Un envoi refuse faisait taire TOUTES les sondes suivantes : rapporter sortait en exit 1. Une sonde deposee mais non declaree supprimait le rapport des autres, sante comprise — le tableau ne devenait pas rouge, il devenait vide, et le ttl le perimait des heures plus tard sans dire pourquoi. Aucun delai de garde sur les sondes. check_disk 2.4.0-3+deb13u1 sur mon-01 tourne sans fin (etat R) quels que soient ses arguments : un greffon STANDARD, sur une machine saine, qui boucle. Sans garde il figeait le rapport entier toutes les quinze minutes. Chaque sonde tourne desormais sous timeout 20 ; au-dela on rapporte INCONNU en le disant. La lecon n est pas que les greffons standards sont mauvais : c est qu adopter un standard ne dispense pas de l eprouver, et que le porteur doit survivre a une sonde qui se comporte mal. CONSTATE AU PASSAGE, NON CORRIGE : la configuration d exemple d Icinga crie en permanence sur mon-01 — swap sur une VM sans swap, http sur un port ou rien n ecoute, apt pour un paquet. Trois alarmes qui ne peuvent que rester rouges, dans le seul endroit qui doit rester lisible. Etat : certificat 14/14, sante 14/14 au tenant ; 7/7 au site. 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 22:14:30 -04:00
exit $(( ECHECS_RAPPORT > 0 ? 1 : 0 ))