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
57 lines
3.1 KiB
YAML
57 lines
3.1 KiB
YAML
---
|
|
# A QUI L'ON RAPPORTE — derive du groupe, jamais ecrit en dur. Vide = pas de supervision
|
|
# dans cet ecosysteme, et le role ne pose alors ni script ni minuteur : un timer qui
|
|
# echoue chaque heure apprend a ignorer le rouge.
|
|
client_sante_icinga_hote: "{{ (groups['serveur_icinga'] | default([]) | first) | default('') }}"
|
|
|
|
# L'ADRESSE DU TEMOIN, PAR SON NOM — SAUF QUAND LE NOM N'EXISTE PAS (2026-09-10).
|
|
#
|
|
# Le porteur visait `<hote>.<domaine>`, ce qui suppose le plancher `/etc/hosts` pose par
|
|
# le socle. Les HYPERVISEURS ne l'ont pas, et ne doivent pas l'avoir : Proxmox se sert de
|
|
# `/etc/hosts` pour l'identite de noeud du cluster, et la reecrire est un risque qu'on ne
|
|
# prend pas pour une commodite de supervision.
|
|
#
|
|
# Mesure : `curl: (6) Could not resolve host: site-mon-01.genese.internal` sur les trois
|
|
# hyperviseurs, alors que le porteur etait correctement installe et tournait.
|
|
#
|
|
# On DERIVE donc l'URL, ce qui laisse une machine sans resolveur la surcharger par une
|
|
# ADRESSE. Une seule chose change, et elle se declare la ou le nom ne marche pas.
|
|
client_sante_icinga_url: >-
|
|
https://{{ client_sante_icinga_hote }}.{{ domaine_interne }}:5665
|
|
|
|
# LE MEME COMPTE D'API QUE LE RAPPORT DE SAUVEGARDE, et c'est un choix.
|
|
#
|
|
# Un second compte serait plus pur — un secret par usage. Il exigerait une CLEF DE VOUTE
|
|
# DE PLUS dans chaque ecosysteme, donc un geste manuel a chaque nouvel ecosysteme, pour
|
|
# une portee identique : ce compte ne peut deja QUE poser un resultat passif, et
|
|
# seulement sur des services nommes. On elargit le filtre de deux noms a trois, on ne
|
|
# donne aucun pouvoir nouveau.
|
|
client_sante_icinga_utilisateur: "setops-depot"
|
|
client_sante_icinga_motdepasse: "{{ vault_icinga_api_depot | default('') }}"
|
|
client_sante_ca_verification: "/etc/setops/icinga-ca.crt"
|
|
client_sante_icinga_ca_source: "/var/lib/icinga2/ca/ca.crt"
|
|
|
|
# `ttl` du resultat passif. AU-DELA, ICINGA PERIME LE SERVICE DE LUI-MEME — c'est ce qui
|
|
# fait que le SILENCE alerte, et pas seulement l'echec. Un noeud eteint, un timer casse,
|
|
# un reseau coupe : trois facons de ne plus rien dire, et les trois doivent se voir.
|
|
#
|
|
# Trois fois la periode : deux passages peuvent manquer sans crier au loup.
|
|
client_sante_periode: "15min"
|
|
client_sante_ttl_icinga: 2700
|
|
|
|
# UNITES TOLEREES — nommees, jamais un motif large.
|
|
#
|
|
# Vide par defaut, et c'est le bon defaut : une unite en echec permanent use le seul
|
|
# signal qui devrait alerter. Le jour ou une VRAIE unite tombe, le compte passe de 1 a 2
|
|
# et personne ne fait la difference. Si une unite doit etre toleree, elle est ECRITE ICI,
|
|
# avec sa raison — pas absorbee par un filtre qui en cacherait d'autres.
|
|
client_sante_unites_tolerees: []
|
|
|
|
# `ttl` des sondes de ROLE. Plus long que celui de `sante` : une sonde de role peut etre
|
|
# plus lente (une poignee TLS, une requete), et on ne veut pas qu'un hoquet la perime.
|
|
# Six passages du porteur.
|
|
client_sante_ttl_sondes: 5400
|
|
|
|
# Delai de garde de CHAQUE sonde. Une sonde est cense repondre vite ; celle qui depasse
|
|
# n'a pas de verdict, et on le dit (INCONNU) plutot que de figer tout le rapport.
|
|
client_sante_delai_sonde: 20
|