From 3e8e052670a3175af654f7f32c65bc8bd4e5946a Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Thu, 10 Sep 2026 03:10:24 -0400 Subject: [PATCH] supervision : la regle qui decide COMBIEN de sondes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Question posee : « une sonde par role, est-ce parce qu elles agregent plusieurs verifications ? » Oui — et « une par role » n etait pas mon critere, c etait une coincidence : la plupart de ces roles n ont qu une preoccupation. Mesure : les quatorze sondes agregent de 2 a 6 chemins d echec chacune. Le critere, applique en silence jusqu ici, est desormais ecrit : UNE SONDE PAR CAUSE D ACTION — ni par role, ni par verification. CE QUE COUTE UNE AGREGATION ABUSIVE, dans le modele d Icinga : un service = un etat, un historique, un acquittement. Fondre deux causes qui appellent des gestes differents, c est ne plus pouvoir acquitter l une pendant que l autre alerte, et lire comme un service instable ce qui est deux faits distincts qui alternent. CE QUE COUTE L EXCES INVERSE : un voyant de plus est un voyant de moins regarde. Le test : les deux echecs appellent-ils le meme geste, de la meme personne, dans le meme delai ? Si oui une sonde, et le message nomme lequel a parle. Si non, deux. Par ce critere, deux sondes existantes sont abusives : `certificat` (trois gestes — minuteur bloque, AC changee, consommateur a recharger) et `cache-apt` (deux delais — panne immediate contre billet pour demain). Non scindees : c est une decision sur le nombre de voyants au mur. make prouver : CONFORME, 64 OK, 0 echec, 0 saute. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q --- docs/supervision-conception.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/docs/supervision-conception.md b/docs/supervision-conception.md index db9a96a..cf05e40 100644 --- a/docs/supervision-conception.md +++ b/docs/supervision-conception.md @@ -105,6 +105,35 @@ utilisait `openssl verify -CAfile racine`, alors que nos certificats sont signé allumée ne vaut pas mieux qu'une alarme jamais allumée : elle apprend à ne plus regarder. Une sonde se prouve donc **deux fois** — verte sur le sain, rouge sur le cassé. +## Combien de sondes : une par CAUSE D'ACTION + +Ni une par rôle, ni une par vérification. **Une par geste que le verdict appelle.** + +Les quatorze premières sondes agrègent chacune de deux à six chemins d'échec, et ce choix +avait été fait **sans être écrit** — d'où cette section, ajoutée le 2026-09-10 après la +question : *« est-ce parce qu'elles agrègent plusieurs vérifications ? »* + +**Ce que coûte une agrégation abusive**, dans le modèle d'Icinga : un service = **un état, +un historique, un acquittement**. Fondre deux causes qui appellent des gestes différents, +c'est ne plus pouvoir acquitter l'une pendant que l'autre alerte — et lire comme *un +service instable* ce qui est en réalité *deux faits distincts qui alternent*. + +**Ce que coûte l'excès inverse** : un voyant de plus est un voyant de moins regardé. Le +dépôt le répète assez — *une supervision creuse est pire qu'aucune*. + +Le test pratique, à appliquer sans état d'âme : + +> Les deux échecs appellent-ils **le même geste, de la même personne, dans le même délai** ? +> Si oui, une seule sonde, et le message nomme lequel des deux a parlé. +> Si non, deux sondes. + +**Exemple d'agrégation légitime** — `moteur` : `icinga2` mort, `icingadb` mort, état figé en +base. Trois causes, un seul geste : *va regarder la supervision*. Le message dit laquelle. + +**Exemple d'agrégation abusive** — `cache-apt` : « ne répond pas » arrête tout `apt` de +l'écosystème, « volume à 90 % » est un billet pour demain. Même personne, gestes et +**délais** différents : deux sondes. + ## Une sonde doit pouvoir être mise en défaut *par paramètre* Corollaire des deux règles précédentes, et c'est ce qui rend la discipline tenable à