RousselTMLEARNING

Observabilité

Écrire de bonnes règles d'alerte Prometheus (et les tester)

Concevoir des alertes utiles : alerter sur les symptômes, choisir for et les seuils, labels de sévérité et d'équipe, annotations et runbooks, et tests unitaires avec promtool.

1. Alerter sur les symptômes #

Ce qui gêne l'utilisateur, pas chaque cause possible.

Symptômes et causes #

Alerte sur une causeAlerte sur un symptôme
CPU à 90 %Latence p99 au-dessus de l'objectif
Un pod redémarreTaux d'erreurs 5xx supérieur à 2 %
Disque à 80 %Disque plein dans moins de 4 h (prédiction)

Une alerte doit être actionnable : si personne n'a rien à faire en la recevant, c'est un indicateur de dashboard, pas une alerte. Chaque alerte inutile entraîne la fatigue d'alerte : les équipes finissent par ignorer aussi les vraies.

- alert: DiskWillFillIn4Hours
  expr: predict_linear(node_filesystem_avail_bytes{fstype!="tmpfs"}[6h], 4*3600) < 0
  for: 30m
  labels: { severity: warning }
  annotations:
    summary: "Le disque {{ $labels.mountpoint }} de {{ $labels.instance }} sera plein dans 4 h" 

2. Labels et annotations #

Ce dont le routage et l'humain ont besoin.

Conventions #

ÉlémentUsageExemple
severityUrgence : critical (réveille), warning (heures ouvrées), infocritical
teamÉquipe destinataire, utilisée par le routagepaiement
summaryUne phrase lisible sur un téléphoneAPI paiement : 8 % d'erreurs
descriptionDétails, valeurs{{ $value | humanizePercentage }}
runbook_urlProcédure de diagnostic et de résolutionlien wiki
dashboard_urlDashboard de contextelien Grafana
Erreur Courante : Ne mettez jamais de valeur changeante ({{ $value }}) dans les labels : chaque nouvelle valeur créerait une nouvelle alerte. Les valeurs vont dans les annotations.

3. Tester ses règles #

promtool test rules.

Tests unitaires #

promtool rejoue des séries simulées et vérifie quelles alertes se déclenchent, à quel moment et avec quels labels :

# tests.yml
rule_files: [rules.yml]
evaluation_interval: 1m
tests:
  - interval: 1m
    input_series:
      - series: 'up{job="api", instance="api-1"}'
        values: '1 1 0 0 0 0 0 0'
    alert_rule_test:
      - eval_time: 4m          # 2 min de panne : encore pending
        alertname: InstanceDown
        exp_alerts: []
      - eval_time: 8m          # 6 min de panne : firing
        alertname: InstanceDown
        exp_alerts:
          - exp_labels: { severity: critical, team: plateforme, job: api, instance: api-1 }
            exp_annotations:
              summary: "api-1 ne répond plus"
              runbook_url: https://wiki.example.org/runbooks/instance-down
promtool check rules rules.yml
promtool test rules tests.yml
Bonne Pratique : Ajoutez ces deux commandes à la CI du dépôt des règles : une règle qui ne se déclenche jamais est aussi dangereuse qu'une règle cassée.

Articles liés

Alertmanager : rôle, architecture et cycle de vie d'une alerte

Ce que fait Alertmanager entre Prometheus et vos équipes : déduplication, regroupement, routage, silences et …

Routage, regroupement et récepteurs dans Alertmanager

L'arbre de routage d'Alertmanager : matchers, group_by, group_wait, group_interval, repeat_interval, continue…

Silences, inhibitions et intervalles de temps dans Alertmanager

Réduire le bruit des alertes : silences ponctuels avec amtool, règles d'inhibition (une alerte critique tait …

Pour aller plus loin