Alarm-Routing: Gruppierung, Unterdrückung, Stummschaltungen und Eskalationsrichtlinien

Ziel

Jeden Alarm genau der Person oder dem Kanal zustellen, der darauf reagieren kann, als eine Benachrichtigung pro Vorfall statt einer pro Instanz, mit einem definierten Weg für den Fall, dass niemand antwortet.

Voraussetzungen

Alarme, die Labels für Severity, Team und Service tragen; eine Routing-Komponente (die Alertmanager-Dokumentation beschreibt Deduplizierung, Gruppierung, Routing an Empfänger, Stummschaltung und Unterdrückung); sowie ein Paging-Dienst mit Eskalationsrichtlinien.

Schritte

1. Zuerst den Label-Vertrag festlegen: severity (page, ticket), team, service. Routing gleicht anhand von Labels ab; ein Alarm ohne diese landet beim Standardempfänger und gehört niemandem.
2. Den Routing-Baum aufbauen: einen Root-Empfänger für den nicht zugeordneten Rest, Kind-Routen pro Team und darin einen Page-Empfänger für severity=page sowie einen Ticket- oder Chat-Empfänger für den Rest. continue: true nur dort verwenden, wo ein Alarm absichtlich zwei Empfänger erreichen muss.
3. Nach alertname und service (oder Cluster) gruppieren, damit ein Ausfall mit fünfzig Instanzen eine Benachrichtigung erzeugt, die alle fünfzig auflistet. group_wait nahe am dokumentierten Beispiel (30s) setzen: Zu kurz, warnt die Dokumentation, sendet eine unvollständige erste Benachrichtigung und lässt Alarme durch, die ein später eintreffender Quellalarm unterdrückt hätte; zu lang verzögert die erste Benachrichtigung. group_interval für Aktualisierungen einer bestehenden Gruppe und repeat_interval (das dokumentierte Beispiel verwendet 4h) für das erneute Senden einer ungelösten Gruppe setzen.
4. Unterdrückungsregeln für bekannte Ursache-Symptom-Paare schreiben: Wenn der Alarm für ein nicht erreichbares Cluster auslöst, jeden Alarm zu diesem Cluster stummschalten; der Quellalarm muss in den abgleichenden Labels denselben Wert tragen.
5. Für geplante Wartung Stummschaltungen mit Ablaufzeit und Kommentar verwenden, und Zeitintervalle auf Routen für wiederkehrende ruhige Stunden bei Alarmen auf Ticket-Ebene; einen Alarm auf Page-Ebene nie ohne ein Ticket stummschalten, das begründet, warum.
6. Die Eskalationsrichtlinie im Paging-Dienst definieren: Die erste Regel benachrichtigt die Bereitschaftsperson, ein Eskalations-Timeout gibt ihr eine feste Anzahl Minuten zum Bestätigen, Lösen oder Umverteilen, danach benachrichtigt die nächste Regel die Vertretung, wobei sich die Richtlinie optional wiederholt. Das Bestätigen stoppt die Eskalation; nur das Lösen beendet den Vorfall.
7. Jedes Quartal und nach jeder Änderung am Baum mit einem synthetischen Alarm pro Route End-to-End testen: richtiger Empfänger, eine Benachrichtigung, Eskalation erreicht die Vertretung, wenn die primäre Person ignoriert hat.

Erwartetes Ergebnis

Ein Page nennt einen Dienst und listet dessen betroffene Instanzen, erreicht die zuständige Bereitschaftsperson innerhalb der Gruppierungswartezeit und erreicht automatisch eine zweite Person, wenn die erste nicht bestätigt.

Grenzen und Prüfbasis

Die hier genannten Zeiten sind dokumentierte Standardwerte und Beispiele, keine abgestimmten Werte; jedes Team legt seine eigenen ausgehend vom Eskalations-Timeout rückwärts fest. Unterdrückung funktioniert nur, wenn die Labels über die Alarmquellen hinweg konsistent sind. Ein Routing-Baum ist Konfiguration, die driftet: Er braucht dieselbe Überprüfung wie Code.