System-Health¶
Umgezogen
Eine eigene „System-Health"-Seite mit Tab-Banner und separater Sidebar-LED gibt es nicht mehr. Die Live-Gesundheit der Instanz zeigt jetzt die Admin-Übersicht (/admin) direkt — als Startseite des Admin-Bereichs, nicht als Unterseite.
Wo du heute hinschaust¶
| Früher | Heute |
|---|---|
| System-Tab mit Stream-Backlog, Insert-Rate, DB-Free, AI-Provider, Worker-Pool | Admin → Übersicht — Kacheln für Kernservices, Verarbeitungs-Pipeline, Speicher & Datenbank, Backup & DR, Lizenz, Updates, Erfassung, Server-System, Hintergrundarbeit |
| Sidebar-LED (grün/gelb/rot) | Ampel direkt in der jeweiligen Kachel der Übersicht |
| Pipeline-Sparklines | Pipeline-Ampel unter Admin → System → Ressourcen → Leistung |
Oben auf der Übersicht steht der Gesamtzustand („Alles gesund", „Aufmerksamkeit nötig", „Problem erkannt"). Ist er nicht grün, steht darunter jeder Grund im Klartext mit einem Link „ansehen" dorthin, wo man ihn abstellt — z. B. ein Kernservice aus, Rückstand in der Pipeline, verworfene Ergebnisse, altes Backup, ablaufende Lizenz, ausgelasteter Server, ein Aktiver Collector offline oder überlastet, stehende Hintergrundarbeit oder ein Zertifikat, das bald abläuft.
Details zur Übersicht: Administration → Übersicht = Instanz-Gesundheit. Details zur Pipeline-Ampel und den Sizing-Profilen: Ressourcen → Leistung.
Was tun bei einem Problem¶
| Symptom | Mögliche Ursache | Maßnahme |
|---|---|---|
| Pipeline-Ampel gelb/rot, Verzögerung steigt | Zu wenig Worker für den aktuellen Check-Mix | Größeres Sizing-Profil wählen, siehe Ressourcen → Leistung |
| Speicher-Kachel warnt (Disk-Belegung ≥ 85 %) | Retention zu lang, Kompression greift nicht | Ressourcen → Speicher prüfen, Retention senken oder „Jetzt aufräumen" |
| Backup-Kachel zeigt keinen aktuellen erfolgreichen Lauf | Zeitplan deaktiviert, Backup schlägt fehl | Backup & Disaster-Recovery prüfen |
| Hintergrundarbeit-Kachel: kein Leiter oder eine Aufgabe steht | Redis nicht erreichbar, API-Prozess hängt, ein Watcher stürzt wiederholt ab | Diagnose-Log Kategorie Wartung lesen (hintergrund_stillstand, leiter_verloren, hintergrund_aufgabe_abgestuerzt); Redis und API-Container prüfen; Notschalter siehe Skalierung |
| Kernservices-Kachel zeigt einen Dienst als „aus" (Worker: „keine Consumer") | Container abgestürzt oder nicht gestartet | Container-Logs des betroffenen Dienstes prüfen |
| „Aufmerksamkeit nötig" wegen verworfener Ergebnisse (Dead-Letters) | Der Worker konnte Ergebnisse endgültig nicht speichern | Ursache im Diagnose-Log klären, dann unter Ressourcen → Leistung abräumen |
Selbst-Monitoring: der Host „Vesana Server"¶
Der Einrichtungs-Assistent bietet an, den Vesana-Server selbst zu überwachen („Vesana-Server selbst überwachen (empfohlen)", standardmäßig an). Dann gibt es im ersten Tenant den Host „Vesana Server" mit diesen Checks, die der Server selbst ausführt:
| Check | Prüft |
|---|---|
| HTTP Health API | Antwortet die API? |
| HTTP Health Receiver | Antwortet der Receiver? |
| PostgreSQL | Ist die Datenbank erreichbar? |
| Redis | Ist Redis erreichbar? |
| Disk Space | Belegung der Server-Platte (WARNING ab 80 %, CRITICAL ab 90 %) |
| TLS Certificate | Restlaufzeit des Instanz-Zertifikats (siehe TLS) |
Diese Checks laufen über die normalen Alarm-Regeln. Sie fragen nur diese festen Ziele ab; eigene Adressen im internen Netz des Servers lassen sich über diesen Check-Typ nicht abfragen.