Uptime-Checks

Uptime-Checks erlauben SLAtus, Ausfälle automatisch zu erkennen. Eine Komponente mit aktivierten Checks wird per HTTP abgefragt, und das Ergebnis kann ihren Status setzen, ohne dass jemand eingreifen muss.

Konfiguration

Die Konfiguration erfolgt je Komponente in der Admin-Oberfläche unter Services → (Service) in der Karte Uptime check. Rollen: admin und service_manager.

Einstellung	Spalte	Bedeutung
Enabled	check_enabled	Schaltet den Checker für diese Komponente ein
URL	check_url	Ziel eines HTTP-GET-Requests
Check interval (seconds)	check_interval_seconds	Abstand zwischen zwei Checks, 30 bis 86 400 Sekunden, Standard 60
Failure threshold	check_failure_threshold	Anzahl aufeinanderfolgender Fehler, bevor ein Ausfall gesetzt wird
Result evaluation	check_result_type	status_200: Erfolg bedeutet eine 2xx-Antwort. body_contains: Der Antworttext muss check_search_string enthalten, unabhängig vom Status. Ist der Suchtext leer, gilt wieder die 2xx-Regel.
Outage severity	check_outage_severity	major_outage (Standard) oder partial_outage
Degraded response time limit (ms)	check_degraded_threshold_ms	Wenn gesetzt (Standard: aus), setzt eine erfolgreiche, aber langsamere Antwort degraded_performance

Mit dem Button Test now wird ein Check sofort einmalig ausgeführt. Das ist ein Diagnosewerkzeug und ändert weder den Check-Zustand noch die Historie.

Pausieren

Mit Pause lässt sich der Check für eine feste Dauer anhalten, in der Oberfläche 15 Minuten, 1 Stunde, 4 Stunden oder 24 Stunden (serverseitig höchstens 7 Tage, check_paused_until). Die Karte zeigt dann „Paused until …“. Resume now hebt die Pause sofort auf. Pausierte Komponenten überspringt der Sweep.

Ablauf eines Sweeps

Jede Minute läuft der Job uptime-check-sweep (lib/notifications/uptime-check.ts). Er prüft alle aktivierten, nicht pausierten Komponenten, deren Intervall seit dem letzten Check abgelaufen ist:

1. Ein HTTP-GET mit 10 Sekunden Timeout wird ausgeführt. Die Antwortzeit wird immer gemessen.
2. Das Ergebnis wird mit der Antwortzeit in uptime_check_results gespeichert.
3. Die Cache-Felder der Komponente last_checked_at, last_check_status und last_check_response_time_ms werden aktualisiert.
4. Fehler: Aufeinanderfolgende Fehler werden gezählt. Ist die Schwelle erreicht, setzt der Sweep den konfigurierten Ausfall-Schweregrad über applyComponentStatusChange. Die übliche Benachrichtigung wird gesendet. Das gilt auch, wenn die Komponente von Hand auf einen anderen Status gesetzt wurde, zum Beispiel „In Wartung“; entspricht der manuelle Status schon dem Schweregrad, bleibt er unverändert. Das gilt auch für einen von Hand erhöhten Ausfall-Schweregrad: bleibt der Check fehlgeschlagen, setzt der Sweep den konfigurierten Schweregrad einmal erneut (danach bleibt er stabil). Erholung und Degradation fassen einen von Hand geänderten Status dagegen nicht an. Hat der Checker zuvor selbst degraded_performance gesetzt, eskaliert er so zum Ausfall. Der Sweep merkt sich in check_set_status, welchen Status er zuletzt gesetzt hat.
5. Erfolg: Wurde der aktuelle Status vom Checker selbst gesetzt (Ausfall oder Degradation) und ist die Antwort schnell genug, setzt der Sweep operational. Ist die Antwort langsamer als die Schwelle für Degradation, setzt er degraded_performance, aber nur wenn die Komponente operational ist oder der Checker den Ausfall selbst gesetzt hat. Ein manuell gesetzter Status bleibt dabei unverändert.

Schutz vor dem Überschreiben manueller Änderungen

Der Sweep merkt sich in check_set_status, welchen Status er zuletzt gesetzt hat. Der Checker stellt eine Komponente nur wieder her und stuft sie nur auf degraded_performance herab, wenn er den Status selbst gesetzt hat oder die Komponente operational ist — der aktuelle Status muss also noch genau dem gespeicherten Wert entsprechen, auch wenn die Ausfall-Severity inzwischen geändert wurde. Ändert ein Mensch den Status, endet die Zuständigkeit des Checkers und check_set_status wird beim nächsten Check zurückgesetzt. Ein manuell gesetzter Schweregrad bleibt bestehen, bis ein Mensch ihn ändert. Ausnahme ist ein Ausfall: Erreichen die Fehlschläge die Schwelle, setzt der Sweep den konfigurierten Ausfall-Schweregrad.

Historie und Anzeige

• Unter Services → (Service) → View history (/admin/services/[id]/uptime-history) stehen die letzten 50 Check-Ergebnisse mit Zeitpunkt, Ergebnis und Fehlermeldung.
• Unter Service Status zeigt ein farbiges Symbol je Service das Ergebnis und die Antwortzeit des letzten Checks.

Aufbewahrung

Ergebnisse werden 30 Tage lang gespeichert. Der Job uptime-check-retention löscht ältere Zeilen täglich um 03:00.

Betriebshinweise

• Der Checker benötigt den Worker-Prozess. Ohne ihn laufen keine Checks.
• Checks werden vom Server aus ausgeführt, auf dem der Worker läuft. Eine URL, die nur von außen erreichbar ist, braucht einen Worker mit Zugang dorthin oder einen externen Monitor, der die Öffentliche API aufruft.
• Automatische Checks und manuelle Änderungen können dieselbe Komponente betreffen. Der zentrale Einstiegspunkt serialisiert sie, die letzte Änderung gewinnt.