Une règle d’alerte bien écrite (voir l’article sur les alertes symptômes vs causes) décide quand déclencher une alerte, mais ne décide rien de ce qui se passe ensuite. Sans configuration explicite d’Alertmanager, un seul incident qui affecte 50 pods simultanément génère 50 notifications identiques, une tempête qui noie le signal utile sous son propre volume.

Le routage : diriger chaque alerte vers la bonne équipe

Alertmanager route chaque alerte reçue à travers un arbre de règles (route), qui décide de la destination (Slack, PagerDuty, email) selon les labels de l’alerte, pas selon son contenu textuel.

route:
  receiver: default
  routes:
    - match:
        team: platform
      receiver: platform-pagerduty
    - match:
        team: billing
      receiver: billing-slack

Sans arbre de routage explicite, toutes les alertes atterrissent sur le même canal, quelle que soit l’équipe réellement concernée : un signal utile pour une équipe devient du bruit pour toutes les autres qui reçoivent la même notification sans jamais pouvoir agir dessus.

Le groupement : une notification, pas cinquante

Le groupement (group_by) rassemble plusieurs alertes qui partagent les mêmes valeurs sur un ensemble de labels en une seule notification, plutôt que d’en envoyer une par alerte individuelle.

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m

Cinquante pods qui échouent leur readiness probe en même temps, tous rattachés au même alertname et au même cluster, produisent une seule notification groupée listant les cinquante pods concernés, au lieu de cinquante alertes distinctes qui saturent le canal de notification et rendent le signal réel (« quelque chose affecte tout le cluster ») moins visible que le bruit qu’il génère.

group_wait fixe le délai avant la première notification d’un nouveau groupe (le temps de rassembler d’autres alertes similaires avant d’envoyer) ; group_interval fixe le délai minimum entre deux notifications pour un groupe déjà notifié.

L’inhibition : supprimer l’alerte qui ne dit rien de nouveau

L’inhibition supprime une alerte quand une autre, jugée plus significative, est déjà active, évitant de notifier une conséquence attendue d’une cause déjà signalée.

inhibit_rules:
  - source_match:
      alertname: NodeDown
    target_match:
      alertname: PodNotReady
    equal: ['node']

Cette règle supprime toute alerte PodNotReady sur un nœud déjà signalé NodeDown : les pods de ce nœud ne répondent évidemment plus, une conséquence directe et attendue, pas une information supplémentaire qui mérite sa propre notification. Sans inhibition, un nœud qui tombe génère une alerte pour le nœud lui-même, plus une alerte par pod qui y tournait, un multiplicateur de bruit pour un seul incident réel.

Les silences : couper temporairement, sans toucher à la configuration

Un silence désactive temporairement la notification d’alertes correspondant à un motif précis, sans modifier la configuration de routage ni les règles elles-mêmes, typiquement pendant une fenêtre de maintenance planifiée.

# Silence toutes les alertes du cluster "staging"
# pendant 2 heures, sans toucher à la configuration
amtool silence add cluster=staging --duration=2h

Un silence expire automatiquement à la fin de sa durée, contrairement à une modification manuelle de règle qu’on oublie parfois de rétablir après une maintenance.

À retenir

Une règle d’alerte bien écrite ne suffit pas à elle seule : sans routage explicite, toutes les alertes atterrissent au même endroit ; sans groupement, un incident qui touche plusieurs cibles simultanément génère une notification par cible plutôt qu’une seule regroupée ; sans inhibition, une conséquence attendue d’une cause déjà signalée génère son propre bruit. Les silences gèrent les fenêtres de maintenance sans toucher à la configuration permanente. Ces quatre mécanismes, combinés, transforment un système d’alerting techniquement fonctionnel en un système réellement exploitable en astreinte, un des piliers d’une fiabilité et observabilité qui ne noie jamais le signal sous son propre volume.