# 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 (sinon rien n'est posé, et c'est dit), le secret
`vault_icinga_api_depot`, et le flux sortant TCP 5665 vers lui.