Daniel Allaire
5abf20102d
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 |
||
|---|---|---|
| .. | ||
| 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.