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 (ist sie dort per Schalter abgeschaltet, geht jede Meldung einzeln raus): 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. Kommen sie zurück, beginnt eine Anlaufphase (Vorgabe 30 min, Admin → Benachrichtigungen → E-Mail & Meldungen): Probleme, die erst mit dem Neustart entstehen — Eventlog-Fehler, „Unexpected Shutdown", Dienste, die noch hochfahren — werden so lange gesammelt. Was sich bis dahin erledigt, wird nicht gemeldet; der Rest kommt als eine Meldung „Alarm nach Wiederanlauf" für alle zurückgekehrten Hosts. 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 Check sehr schnell mehrfach zwischen zwei Statussen hin und her (Flapping — z. B. ein WLAN-Access-Point, der ständig kurz weg ist und wiederkommt), entsteht keine Kaskade aus Alarm- und Entwarnungs-Mails: Vesana schickt einmalig „Instabil (flappt)" und später „Wieder stabil". Ein Klick auf das Flapping-Badge am Check zeigt, ob dafür eine Meldung rausgeht und an welche Kanäle.

Bekommst du trotzdem viele Einzelmails bei einem instabilen Check: Erreicht er die Wartezeit der Regel jedes Mal am Stück, ist er aus Sicht der Regel wirklich mehrfach ausgefallen. Dann hilft eine längere Wartezeit (Punkt 2) oder ein Blick auf den Wiederholungs-Modus der Regel (Punkt 4).

4. Wiederholungen und Eskalation prüfen

  • Wiederholte Meldungen: Der Modus der Regel unter „Wiederholte Meldungen zu einem offenen Alarm" entscheidet, ob ein offenes Problem erneut meldet. Vorgabe ist „Nur bei Verschlimmerung"; „Bei jeder Überschreitung" und „Regelmäßig erinnern" melden zusätzlich — frühestens im Abstand „Frühestens alle". Treffen mehrere Regeln denselben Check, gilt der gesprächigste Modus.
  • Eskalation: Zu viele, zu eng getaktete Stufen werden selbst zur Quelle. Jede Stufe wartet mindestens 1 Minute nach der ersten Benachrichtigung, die Zeiten müssen streng steigen. Prüfe, ob die erste Stufe wirklich nach wenigen Minuten den nächsten Kreis informieren muss. Die Eskalation pausiert, sobald der Alarm quittiert ist, und endet, wenn sich das Problem auflöst — ein rechtzeitiges ACK ist oft der schnellste Weg, weitere Stufen zu verhindern.

Details: Alert Rules → Wiederholte Meldungen, Alert Rules → Eskalation.

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 vorübergehend zu deaktivieren. Während einer aktiven Downtime werden Alarme gar nicht erst versandt; besteht ein Problem nach Ende des Fensters weiter, wirst du dann informiert.

Schnellauswahl (15 Min bis 1 Monat, inkl. „Bis Tagesende" und „Bis morgen 08:00"), mehrere Geräte oder der ganze Tenant in einem Fenster sowie wiederkehrende Fenster machen das auch für größere Wartungen schnell.

Details: Downtimes.

Zusätzlich: Regel-Geltungsbereich prüfen

Manchmal ist die eigentliche Ursache eine zu breite Regel — z. B. Geltungsbereich „Alle" mit allen vier Statussen, die auf viel mehr Checks trifft als beabsichtigt. Die Treffer-Vorschau im Regel-Editor („Matcht aktuell N Checks", mit Beispielen) zeigt das schon beim Bearbeiten; einzelne Hosts, Collectors oder Checks nimmst du über die Ausnahmen heraus.

Anschluss