Niveau 🔴 avancé
Durée estimée : 20 min · Prérequis : Exposer ou non
Installer un détecteur de fumée, c'est du déploiement. Vérifier périodiquement sa pile, régler
sa sensibilité pour qu'il ne se déclenche pas à chaque toast un peu brûlé, et savoir quoi faire
quand il sonne — c'est l'exploitation. Un détecteur installé mais jamais entretenu, ou qui sonne
si souvent pour rien qu'on finit par le débrancher, ne protège plus personne.
Le déploiement de Prometheus, Grafana et node_exporter — dont le piège central (mesurer la
vraie machine, pas un conteneur ou une VM) — a déjà été détaillé en
M6. Cette page porte sur l'étape suivante :
qu'est-ce qu'on fait, concrètement, une fois que les métriques arrivent ?
Regarder un dashboard n'est pas de la supervision. Un tableau de bord qu'on consulte
« de temps en temps » détecte un problème seulement si quelqu'un a le réflexe de le regarder
juste au bon moment — un pari, pas une méthode. La supervision réelle repose sur des alertes
: des règles qui déclenchent une notification dès qu'une métrique franchit un seuil défini Ã
l'avance, sans attendre qu'un humain remarque quoi que ce soit.
Choisir un seuil d'alerte, l'exercice le plus délicat de cette page : un seuil trop bas
déclenche pour des variations normales (un pic de CPU de quelques secondes lors d'une sauvegarde
planifiée, par exemple), un seuil trop haut laisse passer un vrai problème avant qu'il ne
devienne critique. Une bonne pratique : observer le comportement normal d'un service pendant
plusieurs jours ou semaines avant de fixer un seuil, plutôt que de deviner une valeur arbitraire
dès le premier jour.
La fatigue d'alerte (alert fatigue) est le risque central d'une supervision mal réglée :
si les notifications sont trop fréquentes ou peu pertinentes, elles finissent par être ignorées
par réflexe — au moment précis où une alerte véritablement importante arrive, elle se noie dans
le bruit des précédentes. Une supervision qui alerte trop est, à terme, presque aussi inutile
qu'une supervision absente.
Quelques métriques qui méritent une alerte, plutôt qu'un simple affichage passif : espace
disque disponible sous un seuil critique, utilisation mémoire proche de la saturation, un service
supervisé (via Uptime Kuma) qui ne répond plus
depuis plusieurs cycles consécutifs — plutôt qu'un seul échec ponctuel, souvent un faux positif
sans conséquence.
🧪 Honnêtement, sur notre exemple : les dashboards Grafana (dont le modèle communautaire
« Node Exporter Full », déjà mentionné en M6) sont en place et consultés, mais aucune règle
d'alerte automatique n'est configurée à ce jour — la supervision reste, pour l'instant, du
déploiement complété par une consultation manuelle occasionnelle, pas encore une exploitation
complète au sens de cette page. Un manque assumé, dans le même esprit que l'absence de
sauvegarde documentée en M5 — à combler dans un
prochain incrément, pas à présenter comme déjà résolu.
Exiger la persistance sur plusieurs cycles avant de déclencher une alerte réduit fortement les
faux positifs — un des leviers les plus simples contre la fatigue d'alerte.
# Exemple de règle d'alerte Prometheus (syntaxe simplifiée) --
# déclenche si l'espace disque disponible reste sous 10% pendant 15 min
groups:
- name: disque
rules:
- alert: EspaceDisqueFaible
expr: node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.10
for: 15m
labels:
severity: warning
annotations:
summary: "Espace disque sous 10% depuis 15 minutes"
Le champ for: 15m est ce qui impose la persistance vue dans le schéma — sans lui, une alerte se
déclencherait à la moindre variation ponctuelle, même sans conséquence réelle.
Dans l'interface Prometheus, la section « Alerts » doit lister les règles configurées, avec leur
état (inactive, pending, firing). Un test simple : abaisser temporairement un seuil pour
observer qu'une alerte se déclenche bien comme attendu, puis le remettre à sa valeur normale.
| Symptôme | Cause probable | Solution |
|---|---|---|
| Alertes ignorées par habitude, même les importantes | Fatigue d'alerte accumulée par des seuils trop sensibles | Revoir les seuils à la hausse, exiger une persistance sur plusieurs cycles avant de déclencher |
| Un problème réel non détecté avant plusieurs heures | Aucune alerte configurée, seulement un dashboard consulté occasionnellement | Passer d'un dashboard passif à des règles d'alerte actives sur les métriques critiques |
| Seuil fixé arbitrairement dès le premier jour | Absence d'observation du comportement normal avant de régler le seuil | Observer plusieurs jours ou semaines de fonctionnement normal avant de fixer un seuil définitif |
Parce que ça repose sur la chance qu'un humain regarde au bon moment — une alerte automatique,
elle, détecte un problème sans dépendre de l'attention de quelqu'un.
Le phénomène par lequel des alertes trop fréquentes ou peu pertinentes finissent par être
ignorées par réflexe — au risque de noyer une alerte véritablement importante dans le bruit des
précédentes.
Pour éviter les faux positifs déclenchés par des variations normales et ponctuelles (un pic de
CPU de quelques secondes, par exemple), qui ne signalent pas un vrai problème.
Pour un service que tu supervises (ou envisages de superviser), définis une règle d'alerte
complète : quelle métrique, quel seuil, sur quelle durée de persistance — en justifiant tes choix
par une observation, même approximative, du comportement normal.
alerte ·
fatigue d'alerte ·
seuil
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.