RousselTMLEARNING

Observabilité

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 inhibitions, et le cycle de vie d'une alerte de pending à resolved.

1. Qui fait quoi ? #

Prometheus détecte, Alertmanager notifie.

Le partage des rôles #

Architecture de l'alerting
Plusieurs Prometheus peuvent envoyer les mêmes alertes : Alertmanager les déduplique.

Prometheus évalue périodiquement des règles d'alerte (expressions PromQL). Quand une règle est vraie, il envoie l'alerte (avec ses labels et annotations) à Alertmanager, et la renvoie régulièrement tant qu'elle est active.

Alertmanager ne connaît pas PromQL : il reçoit des alertes et décide qui prévenir, quand et comment.

FonctionEffet
DéduplicationUne alerte reçue de deux Prometheus ou dix fois de suite n'est notifiée qu'une fois
Regroupement50 instances en panne = une seule notification « 50 instances down »
RoutageL'alerte de la base de données part vers l'équipe DBA, celle du front vers l'équipe web
SilencesCouper temporairement des notifications (maintenance)
InhibitionsTaire les alertes secondaires quand une alerte principale est active
Intervalles de tempsNe pas réveiller la nuit pour une alerte non urgente

2. Le cycle de vie d'une alerte #

Pending, firing, resolved.

Les états #

Cycle de vie
Le paramètre for évite d'alerter sur un pic de quelques secondes.
groups:
  - name: disponibilite
    rules:
      - alert: InstanceDown
        expr: up == 0
        for: 5m                 # doit rester vraie 5 min avant de passer en firing
        keep_firing_for: 2m     # évite le clignotement firing/resolved
        labels:
          severity: critical
          team: plateforme
        annotations:
          summary: "{{ $labels.instance }} ne répond plus"
          runbook_url: https://wiki.example.org/runbooks/instance-down
À savoir : Quand l'expression redevient fausse, Prometheus envoie l'alerte avec une date de fin : Alertmanager notifie alors la résolution si le récepteur a send_resolved: true (valeur par défaut pour la plupart des intégrations).

3. Installer Alertmanager #

Un binaire, un fichier de configuration.

Lancement #

docker run -d --name alertmanager -p 9093:9093 \
  -v $PWD/alertmanager.yml:/etc/alertmanager/alertmanager.yml \
  prom/alertmanager:latest
# prometheus.yml : où envoyer les alertes
alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]
rule_files: ["rules/*.yml"]

L'interface web (:9093) liste les alertes reçues, leurs groupes et les silences. L'outil en ligne de commande amtool fait la même chose depuis un terminal.

Articles liés

É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'…

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