PrometheusObservabilitéDevOps

Prometheus : écrire de bonnes règles d'alerting (et éviter les faux positifs)

8 avril 2026 · Sphinx-Digital

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 :

SignalCe qu’il mesureExemple de règle
LatenceTemps de réponse (P95, P99)P99 > 500ms pendant 5min
TraficVolume de requêtesChute de 50% en 5min
ErreursTaux de 5xx> 1% pendant 5min
SaturationCPU, mémoire, queueCPU > 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.