Set-OPS-Public/roles/serveur_icinga/defaults/main.yml
Daniel Allaire a5d9040a11 cache-apt scindee — et la scission a revele que moteur aurait alarme a tort
LA SCISSION. cache-apt fondait deux causes aux DELAIS differents : « ne
repond pas » arrete tout apt de l ecosysteme, on agit dans la minute ;
« volume a 90 % » est un billet pour demain. Les fondre obligeait soit a
reveiller quelqu un pour un disque, soit a traiter une panne comme un
billet. Deux sondes, chacune avec son etat, son historique, son
acquittement — et prouvees INDEPENDANTES :

  port ferme       -> cache-apt CRITIQUE, cache-apt-volume OK
  seuil impossible -> cache-apt OK, cache-apt-volume AVERTISSEMENT

CE QUE LA VERIFICATION A REVELE. Un resultat pousse et accepte (code 200)
n apparaissait pas en base. Hypothese testee et confirmee : IcingaDB n
ECRIT service_state QUE SUR CHANGEMENT D ETAT. Un OK identique repete ne
produit aucune ecriture ; un AVERTISSEMENT pousse ensuite est ecrit en 13 s.

Or la sonde moteur, ecrite quelques heures plus tot, lisait exactement
max(last_update) de service_state pour juger de la fraicheur. Elle
mesurait le CHANGEMENT. Sur un ecosysteme parfaitement STABLE — celui
qu on veut — plus rien ne change, last_update vieillit, et elle serait
passee en avertissement a 15 min puis en critique a 90. Une alarme qui se
declenche PARCE QUE tout va bien, avec un delai qui l aurait rendue
difficile a rattacher a sa cause.

La bonne source existait : icingadb_instance porte le battement du
synchroniseur, ecrit en continu. Releve a 1 s sur un systeme sain. Seuils
ramenes de 15/90 min a 1/5 min. Controle negatif rejoue.

Dix-huit services, tous verts sauf sauvegarde 7/9 (deja connu).

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-10 03:27:52 -04:00

117 lines
6 KiB
YAML

---
serveur_icinga_paquets:
- icinga2
- icingadb
- icingadb-redis
- postgresql-client # pour importer le schema vers la BD distante
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: >-
https://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]
https://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