Zum Inhalt

Alert Rules

Eine Alert-Regel legt fest, wann und an wen eine Benachrichtigung geht. Ohne passende, aktive Regel benachrichtigt Vesana nie — ein roter Check allein verschickt nichts.

Regeln verwaltest du unter Alerting → Regeln (Seitenleiste: Configuration → Alerting). Die Liste lässt sich durchsuchen, nach Tenant und Aktiv/Deaktiviert filtern und blättern; jede Zeile hat einen Schalter zum Ein-/Ausschalten sowie Test, Bearbeiten und Löschen.

Regel anlegen

Alerting → Regeln → Neue Regel. Der Editor ist zweispaltig: links „wann und wo", rechts „wer wird benachrichtigt".

Name und Tenant

Der Name erscheint in Meldungen und im Alarm-Fahrplan. Der Tenant bestimmt, welche Hosts und Kanäle wählbar sind — Kanäle lassen sich nur aus demselben Tenant zuordnen.

Status-Filter

Vier Chips: Critical · Warning · No Data · Unknown. Die Regel meldet nur bei den gewählten Statussen; mindestens einer muss gewählt sein. Neue Regeln starten mit Critical und Unknown.

Wartezeit pro Status (Versand-Gate)

Abschnitt „Benachrichtigen, nachdem das Problem anhält". Ein Problem wird erst gemeldet, wenn es diese Zeit lang durchgehend besteht.

Feld Bedeutung
Critical Wartezeit in Sekunden für CRITICAL (Vorgabe 60)
Warning Wartezeit für WARNING (Vorgabe 120)
No Data leer = „wie Critical"
Unknown leer = „wie Critical"

0 heißt ausdrücklich „sofort" — die Meldung geht ohne Sammelfenster raus. Die Schnellwahl (sofort · 30 s · 1 min · 5 min · 15 min) setzt Critical und Warning gemeinsam.

Löst sich das Problem auf, bevor die Wartezeit abgelaufen ist, verschickt die Regel für diese Episode gar nichts — nicht verspätet, sondern nie. Das ist gewollt: ein Ausreißer, der sich von selbst erledigt, soll niemanden alarmieren. Die Anzeige in Fehlerübersicht und Host-Detail reagiert davon unabhängig sofort, siehe Alerting-Übersicht.

Jede Regel wertet ihre Wartezeit für sich aus. Treffen mehrere Regeln denselben Check, meldet jede nach ihrer eigenen Zeit an ihre eigenen Kanäle.

Neue oder reaktivierte Regeln blasten nicht rückwirkend

Legst du eine Regel an oder schaltest eine ausgeschaltete wieder ein, während irgendwo schon ein Problem läuft, gilt die Regel nur für Probleme, die danach entstehen. Ein bereits laufendes Problem bleibt für diese Regel stumm, bis es einmal behoben war und erneut auftritt — auch die Eskalation läuft dafür nicht an. Unter „Aktive Alarme" steht das dann als „nie gesendet — das Problem lief bereits, als die Regel aktiviert wurde".

Wann wird ein Check NO_DATA?

Ein Check, der zuletzt OK war, gilt nach ungefähr dem 3-fachen seines Intervalls ohne neues Ergebnis als NO_DATA (5-Minuten-Check: nach rund 15 Minuten Stille). Ein Check, der schon vorher WARNING oder CRITICAL war, bekommt mehr Toleranz — NO_DATA erst nach dem 10-fachen Intervall oder nach 30 Minuten, je nachdem, was länger ist. So springt ein bereits gestörter Check nicht bei jeder kleinen Verzögerung zwischen CRITICAL und NO_DATA hin und her.

Bei Agent-Hosts, deren Agent sich nicht mehr meldet, gilt zusätzlich der Host als nicht erreichbar — dann kommt eine Host-Meldung statt einer pro Check, siehe Wenn-Dann-Referenz.

Geltungsbereich

Modus Bedeutung
Alle alle Checks des Tenants
Bestimmte Hosts Auswahl aus der Host-Liste (durchsuchbar)
Bestimmte Services Auswahl nach Check (Profil-Check); gilt auf allen Hosts, die ihn haben
Host + Services gezielte Zuordnungen Host → Check, mit Suchfeld über Hosts und Checks

Ausnahmen

Unter „Ausnahmen festlegen" nimmst du einzelne Hosts oder einzelne Checks aus — in jedem Geltungsbereich, etwa „alles im Tenant, außer diesem Host". Ein ganzer Host als Ausnahme unterdrückt auch die „Host nicht erreichbar"-Meldung dieser Regel; einzelne Check-Ausnahmen lassen sie bewusst durch. Die Suche findet auch einzelne Checks und klappt deren Host auf; der Abschnitt lässt sich einklappen, der Zähler bleibt sichtbar.

Treffer-Vorschau

Während du den Geltungsbereich änderst, zeigt der Editor live „Matcht aktuell N Checks" mit Beispielen und der Zahl der per Ausnahme ausgeschlossenen Checks. Bei 0 warnt der Editor: diese Regel benachrichtigt nie. Unsichtbare Telemetrie-Checks des Agents zählen ab v1.9.437 nicht mehr mit.

Anomalie-Erkennung

Nur sichtbar, wenn die Anomalie-Erkennung instanzweit eingeschaltet ist: „Anomalie-Benachrichtigungen" (ungewöhnliche Messwerte) und „Kapazitätswarnungen" (Disk voll in unter 7 Tagen). Details: Anomalie-Erkennung.

Erste Benachrichtigung

Die Kanäle, die die erste Meldung bekommen, sobald die Wartezeit abgelaufen ist. Kanäle fügst du über die „+ Kanalname"-Pillen hinzu; es erscheinen nur aktive Kanäle des Tenants. Konfiguration der Kanäle: Notification Channels.

Kanal-Feinsteuerung

Pro Kanal und pro Stufe legst du direkt in der Regel fest, was über ihn geht:

  • Status-Chips — welche der in der Regel gewählten Statusse dieser Kanal bekommt (z. B. Push nur bei Critical, E-Mail bei allem). Ein grauer Chip ist abgewählt; der letzte Status lässt sich nicht abwählen — dann den Kanal entfernen.
  • Entwarnung — ob dieser Kanal die „behoben"-Meldung erhält.

Bekommt kein Kanal in keiner Stufe die Entwarnung, warnt der Editor: die Regel meldet nur Probleme. Kanal-eigene Filter gibt es nicht mehr — was ein Kanal bekommt, entscheidet allein die Regel.

Eskalation

Zeitversetzte Stufen für „der Operator reagiert nicht, dann der Manager, dann das Team". Pro Stufe: Nach der ersten Benachrichtigung warten (Vorgaben 5 min · 15 min · 30 min · 1 h · 2 h · 4 h oder Benutzerdefiniert, minutengenau, mindestens 1 min) plus eigene Kanäle mit derselben Feinsteuerung. Stufen brauchen mindestens einen Kanal und streng steigende Zeiten.

Die Stufen zählen ab der ersten Benachrichtigung — nicht ab Beginn des Problems, falls dessen Wartezeit noch lief. Wird der Alarm quittiert, pausiert die Eskalation; wird das Problem behoben, endet sie. Feuern mehrere Checks gleichzeitig dieselbe Stufe, kommt eine Sammel-Meldung pro Stufe und Kanal-Satz.

Ein Neustart des Servers verliert keine Eskalation: laufende Alarme werden beim Hochfahren an ihrem Stand weitergeführt.

Die Vorschau-Zeile unter den Stufen fasst den Fahrplan zusammen: „Nach 60 s an ops-mail → 30 Min später an ops-push".

Wiederholte Meldungen

Abschnitt „Wiederholte Meldungen zu einem offenen Alarm" — was passiert, solange das Problem offen bleibt:

Modus Verhalten
Nur bei Verschlimmerung (Vorgabe) Erneut melden nur, wenn die Schwere über die zuletzt gemeldete steigt oder ein weiterer Check dazukommt. Ein Wert, der um seinen Schwellwert pendelt, bleibt still.
Bei jeder Überschreitung Zusätzlich jedes Mal, wenn der Schwellwert erneut überschritten wird — frühestens im eingestellten Abstand.
Regelmäßig erinnern Zusätzlich in festem Takt, auch wenn sich nichts ändert.

Für die beiden letzten Modi gibt es eine Frequenz „Frühestens alle" (Vorgaben 5 min bis 1 d oder Benutzerdefiniert; Vorbelegung 30 min). Erinnerungen sind damit opt-in pro Regel; einen tenantweiten Wiederholungs-Takt gibt es nicht mehr. Treffen mehrere Regeln denselben Check, gilt der gesprächigste Modus.

Gruppierung

Wenn 50 Checks gleichzeitig ausfallen, willst du eine Sammel-Meldung, nicht 50 Einzelmails. Gruppierung stellst du nicht pro Regel ein, sondern pro Tenant unter Tenants → Tenant aufklappen → Alert-Gruppierung. Es gibt genau drei Stellschrauben:

Feld Bedeutung
Gruppieren nach Host (alle Alarme eines Hosts in einer Meldung, Vorgabe) · Host + Severity (wie Host, aber getrennt nach Status) · Service-Name (gleicher Check-Name über alle Hosts; Achtung: fällt ein Host mit vielen Checks aus, entstehen mehrere Meldungen — eine je Check-Name)
Wartezeit Nach dem ersten Alarm so lange auf weitere warten, dann eine Meldung mit allem, was bis dahin da ist (Vorgabe 30 s, 0 = sofort)
Mindestabstand Frühestens so lange nach der letzten Meldung kommt ein Update zur selben Gruppe — weitere Checks, höhere Schwere oder eine Teil-Entwarnung (Vorgabe 5 min, mindestens 1 min)

Unter den Reglern steht ein Beispielsatz, der die drei Werte in das übersetzt, was beim Empfänger ankommt.

Was die Gruppierung außerdem tut:

  • Mehrere Hosts gleichzeitig nicht erreichbar (Standort ohne Strom, Collector-Netz weg): alle Hosts, die innerhalb der Wartezeit ausfallen, stehen in einer Meldung „Hosts nicht erreichbar: srv01, srv02, srv03" — beim Comeback ebenso eine Entwarnung. Ein einzelner Host bekommt weiterhin seine gewohnte Einzel-Meldung.
  • Gebündelte Entwarnungen: erholen sich mehrere Bündel kurz nacheinander, kommt innerhalb der Wartezeit eine Sammel-Entwarnung.
  • Regeln mit Wartezeit 0 senden ihre erste Meldung sofort, bleiben aber Teil des Bündels — was danach dazukommt, folgt als Update.
  • Pro Host lässt sich die Gruppierung abschalten (Host verwalten → Alert-Gruppierung): seine Meldungen gehen dann einzeln und ohne Sammelfenster raus.

Erinnerungen an weiterhin offene Probleme gehören nicht hierher, sondern zur Regel (siehe oben). Wie Bündel, Updates und Erinnerungen im Detail zusammenspielen: Wenn-Dann-Referenz.

Ein- und Ausschalten

Der Schalter steht in der Regel-Liste (und in der Alerting-Übersicht). Eine ausgeschaltete Regel ist wirklich still: keine Alarme, keine Eskalationsstufen und keine Entwarnungen mehr — auch nicht für Probleme, die schon vor dem Ausschalten liefen. Trifft eine andere aktive Regel denselben Kanal, hat sie Vorrang. Beim Wiedereinschalten gilt die Regel nur für Probleme, die danach entstehen (siehe oben).

Eine gelöschte Regel liefert dagegen offene Entwarnungen noch zu, damit kein Alarm „hängen" bleibt.

Test und Probealarm

Zwei verschiedene Dinge:

  • Test (in der Regel-Zeile): schickt eine als Test markierte Meldung direkt an die aktiven Kanäle der Regel — ohne Wartezeit, Unterdrückung oder Zustell-Journal. Prüft nur, ob die Kanäle erreichbar sind.
  • Probealarm (Knopf über der Liste): wählt einen Host und schickt einen als PROBEALARM markierten Alarm durch die echte Kette — Regel-Zuordnung, Unterdrückung, Zustell-Journal, Kanäle. Das Ergebnis zeigt pro Kanal Status und Fehler. Bleibt die Tabelle leer, trifft keine aktive Regel diesen Host oder eine Unterdrückung greift — Details im Diagnose-Log, Kategorie „Unterdrückt".

Entwarnungen

Eine Entwarnung geht an genau die Kanäle, die beim Alarm tatsächlich benachrichtigt wurden — auch wenn du die Regel danach geändert oder gelöscht hast. Niemand bekommt eine Entwarnung für einen Alarm, den er nie gesehen hat, und niemand geht leer aus, nur weil die Regel inzwischen anders aussieht. Welche Kanäle überhaupt Entwarnungen bekommen, stellst du in der Kanal-Feinsteuerung ein.

Verschlimmerung und Flapping

Springt ein bereits gemeldeter Check von WARNING auf CRITICAL, meldet die Regel erneut mit dem höheren Schweregrad — in jedem Wiederholungs-Modus. Maßstab ist die zuletzt gemeldete Schwere: ein Wert, der um seinen Schwellwert pendelt (CRITICAL → WARNING → CRITICAL), erzeugt keine neue Alarm-Mail.

Springt ein Check sehr schnell mehrfach zwischen zwei Statussen hin und her (Flapping), entsteht keine Kaskade aus Alarm und Entwarnung: 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 (mit Kanälen) — oder warum nicht: Downtime, ACK, Info-Modus, keine passende Regel, Status-Filter oder kein aktiver Kanal.

Rechte

Regeln sehen: alert_rules.view (Operator und Viewer). Anlegen, Bearbeiten (inkl. Test und Probealarm) und Löschen: alert_rules.create, alert_rules.edit, alert_rules.delete — in den mitgelieferten Rollen ab Admin.

Audit

Regel-Änderungen landen im Audit-Log mit Diff — wer hat die Wartezeit von 300 auf 60 Sekunden gesetzt?

Anschluss