RousselTMLEARNING

Observabilité

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 les alertes secondaires) et intervalles de temps (heures ouvrées, maintenance).

1. Les silences #

Couper temporairement.

Avec amtool #

export ALERTMANAGER_URL=http://localhost:9093   # ou --alertmanager.url

# Créer un silence de 2 h pour la maintenance d'une base
amtool silence add instance="db-1:9100" --duration=2h \
  --author="martin" --comment="Maintenance planifiée CHG-1234"

amtool silence query                 # lister les silences actifs
amtool silence query -e              # y compris expirés
amtool silence expire <id>           # lever un silence
amtool alert query                   # alertes actives (non silencées)

Un silence est un ensemble de matchers et une période. Les alertes correspondantes restent visibles dans l'interface (marquées silenced) mais ne sont plus notifiées.

Erreur Courante : Un silence trop large (severity=~".*") peut masquer un incident réel pendant des heures. Limitez toujours un silence à une instance ou un service, avec une durée courte et un commentaire qui cite le ticket de changement.

2. Les inhibitions #

Une seule cause, une seule alerte.

Principe #

Quand un datacenter entier est injoignable, inutile de recevoir 300 alertes « service down ». Une règle d'inhibition tait les alertes cibles tant qu'une alerte source est active, à condition qu'elles partagent les labels listés dans equal.

inhibit_rules:
  # Une alerte critique tait la même alerte en warning
  - source_matchers: ['severity="critical"']
    target_matchers: ['severity="warning"']
    equal: [alertname, instance]
  # Le cluster est injoignable : on tait toutes ses autres alertes
  - source_matchers: ['alertname="ClusterUnreachable"']
    target_matchers: ['alertname!="ClusterUnreachable"']
    equal: [cluster]
À savoir : L'interface d'Alertmanager affiche les alertes inhibées avec le filtre Inhibited : utile pour vérifier qu'une règle n'est pas trop large.

3. Les intervalles de temps #

Respecter le sommeil des équipes.

Heures ouvrées et périodes de gel #

time_intervals:
  - name: heures-ouvrees
    time_intervals:
      - weekdays: ['monday:friday']
        times: [{ start_time: '09:00', end_time: '18:00' }]
        location: Europe/Paris
  - name: nuit-et-week-end
    time_intervals:
      - weekdays: ['saturday', 'sunday']
      - times: [{ start_time: '18:00', end_time: '24:00' }, { start_time: '00:00', end_time: '09:00' }]
        location: Europe/Paris

route:
  receiver: defaut
  routes:
    - matchers: ['severity="warning"']
      receiver: equipe-mail
      mute_time_intervals: [nuit-et-week-end]     # pas de warning la nuit
    - matchers: ['severity="critical"']
      receiver: astreinte                          # le critique sonne 24 h/24

active_time_intervals fait l'inverse : la route n'est active que pendant les intervalles listés (par exemple, un canal de support ouvert seulement en journée).

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