Le monitoring échoue rarement par manque de métriques. Il échoue plus souvent à cause d'alertes sans contexte, de doublons et de règles jamais revues avec les personnes qui exploitent réellement le service. La fatigue d'alertes n'est pas un problème de confort. C'est un problème de fiabilité.
Moins de signaux, une escalade plus claire
Une alerte doit répondre à une question simple : quelqu'un doit-il agir maintenant, ou suffit-il d'observer ? Tout le reste relève plutôt des dashboards, tendances et rapports.
- N'alerter des humains que lorsqu'une action concrète est attendue.
- Séparer alertes, avertissements et simples informations.
- Supprimer les doublons liés à une même cause.
- Router par responsabilité plutôt que par outil.
Ce qu'une bonne alerte doit contenir
Une alerte utile ne donne pas seulement une valeur. Elle donne du contexte : quel service est touché, quelles dépendances sont critiques, si des alertes similaires existent déjà et quel runbook utiliser.
Préférer SLI/SLO aux seuils aveugles
Beaucoup d'équipes alertent encore sur CPU, RAM ou disque alors que le métier ressent surtout disponibilité, latence ou taux d'erreur. Aligner l'alerte sur des SLI/SLO améliore fortement la qualité du signal.
Checklist en 5 minutes
- Revoir les dix alertes les plus fréquentes : exigent-elles une action concrète ?
- Dédupliquer les signaux qui proviennent d'un même incident.
- Mettre les liens vers les runbooks directement dans l'alerte.
- Définir au moins un SLI métier pour chaque service important.
- Revoir l'alerte chaque trimestre avec exploitation et responsables de service.