Alertmanager

Fiche express
Type	Routage, déduplication et regroupement des alertes issues de Prometheus
Éditeur	Projet CNCF (sous-projet Prometheus)
Licence	Open source (Apache 2.0)
Intégrations	E-mail, Slack, PagerDuty, Opsgenie, webhook générique...
Voir aussi	Prometheus · Grafana

Alertmanager est le composant compagnon de Prometheus chargé de tout ce qui se passe après qu'une alerte a été déclenchée : recevoir les alertes firing envoyées par un ou plusieurs serveurs Prometheus, les dédupliquer, les regrouper, les faire éventuellement taire, puis les router vers le bon canal de notification. Prometheus lui-même ne notifie jamais personne : il se contente d'évaluer des règles et de transmettre leur résultat à Alertmanager.

Règles côté Prometheus, routage côté Alertmanager

La séparation des responsabilités entre les deux composants est stricte et volontaire :

• côté Prometheus — les alerting rules définissent quand une alerte doit se

 déclencher (une expression PromQL, une durée for avant passage à
 firing) et lui attachent des labels et annotations descriptifs.

• côté Alertmanager — la configuration de routage décide, une fois l'alerte reçue,

 qui doit être notifié, comment (canal), à quelle fréquence et avec quel
 regroupement vis-à-vis d'autres alertes similaires.

<mermaid> flowchart LR

   P1[Prometheus A] -->|alertes firing
via API| AM[Alertmanager]
   P2[Prometheus B] -->|alertes firing
via API| AM
   AM -->|groupées / dédupliquées /
filtrées par route| E[E-mail]
   AM --> S[Slack]
   AM --> PD[PagerDuty]
   AM --> W[Webhook générique]

</mermaid>

Ce découplage permet à plusieurs serveurs Prometheus (par exemple un par datacenter ou par équipe) de partager un même Alertmanager central, avec une politique de notification uniforme.

Cycle de vie d'une alerte

1. L'expression d'une alerting rule devient vraie côté Prometheus : l'alerte passe

 à l'état pending.

1. Si la condition reste vraie au-delà de la durée for configurée, l'alerte passe

 à firing et Prometheus la transmet à Alertmanager (par défaut toutes les 15 à
 30 secondes tant qu'elle reste active).

1. Alertmanager applique son arbre de routage, ses règles de regroupement et d'inhibition, puis

 envoie (ou non) une notification.

1. Quand la condition redevient fausse côté Prometheus, l'alerte est retirée ; selon la

 configuration du récepteur, une notification de résolution peut être envoyée.

Regroupement, inhibition, silences

• Grouping — plusieurs alertes partageant certains labels (par exemple toutes les

 alertes TauxErreurEleve d'un même cluster) sont regroupées dans une
 seule notification plutôt que d'en envoyer une par alerte individuelle, pour éviter le
 déluge de notifications lors d'un incident qui touche de nombreuses cibles à la fois.

• Inhibition — permet de faire taire automatiquement certaines alertes quand une autre

 alerte, plus générale, est déjà active (typiquement : ne pas notifier chaque service en échec
 d'un nœud si l'alerte « nœud injoignable » est elle-même déjà active).

• Silences — mise en sourdine manuelle et temporaire d'alertes correspondant à un

 ensemble de labels, le temps d'une maintenance planifiée par exemple, via l'UI web ou l'API.

Configuration

route:
  receiver: 'defaut-email'
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers:
        - severity="critical"
      receiver: 'astreinte-pagerduty'
      continue: true
    - matchers:
        - team="infra"
      receiver: 'slack-infra'

receivers:
  - name: 'defaut-email'
    email_configs:
      - to: 'ops@example.org'
        from: 'alertmanager@example.org'
        smarthost: 'smtp.example.org:587'

  - name: 'astreinte-pagerduty'
    pagerduty_configs:
      - service_key: "<clé d'intégration PagerDuty>"

  - name: 'slack-infra'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/...'
        channel: '#alertes-infra'

inhibit_rules:
  - source_matchers:
      - alertname="NoeudInjoignable"
    target_matchers:
      - severity="warning"
    equal: ['cluster', 'node']

• group_wait — délai initial avant d'envoyer la première notification d'un nouveau

 groupe, pour laisser le temps à d'autres alertes proches de le rejoindre.

• group_interval — délai minimal entre deux notifications successives pour un même

 groupe déjà notifié une première fois.

• repeat_interval — délai au-delà duquel une alerte toujours active est renotifiée même

 sans changement.

• routes — arbre de routage évalué du haut vers le bas ; continue: true

 permet à une alerte de correspondre à plusieurs routes plutôt de s'arrêter à la première
 correspondance.

Intégrations de notification

Alertmanager sait notifier nativement vers de nombreux canaux (e-mail, Slack, PagerDuty, Opsgenie, VictorOps, OpsGenie...) et, pour tout le reste, expose un mécanisme de webhook générique : n'importe quel système capable de recevoir un POST HTTP avec un payload JSON décrivant l'alerte peut être branché en récepteur, ce qui couvre en pratique l'intégration avec un outil de ticketing ou un système de supervision existant comme Centreon.

Haute disponibilité

Plusieurs instances d'Alertmanager peuvent être déployées en cluster : elles se synchronisent entre elles via un protocole de type gossip pour partager l'état des silences et des notifications déjà envoyées, ce qui évite les doublons de notification même si plusieurs serveurs Prometheus pointent vers plusieurs instances d'Alertmanager simultanément.

Voir aussi

• Prometheus — évaluation des règles d'alerte en amont, à l'origine des alertes reçues ici
• Grafana — peut également porter ses propres règles d'alerte (Grafana Alerting), à

 distinguer du couple Prometheus/Alertmanager décrit sur cette page