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
51 lines
2.2 KiB
Django/Jinja
51 lines
2.2 KiB
Django/Jinja
/*
|
|
* Gere par Set-OPS (role serveur_icinga). Ne pas editer a la main.
|
|
*
|
|
* LES SONDES QUE LES ROLES DECLARENT — voir docs/supervision-conception.md.
|
|
*
|
|
* Rien ici n'est ecrit a la main : chaque service vient d'un `meta/supervision.yml`, et
|
|
* s'attache aux hotes qui portent le role qui le declare. Ajouter une sonde a un role la
|
|
* fait apparaitre ici sans toucher a ce fichier — comme un flux declare devient une
|
|
* regle nftables.
|
|
*
|
|
* CE QUE CA REMPLACE : dix-neuf lignes `surveillance:` en prose dans
|
|
* `docs/dependances-groupes.yml`, ecrites, versionnees, relues — et qu'aucun mecanisme
|
|
* n'executait. La carte disait ce qui etait surveille, et personne ne surveillait.
|
|
*
|
|
* Les HOTES sont definis dans `setops-hotes.conf` : ici, rien que des services.
|
|
*/
|
|
|
|
{#
|
|
* UN SERVICE PASSIF N'EXISTE QUE POUR UN HOTE QUI PEUT POUSSER (2026-09-10).
|
|
*
|
|
* Les hyperviseurs ont rejoint `client_metrique` — c'est par ce groupe qu'on leur
|
|
* DEPLOIE node_exporter. La derivation en tirait donc `asgard!metriques`, et Icinga
|
|
* refusait la configuration ENTIERE :
|
|
*
|
|
* Attribute 'host_name': Object 'asgard' of type 'Host' does not exist.
|
|
*
|
|
* Meme en definissant l'hote, le service serait reste UNKNOWN pour toujours : un
|
|
* hyperviseur ne porte pas `client_sante`, parce que sa route par defaut est gelee et
|
|
* qu'il ne peut rien pousser (D-57). On le TIRE avec Prometheus.
|
|
*
|
|
* L'appartenance a un groupe sert donc DEUX choses qui ne coincident pas toujours : a
|
|
* qui l'on deploie, et de qui l'on attend un rapport. La seconde se lit sur le porteur
|
|
* lui-meme — `client_sante` — et nulle part ailleurs.
|
|
#}
|
|
{% for role, sondes in (serveur_icinga_sondes | default({})) | dictsort %}
|
|
{% for hote in ((groups[role] | default([])) | intersect(groups['client_sante'] | default([]))) | sort %}
|
|
{% for sonde in sondes %}
|
|
object Service "{{ sonde.nom }}" {
|
|
host_name = "{{ hote }}"
|
|
check_command = "setops-passif"
|
|
enable_active_checks = false
|
|
enable_passive_checks = true
|
|
volatile = false
|
|
max_check_attempts = 1
|
|
vars.setops_source = "{{ hote }}"
|
|
vars.setops_role = "{{ role }}"
|
|
vars.setops_raison = "{{ (sonde.raison | default('')) | replace('"', "'") | replace('\n', ' ') | trim }}"
|
|
}
|
|
{% endfor %}
|
|
{% endfor %}
|
|
{% endfor %}
|