2026-07-07 03:08:09 -04:00
|
|
|
---
|
|
|
|
|
# Flux réseau d'Icinga 2 (moteur de supervision). Voir docs/flux-conception.md.
|
|
|
|
|
# IcingaDB (Redis 6380) est co-localisé : consommé en localhost par le frontal Icinga Web 2.
|
|
|
|
|
flux:
|
|
|
|
|
- sens: ingress
|
|
|
|
|
port: 5665
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: localhost
|
|
|
|
|
chiffrement: clair
|
|
|
|
|
raison: "API Icinga 2 consommée en local par Icinga Web 2 co-localisé."
|
2026-09-02 18:53:44 -04:00
|
|
|
# LES NOEUDS RAPPORTENT EUX-MEMES DEPUIS LE 2026-09-02.
|
|
|
|
|
#
|
|
|
|
|
# Tant que le depot vivait dans l'ecosysteme, il rapportait pour tout le monde et
|
|
|
|
|
# `serveur_backup` suffisait comme pair. Depuis que les ecosystemes deposent chez leur
|
|
|
|
|
# HEBERGEUR — qui heberge du chiffre et ne peut rien juger — c'est chaque detenteur
|
|
|
|
|
# d'etat qui verifie SON depot et le rapporte. Le pair, c'est donc `client_backup`.
|
|
|
|
|
#
|
|
|
|
|
# Les deux coexistent : un ecosysteme qui garde son propre depot continue de le laisser
|
|
|
|
|
# rapporter. `serveur_backup` reste declare juste en dessous.
|
|
|
|
|
- sens: ingress
|
|
|
|
|
port: 5665
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: client_backup
|
|
|
|
|
chiffrement: tls-requis
|
|
|
|
|
raison: "Rapport passif de chaque detenteur d'etat sur SON depot distant : le depot du site heberge du chiffre et ne peut pas le juger."
|
supervision : c'est le DEPOT qui dit ou en sont les sauvegardes
Icinga ne surveillait rien : aucun objet Host ni Service de Set-OPS, seulement
la config Debian d'origine sur localhost.
Superviser setops-sauvegarde.service aurait reproduit le defaut du jour meme :
l'unite etait VERTE sur onze noeuds pendant qu'elle n'emportait rien. Le noeud
sait qu'il a LANCE sa sauvegarde, pas qu'elle est ARRIVEE. backup-01 evalue donc
ses depots et pousse un resultat passif par noeud vers l'API Icinga.
Trois criteres, parce qu'un seul suffit a mentir : l'instantane existe, il est
recent (26 h / 50 h), il contient au moins un fichier.
Le sens du flux est delibere : le depot parle a la supervision, jamais l'inverse
— compromettre mon-01 ne donne aucun acces aux sauvegardes.
Le ttl de 6 h fait la fraicheur : si le rapporteur se tait, Icinga perime les
services tout seul. C'est le silence qui a laisse le defaut vivre un mois.
Deux erreurs corrigees par la mesure :
- --data-urlencode refuse en Bad Request (l'API veut du JSON) ; le flux, le TLS
et l'auth marchaient, seule la charge etait perdue.
- le seuil « vide » en octets signalait a tort idm-01 (2363 o) : un export LDIF
d'un annuaire a un compte pese cela. « Vide » se mesure en FICHIERS. Et le
verdict est un AVERTISSEMENT : la machine ne distingue pas « les donnees ont
disparu » de « il n'y en a pas encore ».
Reserve assumee : curl -k — l'API presente le cert de sa propre AC, pas step-ca.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:39:05 -04:00
|
|
|
- sens: ingress
|
|
|
|
|
port: 5665
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: serveur_backup
|
|
|
|
|
chiffrement: tls-requis
|
|
|
|
|
partage: true
|
|
|
|
|
raison: "Le depot de sauvegarde depose ses resultats passifs (portee : process-check-result sur « sauvegarde: * »)."
|
supervision : le site rapporte aussi — et deux corrections pour que ca MARCHE
7 machines du site deployees, 0 echec au playbook — et CINQ rapports sur
sept en TimeoutError. Un playbook vert ne prouve pas qu une chose
fonctionne ; seul l essai de bout en bout l a dit.
1. LE PAIR DE LA FRONTIERE. Le role client declarait son egress 5665, la
politique de sortie etait accept, la regle d entree de l hote autorisait
la source — et les paquets mouraient ENTRE les deux. La frontiere filtre
l inter-zones du site et ne resout que les roles que les machines PORTENT
AU PLAN ; une integration universelle n y figure pas, elle est derivee.
pair: client_sante produisait donc une regle est-ouest correcte et AUCUNE
regle a la frontiere. Le pair devient serveur_debian — le vocabulaire du
depot pour « tout noeud », que le generateur traite deja comme tel, et
exact au sens strict. Six regles creees, zero retiree, une par patte de
zone.
2. LE RAPPORTEUR S ACCUSAIT LUI-MEME. Pendant l heure de blocage,
setops-sante.service a echoue ; une fois debloque, cinq machines ont
rapporte CRITIQUE en citant leur propre rapporteur, et systemd garde l
etat failed jusqu a un reset-failed. Sa propre unite est desormais exclue
du compte — non par complaisance : sa sante est deja mesuree, et mieux,
par la FRAICHEUR de ses envois. S il ne peut plus parler, le ttl perime le
service, ce qui se voit precisement quand il ne peut PAS ecrire.
ETAT FINAL : 7/7 au site, 14/14 au tenant, tous OK. Controle negatif
rejoue sur les deux flottes.
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
2026-09-09 20:48:36 -04:00
|
|
|
# LE RAPPORT DE SANTE : TOUS les noeuds, pas seulement les detenteurs d'etat.
|
|
|
|
|
#
|
|
|
|
|
# Le declarer ici n'est pas une redondance avec `client_sante/meta/flux.yml`. Les deux
|
|
|
|
|
# faces sont necessaires, et l'oubli s'est paye le 2026-09-09 : le role client etait
|
|
|
|
|
# deploye, sa face EGRESS declaree, la politique de sortie etait `accept`, la regle
|
|
|
|
|
# d'entree de l'hote autorisait bien la source — et cinq machines sur sept rendaient
|
|
|
|
|
# `TimeoutError`. Les paquets mouraient ENTRE les deux, a la frontiere, qui filtre le
|
|
|
|
|
# trafic inter-zones et ne connait que ce que le registre lui dit.
|
|
|
|
|
#
|
|
|
|
|
# `make site-appliquer GROUPE=client_sante` avait pourtant rendu 7/7, 0 echec : un
|
|
|
|
|
# deploiement REUSSI sur un flux qui ne passait pas. Seul l'essai de bout en bout l'a
|
|
|
|
|
# dit — un playbook vert ne prouve pas qu'une chose fonctionne.
|
|
|
|
|
#
|
|
|
|
|
# LE PAIR EST `serveur_debian`, PAS `client_sante`, ET C'EST LA LE POINT.
|
|
|
|
|
#
|
|
|
|
|
# La frontiere ne connait que les roles que les machines PORTENT AU PLAN. Une
|
|
|
|
|
# integration universelle n'y figure pas : elle est derivee, pas declaree. Ecrire
|
|
|
|
|
# `pair: client_sante` produisait donc une regle est-ouest correcte et AUCUNE regle a
|
|
|
|
|
# la frontiere — d'ou les cinq `TimeoutError` sur sept. Le meme piege explique pourquoi
|
|
|
|
|
# le flux `client_backup` juste au-dessus ne suffit pas seul : c'est `serveur_backup`,
|
|
|
|
|
# role REEL du site, qui ouvre la porte.
|
|
|
|
|
#
|
|
|
|
|
# `serveur_debian` est le vocabulaire du depot pour « tout noeud » — le socle que
|
|
|
|
|
# chaque machine porte — et le generateur de frontiere le traite deja comme tel. C'est
|
|
|
|
|
# exact au sens strict : tout noeud rapporte sa sante.
|
|
|
|
|
#
|
|
|
|
|
# `partage: true` : plusieurs pairs entrent par le meme port, la regle est mutualisee.
|
|
|
|
|
- sens: ingress
|
|
|
|
|
port: 5665
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: serveur_debian
|
|
|
|
|
chiffrement: tls-requis
|
|
|
|
|
partage: true
|
|
|
|
|
raison: "Rapport passif de sante de chaque noeud (unites systemd en echec)."
|
icinga : l hote de supervision saturait par sa propre demonstration
« mon-01 tape dans l fond. » Il tapait : load 5,10 sur 4 coeurs, 8
processus check_disk a 70-99 % de CPU chacun, jusqu a 28 minutes de vie.
check_disk 2.4.0-3+deb13u1 ne rend jamais la main sur cet hote (etat R).
Icinga en relancait un a chaque intervalle pour le service `disk` de son
hote de DEMONSTRATION, et aucun ne mourait.
RETIRE : conf.d/hosts.conf, l hote NodeName livre par le paquet. Les apply
Service s y accrochaient — disk, http, swap, apt, load, procs, users — et
trois etaient rouges en permanence (swap sur une VM sans swap, http sur un
port ou rien n ecoute, apt pour un paquet). On retire l HOTE et non les
services : sans lui les apply ne s accrochent a rien, et on ne touche pas
a un fichier que le paquet remplacera. Ca garde ping4, qui vise nos hotes
et sert vraiment.
avant : load 5,10 — 8 check_disk — 3 alarmes rouges permanentes
apres : load 0,77 — 0 check_disk — certificat 14/14, sante 14/14, ping4 14/14
TROUVE EN VERIFIANT : l Icinga du SITE tenait 6 de ses 7 machines pour
MORTES (1/7 UP, contre 14/14 au tenant). hostalive est un ping, le site
est decoupe en zones, et l ICMP inter-zones n etait declare nulle part —
100 % de perte, mesure. Or Icinga SUPPRIME les notifications des services
d un hote DOWN : une supervision qui croit tout mort n alerte plus de
rien, tout en ayant l air de fonctionner.
Le flux est declare des DEUX cotes, et le registre a refuse la premiere
moitie seule — exactement sa raison d etre. CODES_ICMP apprend
echo-request. Regles d hote posees sur les 21 machines.
RESTE OUVERT : le generateur de la frontiere ne sait pas traduire un TYPE
ICMP pour un pair INTERNE — il le note et n emet rien. Le site reste a
1/7. Corriger devis_opnsense.py est le prochain geste.
make prouver : CONFORME, 64 OK, 0 echec, 0 saute.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-09 22:34:32 -04:00
|
|
|
# LA SUPERVISION DOIT POUVOIR JOINDRE CE QU'ELLE SUPERVISE (mesure du 2026-09-09).
|
|
|
|
|
#
|
|
|
|
|
# Nos `object Host` sont verifies par `hostalive`, c'est-a-dire un ping. Sans ce flux,
|
|
|
|
|
# l'Icinga du SITE tenait 6 de ses 7 machines pour MORTES — et Icinga SUPPRIME les
|
|
|
|
|
# notifications des services d'un hote DOWN. Une supervision qui croit tout mort
|
|
|
|
|
# n'alerte plus de rien : c'est pire que pas de supervision, parce qu'elle a l'air de
|
|
|
|
|
# fonctionner.
|
|
|
|
|
#
|
|
|
|
|
# Les hotes acceptent deja tout l'ICMP localement (`serveur_debian`) ; c'est la
|
|
|
|
|
# FRONTIERE qui filtre l'inter-zones, et elle ne connait que ce qui est declare. Le
|
|
|
|
|
# tenant ne le voyait pas : ses zones se parlent deja. Le site, decoupe en pattes
|
|
|
|
|
# separees, non.
|
|
|
|
|
#
|
|
|
|
|
# Le pair est `serveur_debian` — tout noeud — pour la meme raison que le rapport de
|
|
|
|
|
# sante : une integration universelle n'est pas un role porte au plan, et la frontiere
|
|
|
|
|
# ne resout que les roles portes.
|
|
|
|
|
#
|
|
|
|
|
# CE QUE CE PING APPORTE, malgre le `ttl` qui fait deja parler le silence : un signal
|
|
|
|
|
# INDEPENDANT du chemin de rapport. Si le rapport passif casse, le ping le distingue
|
|
|
|
|
# d'une machine reellement tombee.
|
|
|
|
|
- sens: egress
|
|
|
|
|
port: echo-request
|
|
|
|
|
protocole: icmp
|
|
|
|
|
pair: serveur_debian
|
|
|
|
|
chiffrement: n-a
|
|
|
|
|
raison: "La supervision verifie que ses hotes repondent (hostalive) : sans ce flux, elle les tient tous pour morts et supprime leurs notifications."
|
2026-07-07 03:08:09 -04:00
|
|
|
- sens: egress
|
|
|
|
|
port: 5432
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: serveur_postgresql
|
|
|
|
|
chiffrement: tls-requis
|
|
|
|
|
raison: "Base relationnelle du moteur Icinga (verify-full)."
|
le site surveille enfin sa fabric
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
2026-09-10 18:50:43 -04:00
|
|
|
|
|
|
|
|
# LA PASSERELLE FAIT PARTIE DE CE QUI PEUT TOMBER (2026-09-10).
|
|
|
|
|
#
|
|
|
|
|
# La supervision du site voyait ses sept VM et rien d'autre. Mesure : depuis
|
|
|
|
|
# `site-mon-01`, AUCUNE patte de la frontiere ne repondait — pas meme `10.0.36.1`, sa
|
|
|
|
|
# PROPRE passerelle par defaut. OPNsense ne repond pas a l'ICMP sur ses interfaces
|
|
|
|
|
# internes tant qu'une regle ne l'autorise pas.
|
|
|
|
|
#
|
|
|
|
|
# UNE PATTE PAR ZONE, ET C'EST LE POINT. La frontiere est un seul boitier, mais chaque
|
|
|
|
|
# zone du site depend de SON interface a elle. Une interface eteinte — on en a deja vu,
|
|
|
|
|
# les routes creees `disabled` le 2026-09-02 — coupe une zone pendant que les autres
|
|
|
|
|
# vont bien. Un ping vers une seule patte dirait « la frontiere est debout » et
|
|
|
|
|
# manquerait exactement ce cas-la.
|
|
|
|
|
#
|
|
|
|
|
# `fabric` couvre les hyperviseurs ET la frontiere : c'est le materiel de l'hebergeur,
|
|
|
|
|
# celui qu'aucun agent ne peut habiter.
|
|
|
|
|
- sens: egress
|
|
|
|
|
port: echo-request
|
|
|
|
|
protocole: icmp
|
|
|
|
|
pair: fabric
|
|
|
|
|
chiffrement: n-a
|
|
|
|
|
raison: >-
|
|
|
|
|
La supervision verifie que la frontiere sert encore chaque zone. Aucun agent ne peut
|
|
|
|
|
vivre sur un pare-feu : le controle ACTIF est le seul chemin, et il n'existait pas.
|