History

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
..
defaults	cache-apt scindee — et la scission a revele que moteur aurait alarme a tort	2026-09-10 03:27:52 -04:00
handlers	Rendre le dry-run (--check) fiable sur les rôles applicatifs	2026-07-01 21:01:53 -04:00
meta	sondes : quatorze, une par role, derivees en objets Icinga	2026-09-10 03:00:21 -04:00
tasks	sondes : quatorze, une par role, derivees en objets Icinga	2026-09-10 03:00:21 -04:00
templates	cache-apt scindee — et la scission a revele que moteur aurait alarme a tort	2026-09-10 03:27:52 -04:00
README.md	Set-OPS — moteur d'ecosystemes numeriques souverains (Alliance Boreale)	2026-06-24 20:17:46 -04:00

README.md

serveur_icinga

Supervision active Icinga — cœur de surveillance. Portée actuelle : Icinga 2 + Icinga DB (avec son Redis dédié et sa base PostgreSQL). Icinga Web 2 est différé à une phase dédiée.

Rôle (cœur)

Ajoute le dépôt apt officiel Icinga (trousseau + source signée) et installe icinga2, icingadb, icingadb-redis.
icinga2 api setup + activation de la fonctionnalité icingadb.
Base PostgreSQL via le registre (instance/plan/bases-donnees.yml, entrée icingadb) : PostgreSQL crée la base/compte, ce rôle importe le schéma et écrit /etc/icingadb/config.yml (BD + Redis).

Base de données

Entrée registre icingadb (PostgreSQL sur data-01). Mot de passe partagé via Vault (vault_bd_icingadb), comme Keycloak. Dépendance serveur_icinga requiert serveur_postgresql actif (déjà dans docs/dependances-groupes.yml).

Différé (phase Icinga Web 2)

icingaweb2 + sa 2e base (icingaweb) + PHP-FPM + vhost nginx + assistant de configuration (jeton de setup). À faire proprement avec sa doc verbatim.

Limites / caveats honnêtes

Les pages détaillées Icinga DB/Web ont renvoyé des 404 ; la config Icinga DB (config.yml, chemin du schéma /usr/share/icingadb/schema/pgsql/schema.sql, port Redis 6380) suit la structure documentée standard mais n'a pas pu être vérifiée verbatim — à confirmer/ajuster selon la version installée (variables prévues).
Non testé live (mon-01 planifié).
L'import de schéma s'exécute une seule fois (marqueur /etc/icingadb/.schema-imported).

Prérequis

serveur_postgresql actif (base icingadb créée), accès réseau à data-01:5432.