L’alert fatigue est un phénomène réel : quand les alertes sont trop nombreuses ou trop peu pertinentes, les équipes finissent par les ignorer. Le résultat ? Une alerte critique qui passe inaperçue. Voici comment écrire des règles qui déclenchent au bon moment.
L’anatomie d’une bonne règle d’alerte
groups:
- name: api_alerts
rules:
- alert: ApiHighErrorRate
expr: |
rate(http_requests_total{status=~"5.."}[5m])
/ rate(http_requests_total[5m]) > 0.05
for: 5m
labels:
severity: critical
team: backend
annotations:
summary: "Taux d'erreur élevé sur l'API"
description: >
Le taux d'erreur HTTP 5xx dépasse 5% depuis 5 minutes.
Valeur actuelle : {{ $value | humanizePercentage }}
runbook_url: "https://wiki/runbooks/api-error-rate"
Le paramètre for est souvent sous-estimé. Sans lui, une spike momentanée de 30 secondes déclenche une alerte. Avec for: 5m, l’alerte ne se déclenche que si la condition persiste pendant 5 minutes.
Les 4 Golden Signals comme base
Google SRE définit 4 métriques fondamentales à monitorer :
| Signal | Ce qu’il mesure | Exemple de règle |
|---|---|---|
| Latence | Temps de réponse (P95, P99) | P99 > 500ms pendant 5min |
| Trafic | Volume de requêtes | Chute de 50% en 5min |
| Erreurs | Taux de 5xx | > 1% pendant 5min |
| Saturation | CPU, mémoire, queue | CPU > 90% pendant 10min |
Dead man’s switch : l’alerte qui se déclenche quand ça ne répond plus
- alert: WatchdogSilent
expr: absent(up{job="my-service"})
for: 1m
annotations:
summary: "Service my-service introuvable par Prometheus"
absent() déclenche une alerte si la métrique n’existe plus — utile pour détecter un service crashé ou un exporter qui ne répond plus.
Inhibition et silencing
L’inhibition permet de supprimer des alertes de moindre importance quand une alerte critique est active :
inhibit_rules:
- source_match:
severity: critical
target_match:
severity: warning
equal: [service]
Si une alerte critical est active sur le service api, les alertes warning sur ce même service sont supprimées. Moins de bruit, meilleure lisibilité.
Tester vos règles avant de les déployer
# Vérifier la syntaxe
promtool check rules rules.yml
# Tester unitairement
promtool test rules tests.yml
Les unit tests Prometheus permettent de simuler des séries temporelles et de vérifier que vos règles se déclenchent au bon moment. Un investissement souvent négligé, mais précieux.
Approfondissez ces sujets dans notre formation Prometheus & Grafana.