Der Alertmanager ist die Alarmzentrale neben Prometheus. Prometheus selbst wertet Regeln aus, der Alertmanager übernimmt alles danach: Er gruppiert, drosselt, verteilt und schaltet Alarme still. Ohne diese Instanz würde jede ausgelöste Regel sofort eine eigene Nachricht verschicken – bei einem Ausfall von zwanzig Maschinen also zwanzig Mails in einer Minute.
Die vier Kernfunktionen
- Grouping: Mehrere zusammengehörige Alarme werden zu einer Benachrichtigung zusammengefasst. Fällt ein Cluster aus, kommt eine Mail – nicht zwanzig.
- Inhibition: Ein Alarm unterdrückt einen anderen. Ist der Host nicht erreichbar, werden die einzelnen Dienst-Alarme darauf nicht zusätzlich verschickt.
- Silences: Für geplante Wartung lassen sich Alarme zeitgesteuert stumm schalten, mit Kommentar und Ablaufdatum.
- Routing: Über einen Entscheidungsbaum aus
routeundmatch-Regeln landen Alarme beim richtigen Empfänger – Datenbank-Alarme beim DB-Team, Verfügbarkeitsalarme beim Bereitschaftsdienst.
Konfiguration und Empfänger
route:
receiver: bereitschaft
group_by: [alertname, cluster]
group_wait: 30s
repeat_interval: 4h
routes:
- matchers: ['severity="critical"']
receiver: pager
receivers:
- name: pager
webhook_configs:
- url: http://pager.internal/alertDie Parameter group_wait, group_interval und repeat_interval steuern das Timing: kurz warten, damit verwandte Alarme zusammenkommen; nicht zu früh erneut melden; nach einer Frist erinnern.
Als Empfänger dienen E-Mail, Webhook, PagerDuty, Slack, Telegram und weitere Integrationen. Der Zustand wird über den Endpunkt /-/healthy und die Oberfläche auf Port 9093 geprüft. In ernsthaften Setups läuft der Alertmanager geclustert, damit auch bei Ausfall eines Knotens Meldungen herausgehen – und Alarme sind mit SLA und Bereitschaftsplan verzahnt, nicht bloß technisches Beiwerk.
Verwandte Grundlagen: Monitoring, Node Exporter, Observability, Monitoring mit Prometheus und Grafana.