Zum Inhalt

Status- und State-Modell

Die fünf Status-Werte

Status Code Farbe Bedeutung
OK 0 grün Alles in Ordnung, alle Schwellwerte eingehalten
WARNING 1 gelb Warn-Schwelle überschritten, noch nicht kritisch
CRITICAL 2 rot Kritische Schwelle überschritten oder Check fehlgeschlagen
NO_DATA 3 orange Keine Daten innerhalb der Erwartungs-Frist empfangen
UNKNOWN 4 grau Check ausgeführt, Ergebnis nicht interpretierbar (z. B. Plugin-Exit-Code 3)

NO_DATA und UNKNOWN werden in der Praxis oft verwechselt. Faustregel:

  • NO_DATA = wir haben den Check gar nicht gehört (Agent offline, Collector tot, neuer Service ohne Lauf)
  • UNKNOWN = der Check lief, aber das Ergebnis ist nicht eindeutig (Parser-Fehler, fehlende OID auf SNMP-Gerät)

Severity-Reihenfolge

Wichtig für Aggregation (Tenant-Status, Host-Status, Alert-Gruppen):

CRITICAL > WARNING > NO_DATA > UNKNOWN > OK

Wenn ein Host 3 Services hat — OK, NO_DATA, WARNING — ist der zusammengefasste Host-Status WARNING, nicht NO_DATA. Ein konkretes Problem (WARNING) ist relevanter als ein Datenausfall (NO_DATA).

Three-Layer-State-Modell (seit v0.48)

Vesana trennt Operator-Sichtbarkeit von Notification-Trigger in zwei Layer. Das alte Soft/Hard-Modell mit max_check_attempts und retry_interval_seconds wurde in Migration 147 komplett entfernt.

Layer Spalte Wofür Latenz
UI-State current_status.ui_state Was der Operator in der Fehlerübersicht sieht ~15-30 s
Alerting-State current_status.alerting_state Was Notifications/SLA antreibt sustained ≥ alert_after_seconds (60-120 s)

UI-State-Werte (ui_state_kind-ENUM)

Wert Bedeutung
ok Check ist grün
probing Erster Fehlschlag, Bestätigung läuft (Confirmation-Retry)
degraded Fehler bestätigt — aber noch keine Push-Notification, weil sustained-Schwelle nicht erreicht
alerting Fehler dauerhaft → Push raus, Operator alarmiert
no_data Kein Check-Ergebnis empfangen (Agent/Collector offline, neuer Service)
unknown Check lief, Ergebnis nicht interpretierbar

Alerting-State-Werte (alerting_state_kind-ENUM)

Nur zwei Werte — ok oder alerting. Genau dieses Feld treibt Notifications + Status-Pages + SLA an. degraded triggert keinen Alert; erst die Promotion zu alerting nach Sustained-Schwelle tut das.

Phasen-Sequenz

stateDiagram-v2
    [*] --> ok: Check ok
    ok --> probing: Check kritisch (Erstkontakt)
    probing --> ok: Recovery (nie alarmiert)
    probing --> degraded: Confirmation bestätigt (1 Retry default)
    degraded --> ok: Recovery vor Sustained-Schwelle (nie alarmiert)
    degraded --> alerting: Sustained ≥ 60s (CRITICAL) bzw. 120s (WARNING)
    alerting --> ok: Recovery (Recovery-Notification raus)
Phase Konkret
ok → probing erster Fehl-Antwort vom Check
probing → degraded nach confirmation_attempts × confirmation_interval_seconds (Default 1×10 s)
degraded → alerting nach alert_after_seconds sustained — Default 60 s für CRITICAL, 120 s für WARNING
alerting → ok Check liefert wieder grün, Recovery-Notification feuert

Active-Mode-Fast-Poll

Während probing schaltet der Worker-Scheduler das nächste next_check_at auf confirmation_interval_seconds (Default 10 s), während degraded auf recovery_poll_interval_seconds (Default 15 s). Damit werden Active-Checks schneller bestätigt und schneller recovered. Passive/Agent-Checks brauchen weiterhin einen Heartbeat-Push.

Acknowledgement während degraded

Setzt der Operator ein ACK während degraded, blockiert das die Promotion zu alerting — kein Push-Spam für etwas, das der Operator schon gesehen hat. Recovery löscht das ACK automatisch.

Lange Check-Intervalle

Bei Intervallen > 2× Sustained-Schwelle (z. B. 5 min Active-Check, 60 s Schwelle) basiert die Promotion auf alten Daten — der Service kann zwischenzeitlich schon recovered sein, wir erfahren es nur noch nicht. Detection-Latenz = interval_seconds + confirmation_interval. Faustregel: das Haupt-Intervall nicht deutlich größer wählen als die Sustained-Schwelle.

So liest du die Pillen in der Fehlerübersicht

In der Fehlerübersicht steht neben jedem Service eine zusammengesetzte Pille — links der Status (CRITICAL/WARNING/NO_DATA/UNKNOWN), rechts der UI-State (PROBING/DEGRADED/ALERT). Daraus liest du in einem Blick: Was ist das Problem? Und: Wo steht es im Eskalations-Pfad?

Pille Visuell Bedeutung
CRITICAL + PROBING grau pulsierend Erstkontakt, Confirmation läuft — kein Alarm geplant
CRITICAL + DEGRADED rot pulsierend Fehler bestätigt, noch keine Push — Live-Countdown bis Alarmierung sichtbar
CRITICAL + ALERT rot solid + Glocke Push raus, Operator alarmiert
WARNING + DEGRADED gelb pulsierend Warn-Schwelle bestätigt, Sustained läuft (Default 120 s)
WARNING + ALERT gelb solid + Glocke Warn-Push raus
NO_DATA orange Kein Check-Ergebnis — Agent oder Collector offline / Service neu
UNKNOWN grau Check lief, Ergebnis nicht interpretierbar

Was du daraus schließen darfst

  • Pille pulsiert grau (PROBING): noch nichts gemacht, abwarten — Confirmation läuft.
  • Pille pulsiert rot/gelb (DEGRADED): jetzt anschauen. Wenn du es dir gleich anguckst, drück ACK → die Promotion zu ALERT (und damit der Push an alle Channels) wird gestoppt.
  • Pille solid + Glocke (ALERT): der Push ist raus. Andere Operator wissen Bescheid. Trotzdem ACKen wenn du dich darum kümmerst.

Was die kleinen Indikatoren bedeuten

  • Pulsieren = State ist „in Bewegung", entweder Confirmation oder Sustained läuft.
  • Glocke = es ist mindestens eine Notification raus.
  • Backoff (5 / 15 / 30 min) auf lange-down Services — bis zu 10 min Recovery-Lag, weil wir nicht permanent gegen tote Endpunkte pollen.

Wann wird welcher Status gesetzt?

Beim Anlegen eines neuen Service

Neuer host_service → initialer Status NO_DATA, nicht UNKNOWN. Das macht klar: „Wir warten noch auf das erste Ergebnis", nicht „der Check ist kaputt".

Bei eingehendem Check-Ergebnis

Worker übersetzt das Plugin-Result in einen Status:

  • Exit-Code 0, Wert unter threshold_warn → OK
  • Wert ≥ threshold_warn und < threshold_crit → WARNING
  • Wert ≥ threshold_crit oder Exit-Code 2 → CRITICAL
  • Exit-Code 3 / unparsbares Ergebnis → UNKNOWN

Wenn Daten ausbleiben

Watcher-Loops setzen NO_DATA:

Watcher Trigger
dead_agent_watcher Agent meldet sich seit > agent_dead_after (Default 3× Heartbeat-Intervall, ~3 min) nicht mehr
dead_collector_watcher Collector seit > 3 min still
service_overdue_watcher Service-Result älter als interval_seconds × 1.5

Sobald ein Ergebnis eintrifft, wechselt der Status auf das tatsächliche Resultat.

Konfiguration pro Profile-Check

Feld Bedeutung Default
interval_seconds Haupt-Intervall 60 s
confirmation_attempts Confirmation-Retries im probing vor degraded 1
confirmation_interval_seconds Abstand zwischen Confirmation-Retries 10 s
recovery_poll_interval_seconds Active-Poll-Intervall im degraded (Recovery) 15 s
recovery_poll_window_seconds Fenster für Recovery-Fast-Poll 300 s

Die Sustained-Schwellen (alert_after_critical_seconds, alert_after_warning_seconds) liegen in system_settings und sind global per Default 60 s / 120 s.

Auf Host-Service-Ebene gibt es Override-Felder (confirmation_attempts_override, confirmation_interval_override, recovery_poll_interval_override, recovery_poll_window_override) — werden via COALESCE aufgelöst.

Acknowledged

Ein Service kann acknowledged werden — der Operator hat ihn gesehen, weitere Notifications werden unterdrückt:

alerting   + ACK → keine weiteren Notifications (Inhibition)
degraded   + ACK → Promotion zu alerting blockiert (kein Push am Anfang)
+ Recovery       → Status OK, ACK auto-cleared

Details: Alerting → Acknowledgements.

Downtime

Während einer aktiven Downtime läuft der Check normal weiter, aber Alert-Rules sehen ihn als „in Wartung". Notifications werden nicht versandt, der Status erscheint im UI mit einem Wartungs-Badge.

Wartung ≠ ACK: ACK ist „ich habe es gesehen", Downtime ist „das ist erwartet".

Details: Alerting → Downtimes.

Aggregierter Status

Der Host-Status ist die schlimmste Severity seiner Services (mit Inhibition-Berücksichtigung). Der Tenant-Status ist die schlimmste Severity seiner Hosts.

Inhibition kann den effektiven Status reduzieren: wenn der Eltern-Host alerting ist, sind seine abhängigen Services im UI ausgegraut und zählen nicht in den Tenant-Status. Inhibition wirkt erst ab Eltern-alerting, nicht schon ab Eltern-degraded — sonst würden Kind-Alerts bei kurzen Eltern-Glitches stillschweigend unterdrückt.

Details: Alerting → Dependencies & Inhibition.

Status-Pages

Public-Status-Pages filtern hartcodiert auf alerting_state='alerting'. Damit sieht der Visitor kein „Server kurz rot dann grün" mehr — nur Probleme, die der Operator wirklich sehen müssen.

Anschluss