Systemstatus & Logs

Route: GET /system/health · Menüpfad: Einstellungen → Systemstatus

Die Seite aktualisiert sich automatisch alle 30 Sekunden (einfacher <meta http-equiv="refresh">) und gliedert sich in mehrere Karten.

Lizenz

• →Lizenzinhaber, Ausgestellt, Gültig bis — Stammdaten der eingespielten Lizenzdatei, sowie ein Badge Gültig/Abgelaufen.
• →Feature-Flags — Multi-Mandant und White-Label jeweils als grünes (aktiv) oder graues (inaktiv) Badge.
• →Modul-Badges — ein Badge pro Fachmodul (ETB, Patienten, UHS, Stab, Lagekarte, Bereitstellung, Tetra, Shelter): grün mit Häkchen, wenn das Modul lizenziert ist, grau mit Kreuz, wenn nicht. Diese Lizenz-Verfügbarkeit ist die Voraussetzung für die Modul-Schalter pro Einsatz — ein nicht lizenziertes Modul kann auch über den Einsatz-Schalter nicht aktiviert werden.

Datenbank & In-Memory-Cache

• →Datenbank: Verbindungsstatus, Dateigröße der SQLite-Datenbank, sowie Verbindungspool-Kennzahlen (offen/genutzt/idle, Warte-Aufrufe, Max. Verbindungen).
• →In-Memory-Cache: Anzahl der aktuell im Arbeitsspeicher gehaltenen Benutzer, aktiven Sitzungen, Einsätze, Einsatzmittel und Mandanten — der Cache wird nach jeder schreibenden Operation aktualisiert (Refresh*-Methoden) und dient als schnelle Lese-Schicht vor der Datenbank.

Mandantenstatistiken

Eine Tabelle mit einer Zeile pro Mandant (siehe Mandantenverwaltung): Hostname, Anzahl Benutzer, aktive Sitzungen, Gesamtzahl Einsätze, davon aktiv (grünes Badge), sowie die Größe der hochgeladenen Dateien dieses Mandanten.

Laufzeit & Build-Info

Go-Version, Anzahl Goroutinen, Speicherverbrauch (Heap/Sys) und GC-Durchläufe für die technische Diagnose, sowie Release-Version, Modulpfad und Git-Revision des laufenden Builds — hilfreich, um bei einem Support-Fall sofort zu sehen, welcher genaue Softwarestand betroffen ist.

Karte „Aktive Benutzer" im Health-Dashboard

Diese Tabelle listet jeden Benutzer, der aktuell eine gültige Sitzung besitzt, mit Benutzername, vollem Namen, Mandant und allen Rollen-Badges.

Spalte „Aktuelle Seiten"

Diese Spalte zeigt nicht die letzte besuchte HTTP-Seite, sondern die tatsächlich offenen WebSocket-Verbindungen des Benutzers (h.Hub.Clients()) — also auf welcher Seite der Browser aktuell live Aktualisierungen empfängt (z. B. die ETB-Meldungsseite oder das Belegungs-Dashboard im UHS-Modul). Ein Benutzer kann mehrere Einträge zugleich haben, wenn mehrere Browser-Tabs offen sind; „–" bedeutet, dass aktuell keine WebSocket-Verbindung besteht (z. B. weil der Benutzer sich auf einer Seite ohne Live-Updates befindet).

Route: GET /system/logs · Schaltfläche Logs im Health-Dashboard

Die Logdatei-Übersicht ist in drei Bereiche gegliedert, damit das hohe Aufkommen an HTTP-Zugriffen und TETRA-Funkverkehr nicht die eigentlich relevanten Anwendungs- und Fehlermeldungen überdeckt:

• →Server (server.log) — Anwendungs-Lifecycle, Datenbank, geplante Aufgaben und Fehlermeldungen.
• →Zugriffe (HTTP) (access.log) — eine Zeile pro eingehendem HTTP-Request.
• →TETRA-Gateway (tetra.log) — Funkverkehr über /wsapi (Gruppenrufe, Statusmeldungen, Positionsdaten).

Jeder Bereich zeigt die aktuelle Logdatei sowie alle automatisch rotierten Backups (<name>-<Zeitstempel>.log, ggf. .gz-komprimiert), jeweils mit Größe und letztem Änderungsdatum. Ein Bereich erscheint nur, wenn für ihn bereits Logdateien existieren.

Anzeigen vs. Herunterladen

• →Anzeigen — nur für unkomprimierte Dateien verfügbar. Lädt per GET /system/logs/tail die letzten 300 Zeilen direkt in die Seite (Live-Tail-Ansicht, siehe Screenshot unten).
• →Herunterladen — funktioniert für jede Datei inklusive komprimierter Backups, lädt die vollständige Datei als Anhang herunter (GET /system/logs/download).

Bedienung der Tail-Ansicht

1. Bei der gewünschten Datei auf Anzeigen klicken.
2. Die letzten 300 Zeilen erscheinen in einem scrollbaren Textblock unterhalb der Tabelle.
3. Über die Schaltfläche Kopieren lässt sich der angezeigte Ausschnitt direkt in die Zwischenablage kopieren — z. B. um ihn in eine Support-Anfrage einzufügen.

Route: GET /system/debug-info · Schaltfläche Debug-Info kopieren im Health-Dashboard

Diese Funktion wurde gezielt für Support-Anfragen entwickelt: Statt einzeln Bildschirmfotos vom Health-Dashboard zu machen und Logzeilen zusammenzukopieren, liefert ein Klick einen vollständigen Klartext-Bericht in die Zwischenablage.

Inhalt des Berichts

• →Release-Version, Revision, Build-Zeit, Go-Version, Betriebssystem/Architektur.
• →Datenbankstatus, Dateigröße, Verbindungspool-Kennzahlen.
• →Cache-Zahlen (Benutzer, Sitzungen, Einsätze, Einsatzmittel, Mandanten).
• →Laufzeit-Kennzahlen (Goroutinen, Speicher, GC-Durchläufe).
• →Mandantenstatistiken — pro Mandant Benutzer-/Sitzungs-/Einsatzzahlen und Upload-Größe in einer Zeile.
• →Die letzten 100 Logzeilen aus server.log (Anwendungslog — Zugriffs- und TETRA-Logs sind hier bewusst nicht enthalten).

Bedienung

1. Im Health-Dashboard auf Debug-Info kopieren klicken.
2. Der Bericht wird per Clipboard-API direkt in die Zwischenablage kopiert — die Schaltfläche bestätigt das kurz mit „Kopiert!".
3. Ist die Clipboard-API nicht verfügbar (z. B. weil die Seite nicht über einen als sicher geltenden Kontext aufgerufen wurde), öffnet sich automatisch ein auswählbares Textfeld als Fallback, aus dem der Inhalt manuell kopiert werden kann.
4. Den Inhalt in die Support-Anfrage (E-Mail, Ticket, Chat) einfügen.

Nutzung über die Kommandozeile

Da /system/debug-info eine normale, mit Basic Auth und Sitzungscookie geschützte Route ist, lässt sich derselbe Bericht auch direkt per curl abrufen — etwa wenn die Oberfläche selbst nicht erreichbar ist oder das Ergebnis gleich in eine Datei geschrieben werden soll:

curl -u einsatz:PASSWORT https://<host>/system/debug-info \
  -b "session=<eigener-Sitzungscookie>" \
  -o debug-info.txt

-u liefert dabei die nginx-Basic-Auth-Zugangsdaten (siehe server/deployment/nginx.conf), das gültige Sitzungscookie muss zusätzlich aus einer bestehenden Browser-Anmeldung stammen, da /system/debug-info selbst die normale global_admin-Rollenprüfung durchläuft.