Daniel Allaire
69b84f4e2c
Le role portait une branche « aucun serveur_icinga : rien a poser » et un when sur tout son bloc. Ni l une ni l autre ne pouvait s executer. Eprouve sur le modele public, dans une copie jetable : instancier ne pose une integration UNIVERSELLE que si son serveur existe dans l ecosysteme. Sans Icinga au plan, le groupe client_sante est ABSENT de l inventaire genere — comme client_metrique et client_journal le sont deja. Le role n est donc jamais appele sans destinataire. Une garde qui ne peut pas se declencher n est pas une garde : elle rassure sans rien tenir, et elle coute le jour ou l on cherche pourquoi rien n a alerte. Ce qui la remplace se declenche vraiment, et les deux cotes sont eprouves : hote vide -> FAILED, secret vide -> FAILED, et l echec dit lequel des deux manque. Le bloc, prive de sa condition, est aplati : douze taches a plat. Rejoue sur les deux flottes : zero changement sur zero hote. 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
50 lines
2.7 KiB
Markdown
50 lines
2.7 KiB
Markdown
# 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.
|