2026-07-07 03:08:09 -04:00
|
|
|
---
|
|
|
|
|
# Flux réseau de Prometheus (métriques). Voir docs/flux-conception.md.
|
|
|
|
|
flux:
|
|
|
|
|
- sens: egress
|
|
|
|
|
port: 9100
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: client_metrique
|
|
|
|
|
chiffrement: tls
|
|
|
|
|
raison: "Scrape des node_exporter (HTTPS via cert step-ca) sur chaque nœud instrumenté."
|
|
|
|
|
- sens: ingress
|
|
|
|
|
port: 9090
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: localhost
|
|
|
|
|
chiffrement: clair
|
|
|
|
|
raison: "Console Prometheus consommée en local par Grafana co-localisé (pas d'exposition inter-nœud)."
|
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 FABRIC SE SURVEILLE EN LA TIRANT (2026-09-10).
|
|
|
|
|
#
|
|
|
|
|
# Les hyperviseurs portent `node_exporter` — D-48 l'autorise : « hors flotte » ne vaut
|
|
|
|
|
# que pour les commutateurs et la frontiere. Mais ils ne peuvent pas POUSSER : leur route
|
|
|
|
|
# par defaut vise le routeur du site, qui ne connait pas les reseaux du site, et cette
|
|
|
|
|
# route est GELEE (D-57). Mesure : le porteur de sante y expirait en 20 s.
|
|
|
|
|
#
|
|
|
|
|
# Prometheus tire donc, dans le sens que la frontiere route deja pour `serveur_ops_site`.
|
|
|
|
|
# 7887 lignes de metriques sur `asgard`, dont 1005 unites systemd avec leur etat — soit
|
|
|
|
|
# davantage que ce qu'un ping ou un porteur de sante auraient dit.
|
2026-09-17 10:20:46 -04:00
|
|
|
# LA FRONTIERE ELLE-MEME (2026-09-17) : ses temperatures, sa charge, ses interfaces. Le
|
|
|
|
|
# greffon `os-node_exporter` n'ecoute que sur sa patte de supervision.
|
|
|
|
|
- sens: egress
|
|
|
|
|
port: 9100
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: frontiere
|
|
|
|
|
chiffrement: clair
|
|
|
|
|
raison: >-
|
|
|
|
|
Scrape de l'exportateur de la frontiere (os-node_exporter), sur sa seule patte de
|
|
|
|
|
supervision : l'equipement qui voit passer TOUT le trafic n'avait ni temperature ni
|
|
|
|
|
charge dans la supervision.
|
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
|
|
|
- sens: egress
|
|
|
|
|
port: 9100
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: fabric
|
|
|
|
|
chiffrement: clair
|
|
|
|
|
raison: >-
|
|
|
|
|
Scrape des hyperviseurs : la machine qui PORTE les VM etait invisible de la
|
|
|
|
|
supervision qui les surveille. Elle ne peut pas pousser (route par defaut gelee,
|
|
|
|
|
D-57), donc on la tire.
|