Alerting actionnable et seuils intelligents
Concevoir des alertes basées sur les symptômes visibles par l'utilisateur plutôt que sur les causes internes.
À retenir
- Alerter sur l'impact utilisateur (symptôme), pas sur une cause technique isolée.
- Le burn rate multi-fenêtres réduit les faux positifs tout en détectant les incidents sévères.
- Chaque alerte doit renvoyer vers un runbook actionnable.
- La fatigue d'alerte se combat par une revue périodique du taux de faux positifs.
Alerter sur les symptômes, pas sur les causes
Une alerte doit signaler qu'un utilisateur ou un objectif métier est ou sera impacté. Alerter sur une cause probable (« CPU à 85 % ») sans lien démontré avec un impact utilisateur génère du bruit : un CPU élevé n'est pas forcément un problème si la latence et le taux d'erreur restent normaux.
Le modèle SLI / SLO / erreur budget
Le Google SRE Book formalise cette approche autour des indicateurs de niveau de service (SLI) et des objectifs de niveau de service (SLO). L'alerte pertinente porte sur la consommation du budget d'erreur, pas sur une métrique technique isolée.
# Exemple de règle d'alerte Prometheus basée sur le symptôme (taux d'erreur)
groups:
- name: checkout-slo
rules:
- alert: HighErrorBudgetBurn
expr: |
sum(rate(http_requests_total{job="checkout",code=~"5.."}[5m]))
/
sum(rate(http_requests_total{job="checkout"}[5m]))
> 0.02
for: 10m
labels:
severity: page
annotations:
summary: "Taux d'erreur checkout > 2% sur 10 minutes"
runbook: "https://runbooks.internal/checkout-error-rate"
Point clé
une alerte doit toujours pointer vers un runbook actionnable. Si personne ne sait quoi faire à la réception de l'alerte, l'alerte doit être supprimée ou reformulée.
Multi-fenêtres pour réduire le bruit
Une technique éprouvée (popularisée par Google) consiste à combiner une fenêtre courte et une fenêtre longue de consommation du budget d'erreur : cela détecte à la fois les pics violents et les dégradations lentes, tout en filtrant les faux positifs isolés.
| Fenêtre | Seuil de burn rate | Usage |
|---|---|---|
| 5 minutes | 14.4x | Détection rapide d'incident sévère (page immédiate) |
| 1 heure | 6x | Confirmation, évite les faux positifs ponctuels |
| 6 heures | 1x | Dérive lente, ticket non urgent |
Attention
un seuil statique unique (« CPU > 80 % pendant 5 minutes ») ignore la saisonnalité du trafic. Un seuil qui déclenche systématiquement le lundi matin lors du pic hebdomadaire habituel doit être ajusté avec une baseline dynamique ou une comparaison semaine sur semaine.
Fatigue d'alerte : symptôme d'un système mal conçu
Une équipe qui reçoit plus de deux ou trois pages par astreinte et par semaine finit statistiquement par ignorer certaines alertes réelles. La revue périodique des alertes (fréquence de déclenchement, taux de faux positifs, action réellement prise) doit faire partie du cycle d'exploitation, au même titre qu'une revue de code.
Sur le terrain
un cas classique est l'alerte « espace disque < 10 % » déclenchée chaque nuit sur un serveur de logs qui purge automatiquement à 3h du matin — l'alerte est correcte techniquement, mais inutile car sans action requise ; elle doit être reclassée en ticket non urgent, pas en page.
Astuce
pour chaque alerte existante, posez la question « si je reçois ceci à 3h du matin, ai-je une action concrète et différente de ne rien faire ? ». Si la réponse est non, changez la sévérité ou supprimez l'alerte.