Zum Inhalt

Keine Benachrichtigung trotz rotem Check

Ein Check steht sichtbar auf CRITICAL oder WARNING, aber niemand hat eine Mail/Push/Slack-Nachricht bekommen. Das UI und der Alarm-Pfad sind entkoppelt — ein roter Check im Frontend heißt nicht automatisch „es wurde benachrichtigt". Gehe die Punkte in dieser Reihenfolge durch.

Schnellster Einstieg: Alerting → Aktive Alarme. Steht der Check dort, siehst du im Fahrplan, wann die erste Benachrichtigung fällig ist oder warum sie nie gesendet wurde. Steht er nicht dort, trifft keine aktive Regel, oder er ist in Downtime, im Info-Modus oder deaktiviert.

1. Wartezeit pro Status noch nicht abgelaufen?

Jede Alert-Rule hat vier eigene Wartezeiten (Critical/Warning/No Data/Unknown) — ein Problem muss diese Zeit lang durchgehend bestehen, bevor überhaupt eine Benachrichtigung fällig wird. Ist der Check erst seit kurzem rot, ist „noch keine Mail" oft einfach noch keine Fälligkeit.

Wichtig: Löst sich das Problem auf, bevor die Wartezeit abläuft, wird überhaupt nie benachrichtigt — nicht verspätet, sondern gar nicht. Das ist gewolltes Verhalten (kein Alarm für Ausreißer, die sich von selbst erledigen), fühlt sich beim ersten Mal aber oft wie ein Bug an.

Details: Alert Rules → Wartezeit pro Status.

2. Matcht überhaupt eine Regel?

Eine Alert-Rule wählt Checks über Tenant, Status-Filter, Geltungsbereich (Alle · Bestimmte Hosts/Collectors · Bestimmte Services · Host + Services) und Ausnahmen. Prüfe:

  • Gibt es im Tenant des Checks überhaupt eine aktive Regel? Die Alerting-Übersicht zählt „Tenants ohne aktive Regel".
  • Steht der aktuelle Status des Checks im Status-Filter der Regel (z. B. meldet eine Regel mit Critical + Unknown kein WARNING)?
  • Ist der Host oder Check per Ausnahme herausgenommen?
  • Im Regel-Editor zeigt die Treffer-Vorschau live „Matcht aktuell N Checks" mit Beispielen; im Check-Detail zeigt der Abschnitt Alarmierung, welche Regeln greifen und mit welchen Zeiten.
  • Gegenprobe über die echte Kette: Probealarm (Knopf über der Regel-Liste) — er läuft durch Regel-Zuordnung, Unterdrückung und Zustellung und zeigt pro Kanal, was passiert ist. Der Test-Knopf in der Regel-Zeile prüft dagegen nur, ob die Kanäle erreichbar sind.

Details: Alert Rules.

3. Downtime, Acknowledgement oder akzeptierte Ausnahme aktiv?

Drei Zustände unterdrücken Benachrichtigungen, ohne dass der Check-Status selbst sich ändert:

Zustand Wo sichtbar Wirkung
Downtime violette Downtime-Pille am Host/Check Alarme komplett unterdrückt, solange die Downtime aktiv ist
Acknowledged (ACK), Einstufung „Marked as error" Behandlung „In Arbeit" keine weiteren Benachrichtigungen, Eskalation pausiert
Akzeptierte Ausnahme, Einstufung „Marked as no error" „Accepted" zählt nicht als Problem, alarmiert nicht

Ein wichtiger Unterschied: „In Arbeit" hält den Check weiterhin als offenes Problem in Health-Score und Rollups, unterdrückt aber die Benachrichtigungen. Wird ein quittierter oder akzeptierter Check schlimmer als zum ACK-Zeitpunkt, bricht die Markierung automatisch — der Check wird wieder ein echtes, alarmierbares Problem.

Details: Acknowledgements, Downtimes.

4. Unterdrückt der Host selbst, ein Eltern-Host oder der Collector?

  • Eltern-Host (Dependency): Hängt der Check an einem Host, der von einem nicht erreichbaren Elternteil abhängt, unterdrückt Vesana bewusst die Alarme — sonst bekommst du bei einem toten Switch 40 Einzelalarme statt einem. Der Host-Kopf zeigt die Abhängigkeit als Chip („hängt an: …").
  • Host nicht erreichbar / Agent weg: Alarmiert der Erreichbarkeits-Check des Hosts oder schweigt sein Agent, kommt eine Host-Meldung („Host nicht erreichbar" bzw. „Agent meldet sich nicht") statt einer pro Check.
  • Collector offline: Fällt der Collector aus, kommt eine Meldung „Collector offline" — die No-Data-Symptome seiner Checks werden nicht einzeln gemeldet.

Ist die Ursache zurück und der Check weiterhin gestört, holt Vesana den Alarm nach.

Details: Dependencies & Inhibition, Reachability-Hint.

5. Anlaufphase nach einem Ausfall?

Kam der Host oder sein Collector gerade aus einem Ausfall zurück, hält Vesana Probleme, die erst mit dem Wiederanlauf entstanden sind, bis zum Ende der Anlaufphase zurück (Vorgabe 30 Minuten, Admin → Benachrichtigungen → E-Mail & Meldungen → Anlaufphase nach einem Ausfall). Was dann noch besteht, kommt als Sammel-Meldung „Alarm nach Wiederanlauf".

Details: Wenn-Dann-Referenz.

6. Neue oder reaktivierte Regel — Anti-Blast

Legst du eine neue Regel an oder schaltest eine deaktivierte wieder ein, während irgendwo schon seit Stunden ein Problem läuft, bleibt dieses Problem für die Regel stumm, bis es einmal behoben war und erneut auftritt. Das ist Absicht (eine frisch gespeicherte Regel soll nicht sofort eine Flut an Benachrichtigungen über alles bereits Laufende auslösen). Unter „Aktive Alarme" steht dann „nie gesendet — das Problem lief bereits, als die Regel aktiviert wurde".

7. Kanal selbst funktionsfähig?

Auch wenn Regel und Timing stimmen: der Kanal selbst kann kaputt sein.

  • Test senden in der Kanal-Zeile (Alerting → Kanäle) — schickt eine Testmeldung ohne echten Alarm und zeigt den Fehlertext des Dienstes.
  • Kanal deaktiviert? Ein deaktivierter Kanal bekommt nichts; auch ein Test schaltet ihn nicht wieder ein.
  • E-Mail ohne Mailserver: Ist kein SMTP eingerichtet, zeigen Kanal-Seite und Alerting-Übersicht eine rote Warnung, und jede Meldung an einen E-Mail-Kanal schlägt fehl. Einrichten: SMTP.
  • Webhook-Endpoint down oder Auth falsch? Prüfe Webhooks.
  • Kanal-Feinsteuerung der Regel: Welche Statusse ein Kanal bekommt und ob er Entwarnungen erhält, steht in der Regel pro Kanal und Stufe — ein Push-Kanal, der dort nur Critical bekommt, meldet kein WARNING. Am Kanal selbst gibt es keinen Filter.
  • Push: Der Kanal-Test nennt die Ziel-Benutzer und sagt ausdrücklich, wenn dein eigenes Konto nicht dabei ist. Push wird pro Gerät aktiviert (Einstellungen → Push); ob die Meldung auf dem Handy erscheint, entscheidet zudem das Betriebssystem (Akkusparen).
  • Zustellungen und Fehlversuche stehen unter Alerting → Aktive Alarme → Zustell-Protokoll und am Gerät unter Verlauf → Benachrichtigungen.

Details: Notification Channels.

8. Entwarnung bekommen, aber nie den ursprünglichen Alarm?

Entwarnungen gehen an genau die Kanäle, die beim ursprünglichen Alarm tatsächlich benachrichtigt wurden — nicht an die aktuell konfigurierten Kanäle der Regel. Wurde die Regel zwischen Alarm und Entwarnung geändert (z. B. ein Kanal entfernt), bekommt trotzdem der ursprüngliche Kanal die Entwarnung. Umgekehrt: ein neu hinzugefügter Kanal bekommt keine Entwarnung für einen Alarm, der vor seiner Hinzufügung ausgelöst hat.

Schnell-Checkliste

  • [ ] Wartezeit für diesen Status abgelaufen?
  • [ ] Treffer-Vorschau bzw. Abschnitt „Alarmierung" zeigt eine passende Regel?
  • [ ] Keine Downtime/ACK/Ausnahme aktiv?
  • [ ] Kein Eltern-Host, Agent- oder Collector-Ausfall als Ursache?
  • [ ] Keine laufende Anlaufphase?
  • [ ] Regel nicht gerade erst angelegt/reaktiviert, während das Problem schon lief?
  • [ ] Kanal-Test erfolgreich, SMTP eingerichtet?

Anschluss