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
160 lines
8.5 KiB
YAML
160 lines
8.5 KiB
YAML
---
|
|
serveur_icinga_paquets:
|
|
- icinga2
|
|
- icingadb
|
|
- icingadb-redis
|
|
- postgresql-client # pour importer le schema vers la BD distante
|
|
# LES GREFFONS DE CONTROLE, SANS LESQUELS LE TEMOIN NE VOIT RIEN DE LUI-MEME.
|
|
#
|
|
# `icinga2` n'apporte AUCUN greffon : le paquet ne pose que `check_nscp_api`. Toute la
|
|
# supervision de Set-OPS est PASSIVE — chaque noeud pousse son propre resultat — et
|
|
# cette architecture a masque le manque : les 53 services qui rapportent d'eux-memes
|
|
# etaient verts, et personne ne regardait les autres.
|
|
#
|
|
# CE QUE CA A COUTE (reconstruction du 2026-09-10) : les quatorze services `ping4`
|
|
# rendaient UNKNOWN avec
|
|
#
|
|
# execvpe(/usr/lib/nagios/plugins/check_ping) failed: No such file or directory
|
|
#
|
|
# Or `hostalive` est un ping. Un hote qu'Icinga ne peut pas joindre n'est pas DOWN,
|
|
# il est UNKNOWN — et Icinga ne supprime pas les notifications d'un hote UNKNOWN comme
|
|
# il le fait d'un hote DOWN. Le defaut est donc moins grave qu'une extinction, mais il
|
|
# rend la colonne « l'hote repond-il ? » definitivement muette.
|
|
#
|
|
# `-basic` ET NON LE METAPAQUET : il porte `check_ping`, `check_disk`, `check_http`,
|
|
# `check_load` — ce qu'un temoin verifie lui-meme. `-standard` ajoute des greffons
|
|
# applicatifs (LDAP, SMTP, PostgreSQL) que Set-OPS ne consomme pas : chaque noeud
|
|
# mesure SES services et les rapporte. Installer ce qu'on n'appelle jamais, c'est
|
|
# elargir la surface pour rien.
|
|
- monitoring-plugins-basic
|
|
|
|
serveur_icinga_service_icinga2: "icinga2"
|
|
serveur_icinga_service_icingadb: "icingadb"
|
|
serveur_icinga_service_redis: "icingadb-redis"
|
|
|
|
# Depot apt officiel Icinga (paquet trousseau + source signee).
|
|
serveur_icinga_keyring_url: >-
|
|
{{ serveur_icinga_depot_schema }}://packages.icinga.com/icinga-archive-keyring_latest+debian{{ ansible_distribution_major_version }}.deb
|
|
serveur_icinga_depot_source: >-
|
|
deb [signed-by=/usr/share/keyrings/icinga-archive-keyring.gpg]
|
|
{{ serveur_icinga_depot_schema }}://packages.icinga.com/debian icinga-{{ ansible_distribution_release }} main
|
|
|
|
# Base Icinga DB : resolue depuis le registre par le groupe consommateur.
|
|
serveur_icinga_groupe: "serveur_icinga"
|
|
serveur_icinga_db_host: "" # dérivé (FQDN) par resoudre_base au déploiement
|
|
|
|
# Redis dedie a Icinga DB (paquet icingadb-redis).
|
|
serveur_icinga_redis_host: "localhost"
|
|
serveur_icinga_redis_port: 6380
|
|
|
|
serveur_icinga_config: "/etc/icingadb/config.yml"
|
|
serveur_icinga_schema: "/usr/share/icingadb/schema/pgsql/schema.sql"
|
|
|
|
# TLS vers PostgreSQL (zero-confiance). true = IcingaDB verifie le cert serveur
|
|
# contre le root_ca step-ca (host dans le SAN). root_ca doit etre lisible (0644).
|
|
serveur_icinga_db_tls: false
|
|
serveur_icinga_db_ca: "/etc/step/certs/root_ca.crt"
|
|
|
|
# --- Identite TLS de l'API (5665) ---
|
|
# Icinga s'emet lui-meme son certificat, avec sa propre AC : il renouvelle tout ce qui
|
|
# expire sous 30 jours, et les certificats Set-OPS vivent 24 h. Lui servir un certificat
|
|
# step-ca est donc impossible — il l'ecrase a chaque demarrage (mesure le 2026-08-11).
|
|
# Le consommateur verifie donc le pair contre l'AC d'Icinga : domaine de confiance ferme,
|
|
# pair authentifie, plus aucun `curl -k`.
|
|
#
|
|
# NodeName aligne sur le FQDN : le certificat auto-emis porte NodeName en CN et en SAN,
|
|
# et c'est par le FQDN qu'on appelle l'API. Sans cet alignement, aucune verification ne
|
|
# peut reussir.
|
|
# DERIVE DE L'INVENTAIRE, pas de `ansible_fqdn`. Le fait depend du resolveur de la
|
|
# machine et de la forme de /etc/hosts — il a rendu « mon-01 » alors que le FQDN etait
|
|
# correct (2026-08-12), produisant un certificat SAN=mon-01 que personne ne pouvait
|
|
# verifier en appelant par le nom complet. L'inventaire, lui, est la meme source que
|
|
# celle dont `serveur_backup` compose son URL : les deux ne peuvent pas diverger.
|
|
serveur_icinga_node_name: "{{ inventory_hostname }}.{{ domaine_interne }}"
|
|
serveur_icinga_ca: "/var/lib/icinga2/ca/ca.crt"
|
|
# Ou le depot de sauvegarde attend cette AC (cf. serveur_backup_ca_verification).
|
|
serveur_icinga_ca_destination_depot: "/etc/setops/icinga-ca.crt"
|
|
|
|
# --- Supervision des sauvegardes (resultats passifs pousses par le depot) ---
|
|
# Le controle porte sur la VERITE DE TERRAIN (l'instantane cote depot), pas sur l'unite
|
|
# systemd du noeud source : une unite verte sur un depot vide a menti pendant un mois.
|
|
serveur_icinga_setops_conf: "/etc/icinga2/conf.d/setops-sauvegardes.conf"
|
|
serveur_icinga_api_conf: "/etc/icinga2/conf.d/setops-api-users.conf"
|
|
serveur_icinga_api_utilisateur: "setops-depot"
|
|
serveur_icinga_api_motdepasse: "{{ vault_icinga_api_depot | default('') }}"
|
|
|
|
# Hote portant les depots : DERIVE du groupe, jamais ecrit en dur.
|
|
serveur_icinga_hote_sauvegarde: "{{ (groups['serveur_backup'] | default([]) | first) | default('') }}"
|
|
|
|
# Noeuds dont on ATTEND un instantane : ceux qui portent client_backup ET detiennent
|
|
# reellement de l'etat. Meme regle que `client_backup_jobs`, et meme source que P36 —
|
|
# la liste en clair du catalogue, lue depuis le role qui la possede.
|
|
serveur_icinga_sauvegarde_attendue: >-
|
|
{{ (client_backup_groupes_etat | default([]) | map('extract', groups)
|
|
| select('defined') | flatten | unique | list)
|
|
| intersect(groups['client_backup'] | default([])) }}
|
|
|
|
# LES NOEUDS DONT ON RAPPORTE LA SANTE : tous ceux du plan.
|
|
#
|
|
# `serveur_debian` est le socle — tout hote deploye le porte. Il n'y a donc pas de liste a
|
|
# tenir : un noeud qui entre dans l'ecosysteme entre dans la supervision, et un noeud
|
|
# rase en sort. Une liste ecrite a la main aurait ce defaut precis : elle ne bouge que
|
|
# quand quelqu'un y pense.
|
|
serveur_icinga_sante_attendue: "{{ groups['serveur_debian'] | default([]) }}"
|
|
|
|
# LES HOTES A DEFINIR, UNE SEULE FOIS — l'union de ce que les controles attachent.
|
|
#
|
|
# Icinga REFUSE un `object Host` en double : deux fichiers de controle qui definissent le
|
|
# meme hote font rejeter TOUTE la configuration, donc AUCUNE supervision. Les hotes vivent
|
|
# donc dans `setops-hotes.conf`, et les fichiers de controle n'attachent que des services.
|
|
serveur_icinga_hotes_supervises: >-
|
|
{{ (serveur_icinga_sante_attendue
|
|
+ serveur_icinga_sauvegarde_attendue
|
|
+ ([serveur_icinga_hote_sauvegarde] if serveur_icinga_hote_sauvegarde else []))
|
|
| unique | list }}
|
|
|
|
serveur_icinga_hotes_conf: "/etc/icinga2/conf.d/setops-hotes.conf"
|
|
serveur_icinga_sante_conf: "/etc/icinga2/conf.d/setops-sante.conf"
|
|
serveur_icinga_sondes_conf: "/etc/icinga2/conf.d/setops-sondes.conf"
|
|
# Rempli a l'execution depuis les `meta/supervision.yml` des roles.
|
|
serveur_icinga_sondes: {}
|
|
|
|
# A QUI LA SUPERVISION PARLE — vide = personne, et on le DIT.
|
|
#
|
|
# Icinga livre son exemple avec `root@localhost`. Une supervision qui voit tout et
|
|
# n'en parle a personne a le meme effet qu'une supervision absente, en plus couteux :
|
|
# elle rassure. Renseigne, ce champ cree un destinataire dans le groupe auquel les
|
|
# notifications sont deja assignees.
|
|
#
|
|
# Vide, aucun destinataire n'est pose et le deploiement le SIGNALE — plutot que de
|
|
# laisser croire qu'une alerte partira.
|
|
serveur_icinga_destinataire: ""
|
|
|
|
# --- Sonde de supervision -----------------------------------------------------------
|
|
serveur_icinga_sonde_config_db: /etc/icingadb/config.yml
|
|
# SEUILS SUR LE BATTEMENT D'ICINGADB, qui bat en continu (releve : 1 s sur un systeme
|
|
# sain). Les premiers seuils — 15 et 90 min — visaient la fraicheur des ETATS, et
|
|
# auraient alarme sur un ecosysteme stable ou plus rien ne change. Sur un battement, une
|
|
# minute de silence est deja anormale.
|
|
serveur_icinga_sonde_age_avert: 60
|
|
serveur_icinga_sonde_age_crit: 300
|
|
|
|
# --- SCHEMA DES DEPOTS TIERS (2026-09-10) --------------------------------------------
|
|
#
|
|
# `http` DES QU'UN CACHE EST DANS LE CHEMIN, `https` sinon. Ce n'est pas un relachement :
|
|
# le cache RELAIE ces depots en https vers le fournisseur (voir `serveur_artefacts`,
|
|
# `Remap-*`), et l'integrite vient des SIGNATURES du depot, qu'apt verifie de toute facon.
|
|
# Le meme raisonnement vaut deja pour `deb.debian.org` depuis toujours.
|
|
#
|
|
# Sans cette derivation, chaque machine sortait elle-meme sur Internet : le mandataire ne
|
|
# vaut que pour `http`, et le socle pose deliberement `Acquire::https::Proxy "DIRECT"`
|
|
# parce qu'un cache sans remap refuse les tunnels. Le remap leve ce refus ; encore
|
|
# faut-il DEMANDER en http.
|
|
#
|
|
# DEGRADE, JAMAIS DEVINE : pas de cache d'amorcage declare, pas de reecriture.
|
|
serveur_icinga_depot_schema: >-
|
|
{{ 'http' if (artefacts_amorcage | default('') | string | length > 0) else 'https' }}
|
|
|
|
# LA FABRIC SURVEILLEE, DERIVEE DE L'UNDERLAY PAR L'INVENTAIRE DU SITE.
|
|
# Forme : [{ nom, adresse, role }]. Vide chez un tenant — il n'a pas de fabric a lui.
|
|
serveur_icinga_fabric: []
|