Zum Inhalt

Alerting

Wenn ein Check CRITICAL wird, soll jemand davon erfahren — aber nicht der falsche, nicht zu spät, nicht 50 Mal hintereinander und nicht für jedes abhängige Symptom. Genau das macht das Alerting.

Die Seite Alerting

Alles zum Alerting liegt an einem Ort: Seitenleiste → Configuration → Alerting (über den Pfeil aufklappbar; der Menüpunkt erscheint für Admins und Super-Admins). Vier Reiter:

Reiter Inhalt
Übersicht Kennzahlen und die drei Listen Aktive Alarme, Regeln, Kanäle — mit Suche, Filtern und Blättern; Regel oder Kanal direkt hier ein-/ausschalten, testen und bearbeiten
Regeln alle Alert Rules
Kanäle alle Notification Channels
Aktive Alarme jeder Check, der gerade alarmiert oder kurz davor ist, mit Fahrplan — dazu das Zustell-Protokoll

Die Kennzahlen der Übersicht: Offene Alarme (alarmiert · anbahnend), Zugestellt (24 h) (mit fehlgeschlagen · ausstehend), Regeln (aktiv von gesamt), Kanäle (aktiv von gesamt), Zustellung gestört (Kanäle, deren letzter Versuch fehlschlug), Kanäle ohne Regel (von keiner Regel und keiner Stufe benutzt) und Tenants ohne aktive Regel (dort alarmiert nichts). Die Filter der Übersicht merkt sich Vesana pro Benutzer.

Aktive Alarme

Eine Zeile je Alarm; ein Klick auf Fahrplan anzeigen klappt die Zeitleiste auf: Problem erkannt → bestätigt → Erste Benachrichtigung mit Uhrzeit und Countdown (bei No Data und Unknown mit der dafür eingestellten Wartezeit) → Eskalationsstufen. Standardmäßig steht oben, was gerade meldet — darin das Schwerste und davon das am längsten offene Problem. Suche (Gerät, Check, Tenant), Filter (Status, Zustand „Meldet gerade"/„Bahnt sich an", Tenant) und Sortierung laufen am Server; Vesana merkt sie sich pro Benutzer.

Ob die erste Benachrichtigung wirklich zugestellt wurde, liest Vesana aus dem Zustell-Journal — sonst steht dort der Grund („nie gesendet — das Problem lief bereits, als die Regel aktiviert wurde", „unterdrückt — Eltern-Host oder Collector war nicht erreichbar"). Quittierte Alarme sind über „Alarme mit ACK anzeigen" einblendbar und zeigen „pausiert (ACK)". Checks in Downtime, im Info-Modus, deaktivierte Hosts oder Checks ohne passende aktive Regel erscheinen hier nicht. Bei sehr vielen Alarmen nennt die Ansicht „Mehr als N Alarme" und bittet, die Filter einzugrenzen.

Ist auf der Instanz kein E-Mail-Versand eingerichtet, aber mindestens ein aktiver E-Mail-Kanal vorhanden, zeigt die Übersicht (wie die Kanal-Seite) eine rote Warnung „E-Mail-Versand ist nicht eingerichtet — … Jede Meldung an ihn geht verloren" mit dem Link SMTP einrichten (für Nicht-Super-Admins mit dem Hinweis, wen sie fragen müssen). Fehlt die Instanz-Zeitzone, weist ein Hinweis darauf hin, dass Uhrzeiten in Meldungen dann in UTC stehen.

Zwei Geschwindigkeiten: Anzeige vs. Benachrichtigung

Zwei Dinge laufen bewusst getrennt:

  • Was du siehst, reagiert in Sekunden. Ein Check, der auffällig wird, zeigt sofort einen Nicht-OK-Zustand in Fehlerübersicht und Host-Detail. Der Status-Tooltip sagt dazu: „alarmiert (ob eine Meldung rausgeht, entscheiden die Alert-Regeln)".
  • Was gemailt, gepusht oder gepostet wird, wartet, bis das Problem die in der Regel eingestellte Zeit ununterbrochen angehalten hat.

Ein rot angezeigter Check ohne Meldung ist also kein Fehler — er ist noch nicht lange genug am Stück kritisch. Wie lange „lange genug" ist, legst du pro Regel und pro Status fest, siehe Alert Rules.

flowchart LR
    R[Check-Result CRITICAL] --> GATE[Wartezeit der Regel abgelaufen?]
    GATE -->|nein| NOP[nichts senden]
    GATE -->|ja| SUP[Unterdrückung: Downtime, ACK, Host/Agent/Collector weg, Abhängigkeit, Info-Modus, Anlaufphase?]
    SUP -->|ja| MUTE[still, Grund im Diagnose-Log]
    SUP -->|nein| GROUP[Bündeln pro Tenant]
    GROUP --> OUT[Zustell-Journal]
    OUT --> CHAN[Kanäle: E-Mail, Push, Webhook, Slack, Teams, ...]
    GROUP --> ESC[Eskalation Stufe 1, 2, 3 ...]