Set-OPS-Public/wiki/Supervision-et-impact.md

66 lines
2.8 KiB
Markdown
Raw Normal View History

# Supervision & impact
> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.
---
## ① Le concept *(générique)*
**Observabilité** (métriques/logs) = **passive** : on regarde des données. **Supervision** =
**active** : le système **fait des tests** (« le port 443 répond-il ? le disque est-il plein ? »),
tient un **état** (OK / WARNING / CRITICAL) et **alerte** quand ça se dégrade.
Distinction utile : Grafana te *montre* des tendances ; un moteur de supervision *décide* qu'un
service est en panne et *prévient*. Complémentaires, pas interchangeables.
**Modélisation d'impact métier** (BPM) : agréger des checks techniques en **services de haut
niveau**. « Le service *Courriel* est-il sain ? » = (Postfix **ET** Dovecot **ET** l'annuaire).
On raisonne en **impact**, pas en cases isolées.
---
## ② Comment Set-OPS le fait
La pile Icinga, en trois étages :
| Étage | Pièce | Rôle |
|---|---|---|
| **Moteur** | `serveur_icinga` (icinga2 + IcingaDB) | exécute les **checks**, tient l'**état**, alerte. |
| **UI** | `serveur_icingaweb2` | l'interface (états, acquittements, downtimes), **au SSO**. |
| **Impact** | module **BPM** | des **processus métier** qui roulent la santé de plusieurs checks en un état. |
Ce que Grafana ne fait **pas** : le BPM. « Grafana peut-il remplacer le BPM ? » → **non** : l'un
*visualise des mesures*, l'autre *modélise l'impact métier*. On veut **les deux**.
---
## ③ Pourquoi c'est transférable
| Set-OPS | Équivalents ailleurs |
|---|---|
| Icinga | Nagios · Zabbix · Checkmk · Sensu |
| checks actifs + alerting | modèle **universel** de la supervision |
| BPM / impact | *business service monitoring* (concept répandu) |
Tu as appris **supervision active vs observabilité passive, l'état, l'alerting, l'impact** — pas
« Icinga ».
---
## ④ À toi de jouer
documentation : la tournee des 74 documents, parce qu un balayage ne lit pas La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-06 16:18:23 -04:00
1. **Ouvre Icinga Web 2** (`https://icinga.chezlepro.internal`, via le SSO) : la liste des hôtes
et services **supervisés**, avec leur **état** (vert/jaune/rouge).
2. **Vois l'impact.** Menu *Business Processes* → « **Supervision Chezlepro** » : un processus qui
**agrège** des checks (load, procs, ping…) en un état roulé. C'est l'impact, pas une case.
3. **Casse & répare.** Provoque l'échec d'un check (ex. arrête un service surveillé) : l'état passe
**CRITICAL**, et le **processus BPM** qui en dépend **rougit** (l'impact remonte). Répare : tout
reverdit. Tu *sens* la différence entre *mesurer* et *superviser/alerter*.
---
## Pour aller plus loin *(dépôt)*
- Rôles : `roles/serveur_icinga` (moteur), `roles/serveur_icingaweb2` (UI + module BPM).
- SSO devant Icinga Web : `roles/serveur_oauth2_proxy` (passerelle) — unité **Identité & SSO**.
- Complément visuel : unité **Métriques & journaux** (Grafana).