Daniel Allaire
988d35745e
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 |
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| 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.