Alertmanager : Routage et notification des alertes

Prometheus détecte un problème, mais comment êtes-vous prévenu ? Alertmanager reçoit les alertes de Prometheus et les route vers les bons canaux (Slack, email, PagerDuty, webhook…). Il gère aussi le groupage (éviter 100 notifications pour le même problème) et les silences (maintenance planifiée).

Ce guide vous permet de configurer Alertmanager en 15 minutes : de l’installation aux premières notifications Slack.

Ce que fait Alertmanager

Architecture Alertmanager

Fonction	Description
Routing	Envoie chaque alerte au bon destinataire selon ses labels
Grouping	Combine plusieurs alertes similaires en une seule notification
Silences	Désactive temporairement des alertes (maintenance)
Inhibition	Une alerte critique masque les alertes mineures liées
Déduplication	Évite d’envoyer la même alerte plusieurs fois

# Créer la config minimale
cat > alertmanager.yml << 'EOF'
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'default'

receivers:
  - name: 'default'
    webhook_configs:
      - url: 'http://localhost:5001/alert'
        send_resolved: true
EOF

# Lancer Alertmanager
docker run -d --name alertmanager \
  -p 9093:9093 \
  -v $(pwd)/alertmanager.yml:/etc/alertmanager/alertmanager.yml \
  prom/alertmanager:v0.28.0 \
  --config.file=/etc/alertmanager/alertmanager.yml

# Avec le chart prometheus-community/kube-prometheus-stack
helm upgrade prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --set alertmanager.enabled=true \
  --set alertmanager.service.type=NodePort \
  --set alertmanager.service.nodePort=30093

Alertmanager est inclus dans kube-prometheus-stack.

Vérification : Accédez à http://localhost:9093 pour voir l’interface web.

Configuration par l’exemple

Notification Slack

global:
  slack_api_url: 'https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXX'
  resolve_timeout: 5m

route:
  receiver: 'slack-notifications'
  group_by: ['alertname', 'namespace']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

receivers:
  - name: 'slack-notifications'
    slack_configs:
      - channel: '#alerts'
        send_resolved: true
        title: '{{ .Status | toUpper }}: {{ .CommonLabels.alertname }}'
        text: >-
          {{ range .Alerts }}
          *Severity:* {{ .Labels.severity }}
          *Description:* {{ .Annotations.description }}
          {{ end }}

Notification email

global:
  smtp_smarthost: 'smtp.gmail.com:587'
  smtp_from: 'alertmanager@example.com'
  smtp_auth_username: 'alertmanager@example.com'
  smtp_auth_password: 'app-password'

receivers:
  - name: 'email-team'
    email_configs:
      - to: 'oncall@example.com'
        send_resolved: true

Routing avancé

Dirigez les alertes vers différentes équipes selon leur sévérité ou namespace :

route:
  receiver: 'default'
  routes:
    # Alertes critiques → PagerDuty
    - match:
        severity: critical
      receiver: 'pagerduty'
      continue: false

    # Production → Slack #prod-alerts
    - match:
        namespace: production
      receiver: 'slack-prod'

    # Développement → email équipe dev
    - match_re:
        namespace: dev|staging
      receiver: 'email-dev'

receivers:
  - name: 'default'
    slack_configs:
      - channel: '#alerts-default'

  - name: 'pagerduty'
    pagerduty_configs:
      - service_key: 'xxxxx'

  - name: 'slack-prod'
    slack_configs:
      - channel: '#prod-alerts'

  - name: 'email-dev'
    email_configs:
      - to: 'dev-team@example.com'

Créer des règles d’alerte (Prometheus)

Les alertes sont définies dans Prometheus, pas dans Alertmanager. Exemple :

groups:
  - name: application
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
          /
          sum(rate(http_requests_total[5m])) by (service)
          > 0.05
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Taux d'erreur élevé sur {{ $labels.service }}"
          description: "Le service {{ $labels.service }} a un taux d'erreur de {{ $value | humanizePercentage }}."

      - alert: PodNotReady
        expr: kube_pod_status_ready{condition="false"} == 1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Pod {{ $labels.pod }} non ready"
          description: "Le pod {{ $labels.pod }} dans {{ $labels.namespace }} n'est pas ready depuis 5 minutes."

Silences : désactiver temporairement

Pendant une maintenance planifiée, créez un silence pour éviter les alertes :

Accédez à l’interface : http://localhost:9093/#/silences
Cliquez “New Silence”
Définissez les matchers : labels qui identifient les alertes à silencer
- Ex: alertname=“NodeDown”, instance=“node-maintenance.example.com”
Définissez la durée : date/heure de début et fin
Ajoutez un commentaire : “Maintenance planifiée serveur-01”
Créez le silence

Via API :

curl -X POST http://localhost:9093/api/v2/silences \
  -H "Content-Type: application/json" \
  -d '{
    "matchers": [{"name": "alertname", "value": "NodeDown", "isRegex": false}],
    "startsAt": "2026-02-08T10:00:00Z",
    "endsAt": "2026-02-08T14:00:00Z",
    "createdBy": "admin",
    "comment": "Maintenance serveur"
  }'

Inhibitions : éviter le bruit

Une alerte critique peut masquer les alertes warning associées :

inhibit_rules:
  # Si un nœud est down, masquer les alertes des pods sur ce nœud
  - source_match:
      alertname: NodeDown
    target_match:
      alertname: PodNotReady
    equal: ['node']

  # Les alertes critiques masquent les warnings du même service
  - source_match:
      severity: critical
    target_match:
      severity: warning
    equal: ['alertname', 'namespace']

Dépannage

Symptôme	Cause probable	Solution
Pas de notification	Receiver mal configuré	Vérifier les credentials Slack/email
Alertes en double	group_by trop spécifique	Élargir les labels de groupage
Alertes qui ne se résolvent pas	send_resolved: false	Ajouter send_resolved: true
Interface web vide	Prometheus ne pousse pas	Vérifier alertmanagers dans prometheus.yml

Test de la config :

amtool check-config alertmanager.yml

Tester une notification :

# Envoyer une alerte de test
curl -X POST http://localhost:9093/api/v2/alerts \
  -H "Content-Type: application/json" \
  -d '[{
    "labels": {"alertname": "TestAlert", "severity": "warning"},
    "annotations": {"summary": "Test notification"}
  }]'

Bonnes pratiques

Routing par sévérité — critical → PagerDuty, warning → Slack, info → email digest
Groupage intelligent — group_by: [‘alertname’, ‘namespace’] évite le spam
repeat_interval adapté — 1h minimum pour éviter de harceler l’équipe
Templates lisibles — personnalisez les messages pour être actionnable
Testez les silences — vérifiez qu’ils fonctionnent AVANT la maintenance

À retenir

Alertmanager route les alertes de Prometheus vers les bons canaux
Grouping combine les alertes similaires (même alerte, plusieurs instances)
Silences désactivent temporairement les alertes (maintenance)
Inhibitions masquent les alertes mineures quand une critique est active
Les règles d’alerte sont dans Prometheus, pas dans Alertmanager

Prochaines étapes

TP Alerting Kubernetes Configurez Alertmanager avec kube-prometheus-stack

Prometheus Créez des règles d'alerte PromQL

Grafana Alerting Alternative : alertes directement dans Grafana

Runbooks Documentez les actions à entreprendre pour chaque alerte