RousselTMLEARNING

Observabilité

Haute disponibilité et exploitation d'Alertmanager

Monter un cluster Alertmanager hautement disponible (gossip), configurer Prometheus pour tous les membres, surveiller la chaîne d'alerte avec un Watchdog et diagnostiquer les notifications perdues.

1. Le mode cluster #

Pas de répartiteur de charge entre Prometheus et Alertmanager.

Principe #

Cluster Alertmanager
Les membres partagent silences et journal de notifications : un seul envoie.

Les instances d'Alertmanager forment un cluster par gossip (port 9094) et partagent les silences et le journal des notifications. Chaque Prometheus doit envoyer ses alertes à tous les membres ; ceux-ci se coordonnent pour qu'une seule notification parte (avec un léger décalage par position dans le cluster).

alertmanager --config.file=alertmanager.yml \
  --cluster.listen-address=0.0.0.0:9094 \
  --cluster.peer=alertmanager-1:9094 --cluster.peer=alertmanager-2:9094

Côté Prometheus #

alerting:
  alertmanagers:
    - static_configs:
        - targets: [alertmanager-1:9093, alertmanager-2:9093, alertmanager-3:9093]
Erreur Courante : Ne mettez jamais un répartiteur de charge entre Prometheus et Alertmanager : chaque instance doit recevoir toutes les alertes, sinon la déduplication ne fonctionne plus.

2. Surveiller la chaîne d'alerte #

Qui alerte quand l'alerting tombe ?

Le Watchdog #

Une alerte toujours active (vector(1)) est envoyée en continu vers un service externe (dead man's switch : healthchecks.io, Cronitor, PagerDuty heartbeat...). Si les notifications cessent, c'est le service externe qui prévient : Prometheus, Alertmanager ou le réseau est en panne.

- alert: Watchdog
  expr: vector(1)
  labels: { severity: none }
  annotations: { summary: "Alerte de contrôle : doit toujours être active" }

Métriques utiles #

MétriqueUsage
alertmanager_notifications_failed_totalÉchecs d'envoi par intégration
alertmanager_notification_latency_secondsDélai d'envoi
alertmanager_cluster_membersTaille du cluster vue par chaque membre
prometheus_notifications_dropped_totalAlertes que Prometheus n'a pas pu transmettre
alertmanager_config_last_reload_successfulDernier rechargement de configuration réussi ?

3. Diagnostiquer #

« Je n'ai pas reçu l'alerte ».

Méthode #

  1. La règle est-elle firing dans Prometheus (/alerts) ou encore pending ?
  2. Prometheus a-t-il pu joindre Alertmanager (prometheus_notifications_errors_total) ?
  3. L'alerte est-elle visible dans Alertmanager ? Est-elle silenced ou inhibited ?
  4. Quelle route a-t-elle prise (amtool config routes test) ?
  5. L'envoi a-t-il échoué (journaux, alertmanager_notifications_failed_total) ?
amtool check-config alertmanager.yml       # valider avant de déployer
curl -X POST localhost:9093/-/reload         # recharger sans redémarrer
amtool config routes show                    # afficher l'arbre
amtool alert add alertname=Test severity=critical team=db \
  --annotation=summary="Alerte de test"      # injecter une alerte de test

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 …

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

Pour aller plus loin