Zum Inhalt

Zu viele Benachrichtigungen

Das Gegenteil des vorigen Problems: das Postfach oder der Slack-Channel läuft über — bei einem größeren Ausfall, bei einem instabilen Check, oder einfach im Dauerbetrieb. Fünf Hebel, die sich kombinieren lassen.

1. Gruppierung prüfen

Wenn 50 Checks gleichzeitig kritisch werden, willst du eine Sammel-Meldung, nicht 50 Einzelmails. Die Gruppierung ist standardmäßig an und wird pro Tenant eingestellt: Tenants → Tenant aufklappen → Alert-Gruppierung. Drei Stellschrauben:

  • Gruppieren nach — Host (Vorgabe), Host + Severity oder Service-Name.
  • Wartezeit — nach dem ersten Alarm so lange sammeln, dann eine Meldung (Vorgabe 30 s).
  • Mindestabstand — frühestens so lange nach der letzten Meldung ein Update zur selben Gruppe (Vorgabe 5 min). Kommen dir Updates zu dicht, ist das der Regler.

Fallen mehrere Hosts gleichzeitig aus, fasst dieselbe Wartezeit sie zu einer „Hosts nicht erreichbar"-Meldung zusammen. Erinnerungen an offene Probleme stellst du dagegen pro Alert-Regel ein. Prüfe auch, ob bei einzelnen Hosts die Gruppierung abgeschaltet wurde (Host verwalten → Alert-Gruppierung) — deren Meldungen gehen einzeln raus.

Auch Eskalationsstufen werden pro Tick nach (Tenant, Stufe, Kanal-Satz) gruppiert — feuern mehrere Services gleichzeitig dieselbe Eskalationsstufe, bekommst du eine Sammel-Meldung, keine Einzel-Mail pro Service.

Details: Alert Rules → Gruppierung.

2. Wartezeit pro Status erhöhen

Feuert eine Regel zu schnell auf kurze Blips (z. B. ein Netzwerk-Hänger von 20 Sekunden)? Erhöhe die Wartezeit für den betroffenen Status (Critical/Warning/No Data/Unknown) — ein Problem muss dann länger durchgehend bestehen, bevor überhaupt benachrichtigt wird. Ein kurzer Ausreißer, der sich vorher auflöst, löst dann gar keine Mail mehr aus.

Details: Alert Rules → Wartezeit pro Status.

3. Flapping erkennen statt bekämpfen

Springt ein Service sehr schnell mehrfach zwischen zwei Status hin und her (Flapping — z. B. ein WLAN-Access-Point, der ständig kurz weg ist und wiederkommt), erzeugt das normalerweise eine Kaskade aus Alarm- und Recovery-Mails. Vesana erkennt dieses Muster automatisch und schickt stattdessen eine „Flapping"-Meldung, später eine „Flapping beendet"-Meldung — der reguläre Alarm/Recovery-Zyklus bleibt für die Dauer des Flatterns pausiert.

Bekommst du trotzdem viele Einzelmails bei einem instabilen Service: prüfe, ob das Intervall des Checks zu lang ist (Flapping-Erkennung braucht eine gewisse Anzahl Status-Wechsel in kurzer Zeit) oder ob die Regel auf ein sehr enges Zeitfenster reagiert.

4. Eskalation begrenzen

Eine mehrstufige Eskalation kann selbst zur Quelle werden, wenn zu viele Stufen zu eng getaktet sind:

escalation:
  - after: 0min
    channels: [ops-email]
  - after: 15min
    channels: [ops-push, manager-email]
  - after: 60min
    channels: [oncall-pager, ceo-sms]

Prüfe, ob die erste Stufe wirklich sofort feuern muss (after: 0min), oder ob eine kleine Verzögerung schon reicht, um kurzlebige Probleme abzufangen, bevor der Manager involviert wird. Eskalation stoppt automatisch, sobald der Alert acknowledged wird oder sich auflöst — ein rechtzeitiges ACK ist oft der schnellste Weg, weitere Eskalationsstufen zu verhindern.

5. Wartungsfenster statt manuellem Stumm-Schalten

Steht ein geplanter Reboot, eine Migration oder ein Wartungsfenster an, bei dem bekannt ist, dass mehrere Checks vorübergehend rot werden: eine Downtime anlegen statt hinterher die Mail-Flut zu ertragen oder Regeln temporär zu deaktivieren. Während einer aktiven Downtime werden Alerts gar nicht erst versandt — auch nicht verspätet nachgeholt.

Presets (1 Std/4 Std/8 Std/24 Std/Bis Tagesende/1 Woche) und Bulk-Anlage über Tags machen das auch für größere Wartungsfenster schnell.

Details: Downtimes.

Zusätzlich: Regel-Scope prüfen

Manchmal ist die eigentliche Ursache eine zu breite Regel — z. B. eine Regel ohne Host-/Tag-Filter, die versehentlich auf viel mehr Services matcht als beabsichtigt. Nutze den Test-Button im Regel-Editor, bevor du eine neue oder geänderte Regel speicherst — er zeigt, welche Hosts/Services tatsächlich betroffen wären.

Anschluss