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 | ||
serveur_prometheus
Collecte de métriques Prometheus (paquet Debian), plateforme d'observabilité.
Rôle
- Installe
prometheus. - Déploie
/etc/prometheus/prometheus.yml: jobprometheus(soi-même) + jobnodedont les cibles sont dérivées de l'inventaire (hôtes actifs declient_metrique→node_exportersur:9100). - Rétention via
/etc/default/prometheus(--storage.tsdb.retention.time). promtool check configavant rechargement (handlerValider et recharger prometheus).
Cibles dérivées de l'inventaire
Comme la zone DNS, la liste de scrape se construit toute seule : ajouter un hôte au
groupe client_metrique et l'activer suffit à le faire scraper. Aucun edit manuel.
Variables principales
| Variable | Défaut | Rôle |
|---|---|---|
serveur_prometheus_intervalle |
15s |
scrape_interval |
serveur_prometheus_retention |
15d |
Rétention TSDB |
serveur_prometheus_groupe_metriques |
client_metrique |
Groupe source des cibles |
serveur_prometheus_port_node |
9100 |
Port node_exporter |
serveur_prometheus_cibles_supplementaires |
[] |
Jobs additionnels libres |
Intégration
- Côté VM :
node_exporterest installé par le futur rôleclient_metrique. serveur_grafanaconsommera Prometheus comme datasource.
Hors périmètre
- Alerting (Alertmanager), règles d'alerte, fédération — phases dédiées.