Chapitre 36. Supervision et audit en exploitation

Objectifs pédagogiques

Configurer la télémétrie et arbitrer son exposition en cohérence avec la matrice de flux. Citer les métriques significatives par famille et proposer un seuil défendable. Écrire une alerte utile. Construire un tableau de bord qui répond aux questions posées en incident. Organiser l'exploitation courante des journaux. Installer les rituels d'une exploitation Vault.

Prérequis

Chapitre 26 (les codes de santé et le motif nominal), chapitre 30 (l'audit à double flux et ses requêtes), chapitre 25 (la croissance du stockage et ses causes), chapitre 23 (la supervision de vault-transit-01).

Cours

36.1 Activer la télémétrie

Vault expose un jeu de métriques internes, activé par une strophe de configuration.

telemetry {
  prometheus_retention_time = "24h"
  disable_hostname          = true
}

La première ligne met à disposition un point de collecte, avec une fenêtre de rétention en mémoire. La seconde évite que le nom d'hôte ne soit préfixé à chaque métrique, ce qui rendrait les séries incomparables entre nœuds.

Vault sait aussi pousser ses métriques vers un agrégateur, et cette variante n'est pas un détail d'implémentation : elle décide du sens des flux.

Le chapitre 30 a posé une règle qui vaut ici : les nœuds poussent, le collecteur n'ouvre jamais de session vers eux. Une collecte par interrogation fonctionne à l'inverse et contredirait donc l'invariant. Deux réponses sont défendables, et le choix se consigne. Ouvrir une exception étroite, où monitor-01 est autorisé à lire sys/metrics sur les nœuds, sous un token dédié d'une seule règle, la matrice gagnant une ligne. Ou conserver l'invariant avec un agent local sur chaque nœud, qui interroge localhost et pousse vers monitor-01.

Astrea retient la seconde, pour la raison qui avait fait choisir le sens unique : la compromission du collecteur ne doit ouvrir aucun chemin vers la zone Vault. Décision consignée, avec sa contrepartie assumée, un agent de plus à maintenir.

Une note d'exposition pour finir : le point de métriques peut être ouvert sans authentification par une option d'écouteur. Astrea ne l'utilise pas. Les métriques disent le nombre de baux, le rythme des requêtes, l'identité du leader et l'état du seal, ce qui constitue une reconnaissance précise offerte à qui atteint le port.

36.2 Les métriques qui comptent

Une installation produit des centaines de séries ; une dizaine décide de l'exploitation. Elles se rangent en cinq familles.

Famille	Métrique	Seuil
État du service	vault.core.unsealed	toute valeur à 0 sur un nœud qui devrait servir est un incident
Leadership	vault.core.leadership_lost_count	plus d'une bascule par mois hors maintenance ouvre un ticket
Latences de stockage	les séries vault.raft-storage.*	écart durable à la référence mesurée sur l'installation
Objets à cycle de vie	vault.expire.num_leases, compte de tokens	la pente compte autant que la valeur
Échecs d'audit	compteurs d'échec des dispositifs	zéro, avec alerte immédiate

Quelques-unes de ces lignes méritent un commentaire.

Les latences de stockage sont là où se voit la dégradation d'un disque ou la saturation d'un nœud, souvent des semaines avant que les utilisateurs ne s'en plaignent. Le seuil ne se fixe pas dans l'absolu : on relève la valeur habituelle sur un mois de fonctionnement sain, et l'on alerte sur un écart durable.

Les objets à cycle de vie s'interprètent par leur pente : une progression régulière sans plateau signale des renouvellements automatiques oubliés ou un consommateur qui redemande au lieu de renouveler.

Les échecs d'audit méritent une place à part, puisque Vault refuse de répondre si plus aucun dispositif ne peut écrire. Un échec sur l'un des deux flux n'arrête rien, mais il consomme la marge.

S'y ajoutent la latence des requêtes, les métriques d'exécution du processus et la taille du répertoire de données, qui relèvent de la supervision système classique. Une précision honnête : les noms exacts varient selon les versions, et la référence fiable reste la sortie de la version installée, pas un tableau recopié d'ailleurs.

36.3 Concevoir des alertes utiles

Une alerte a un coût : elle interrompt quelqu'un. Deux principes limitent ce coût sans perdre en couverture.

Alerter sur le symptôme, diagnostiquer par la cause. On réveille pour « aucun nœud actif », pas pour « la latence d'écriture d'un nœud a augmenté de douze pour cent » : cette dernière information est précieuse sur un tableau de bord, pour comprendre la première. Une exception assumée : les alertes de prévention, dont l'intérêt est justement de se déclencher avant tout symptôme, comme l'échéance d'un certificat.

Séparer ce qui réveille de ce qui attend.

Réveiller	Ouvrir un ticket
aucun nœud actif	plus d'une bascule dans le mois
un nœud descellé qui se scelle	dérive durable des latences
échec d'écriture d'un dispositif d'audit	croissance anormale des baux
volume des journaux au-delà du seuil haut	certificat à moins de trois jours
perte de quorum	snapshot attendu et non reçu
vault-transit-01 injoignable	divergence policies actives contre dépôt
déchiffrement autounseal-core sans redémarrage

vault-transit-01 injoignable figure dans la première colonne alors qu'il n'affecte rien de vivant : c'est l'alerte de capacité à redémarrer du chapitre 23, qui hypothèque tout redémarrage à venir. Et le déchiffrement sans redémarrage est le signal de corrélation du chapitre 31, paire fatale en formation.

Chaque alerte porte trois attributs, sans quoi elle ne vaut rien : ce qu'elle signifie en une phrase, ce qu'il faut faire par un lien vers le runbook, et qui la reçoit. Une alerte sans destinataire nommé finit sur une liste de diffusion que personne ne lit.

36.4 Le tableau de bord

Un tableau de bord ne sert pas à contempler des courbes : il sert à répondre, en quelques secondes et sous pression, aux questions que l'on se pose en incident. Celui d'Astrea tient sur un écran et répond à quatre questions dans cet ordre.

Le service répond-il ? Le motif de santé des trois nœuds (200, 429, 429), l'état du seal de chacun, celui de vault-transit-01. Qui mène, et depuis quand ? L'identité de l'actif et le compteur de bascules sur trente jours. Le système souffre-t-il ? Latences de stockage et de requêtes, avec leur référence habituelle tracée en pointillé, ce qui rend l'écart lisible sans calcul. Qu'est-ce qui grossit ? Baux, tokens, taille du stockage, volume d'audit, chacun sur trente jours.

Une cinquième zone, plus discrète, affiche les échéances : prochain certificat à renouveler, dernier snapshot reçu, dernière restauration d'épreuve, prochaine vérification des porteurs de parts. Ces informations ne sont pas des métriques, mais elles répondent à la question qui compte le plus en exploitation courante : qu'est-ce qui va nous surprendre bientôt ?

36.5 Exploiter l'audit au quotidien

Le chapitre 30 a rendu les journaux interrogeables et préparé quatre requêtes pour l'incident. L'exploitation courante ajoute un usage différent : chercher sans être alerté, parce que certaines choses ne déclenchent aucun seuil.

La revue hebdomadaire dure vingt minutes et regarde trois choses. Les refus : leur volume, leur répartition par identité, et tout pic nominatif ; la rafale de refus reste le signal précoce du chapitre 31, et un pic bénin s'explique généralement par un déploiement mal configuré, ce qui est utile aussi. Les chemins de pouvoir : toute écriture sur les chemins d'administration, confrontée aux changements attendus ; la liste doit correspondre au journal des modifications, sinon quelqu'un a agi hors procédure. Les accès aux secrets sensibles : lectures de production, déchiffrements, émissions de certificats, avec un œil sur les horaires inhabituels.

Deux compléments donnent à cette revue son efficacité. L'intégration au collecteur transforme les requêtes du chapitre 30 en tableaux enregistrés, exécutables d'un clic plutôt que réécrits chaque semaine. Et la rétention doit couvrir la fenêtre d'enquête : découvrir en mars une compromission de janvier ne sert à rien si les journaux de janvier ont disparu en février.

36.6 Les rituels

La supervision qui fonctionne repose moins sur la richesse de l'outillage que sur la régularité des gestes.

Rythme	Durée	Contenu
Chaque jour	cinq minutes	tableau de bord, zone des échéances, présence du snapshot de la nuit
Chaque semaine	vingt minutes	revue d'audit, contrôle que les alertes reçues ont été traitées ou classées
Chaque mois	deux heures	restauration d'épreuve chronométrée, revue des baux et des tokens longs, relecture des seuils
Chaque trimestre	une demi-journée	revue KV, revue anti-dérive, rotation des tokens de seal, exercice sur table
Chaque année	variable	vérification des porteurs, exercice de reprise complet, révision du modèle de menaces, relecture du dossier

Ce calendrier n'a rien d'ambitieux : cinq minutes par jour, vingt par semaine, deux heures par mois. Sa valeur tient à ce qu'il est écrit, attribué et coché. Une exploitation qui repose sur la vigilance individuelle fonctionne jusqu'aux vacances de la personne vigilante.

Exemple : la courbe qui montait depuis six semaines

La revue mensuelle relève une progression régulière du nombre de baux, sans plateau : quatre mille deux cents, puis cinq mille cent, puis six mille trois cents. Aucun seuil n'était franchi, aucune alerte n'avait été émise, et la latence restait nominale. Seule la pente attirait l'œil, et seulement parce que quelqu'un regardait la courbe sur trente jours plutôt que sur une journée.

Le diagnostic prend dix minutes. Les baux proviennent d'un seul rôle, et leur émission suit un rythme de quatre par minute alors que la flotte compte six instances. La lecture des entrées montre le mécanisme : une bibliothèque de connexion mise à jour ouvre un nouveau jeu de credentials à chaque reconstruction de son pool, et les anciens baux, non révoqués explicitement, vivent jusqu'à leur échéance. Rien n'est cassé, rien n'est attaqué, et la trajectoire menait pourtant à une saturation calculée pour la fin du trimestre.

Trois actions sortent de la séance. Correction applicative : le pool obtient ses credentials au démarrage et les renouvelle, conformément à la doctrine du chapitre 18, laquelle était documentée depuis quinze chapitres sans empêcher la régression. Contrôle permanent : un quota de débit sur le chemin d'émission, la mesure préventive que le dernier scénario du chapitre 31 avait suggérée. Supervision : une alerte de tendance vient compléter les alertes de seuil, la pente hebdomadaire du nombre de baux ouvrant désormais un ticket.

La ligne retenue par l'équipe : « Aucun seuil n'a été franchi. C'est précisément pour cela que la surveillance regarde des pentes et pas seulement des lignes. »

Sécurité : surveiller sans s'exposer

Les métriques sont de la reconnaissance, et les tableaux de bord racontent l'entreprise. Nombre de baux, rythme des requêtes, identité du leader, état du seal : un attaquant en tire la carte du fonctionnement et le meilleur moment pour agir. Le point de collecte reste donc authentifié ou filtré, et l'accès aux tableaux comme aux journaux se restreint comme celui du dossier d'architecture.

Le sens des flux d'observation reste une décision d'architecture. Que le collecteur interroge ou que les nœuds poussent n'est pas un détail d'outillage : le premier crée un chemin du moins critique vers le plus critique.

Une alerte sans destinataire ni runbook est un bruit. Elle sera d'abord ignorée, puis coupée, et le jour où elle aurait servi, elle n'existera plus.

Erreurs fréquentes

Superviser la machine et pas le service. Processeur, mémoire et disque au vert pendant que le cluster n'a plus d'actif (sections 36.2, 36.4).

Fixer des seuils absolus sur les latences. Les bonnes valeurs dépendent du matériel et de la charge ; le seuil utile est l'écart durable à la référence mesurée sur l'installation (section 36.2).

Traiter un échec d'audit comme un incident mineur. Il consomme la marge d'un mécanisme bloquant : le seuil est zéro (sections 36.2, 30.4).

Ne regarder que des valeurs instantanées. La saturation se prépare en pente douce, sans franchir aucun seuil, pendant des semaines (Exemple).

Ouvrir le point de métriques sans authentification. La commodité d'intégration se paie en reconnaissance offerte (section 36.1).

Accumuler les alertes non traitées. Une file tolérée devient une file ignorée, puis une file coupée (section 36.6).

Faire reposer l'exploitation sur la vigilance individuelle. Cela fonctionne jusqu'aux congés (section 36.6).

Mise en pratique : mesurer et décider

Sur papier ; réponses commentées en fin de partie.

1. Rédigez la fiche des six alertes qui réveillent, avec pour chacune sa signification en une phrase, son seuil, le geste immédiat attendu et le renvoi au runbook.
2. Concevez le tableau de bord d'astreinte sur un seul écran : zones, contenu de chacune, et la question à laquelle chaque zone répond.
3. La latence d'écriture d'un nœud a doublé en trois semaines, sans plainte utilisateur et sans dépassement de seuil. Décrivez votre démarche de diagnostic, dans l'ordre, avec les hypothèses testées et ce que vous décidez selon le résultat.

Questions de compréhension

1. Que fait la strophe de télémétrie, et quelle décision d'architecture le mode d'exposition engage-t-il ?
2. Citez les cinq familles de métriques et la question à laquelle chacune répond.
3. Pourquoi les seuils de latence se définissent-ils par référence plutôt que dans l'absolu ?
4. Pourquoi le seuil des échecs d'audit est-il zéro ?
5. Énoncez les deux principes de conception des alertes et l'exception assumée au premier.
6. Quelles alertes réveillent, et pourquoi celle du gardien y figure-t-elle alors qu'elle n'affecte rien de vivant ?
7. À quelles questions un tableau de bord d'astreinte doit-il répondre, et que contient sa zone des échéances ?
8. Que regarde la revue hebdomadaire d'audit, et pourquoi ces trois choses ?
9. Détaillez le rythme des rituels et expliquez ce qui fait leur valeur.

Synthèse

La supervision commence par une décision d'architecture plutôt que par un outil : selon que le collecteur interroge ou que les nœuds poussent, on crée ou non un chemin vers la zone la plus sensible. Une dizaine de métriques suffisent ensuite, rangées en cinq familles dont les seuils se définissent par référence à l'installation, sauf pour l'audit où le seuil est zéro. Les alertes se conçoivent en deux catégories, chacune portant sa phrase, son geste et son destinataire. Le tableau de bord répond aux questions de l'incident et affiche ce qui va bientôt surprendre. Les journaux se lisent chaque semaine en trois passes, parce que certaines choses ne déclenchent aucun seuil. Et l'ensemble ne vaut que par des rituels écrits et attribués.