Status
Die Statusseite ist der schnelle Betriebsüberblick für Ephraim: Spark-Erreichbarkeit, Runtime, Containerzustände, Auslastung und Hinweise auf Dienste, die aktiv, bereit, problematisch oder bewusst deaktiviert sind.
1. Zweck der Statusseite
Die Statusseite zeigt, welche Dienste gerade erreichbar und bereit sind. Sie ist bewusst als Übersicht gebaut und nicht als Reparaturkonsole. Administratoren sehen auf einen Blick, ob Webserver, Spark-Dienste und Runtime-Container erwartungsgemäß erreichbar sind.
2. Welche Signale angezeigt werden
| Signal | Bedeutung |
|---|---|
| Spark und Inference | Erreichbarkeit der lokalen KI-Inferenz und Antwortfähigkeit des Modells. |
| Runtime und Supervisor | Technische Betriebsdienste für Terminal, Logs, Status und administrative Aktionen. |
| Container | Zustand von Inference, Embedding, Broker, Observer, Runtime, TTS und Logrotation. Der Supervisor läuft getrennt vom Stack. Der abgenommene Standardbetrieb umfasst insgesamt acht laufende Container. |
| school-ui-observer | Liefert der Runtime freigegebene Containerzustände und begrenzte Logs. Er nutzt dazu den festen Broker über einen internen Unix-Socket und hat weder Netzwerkport noch direkten Dockerzugriff. |
| school-ui-broker | Prüft die fest erlaubten Container und vermittelt ihre Zustände und Logs an den Observer. Er ist ein interner Betriebsdienst ohne Netzwerkport. |
| school-ui-logrotate | Rotiert technische Spark-Logdateien täglich. Der Dienst besitzt keinen eigenen Web-Endpunkt und wird deshalb über seinen Docker-Zustand bewertet. |
| Ressourcen | Speicherauslastung, Temperatur, GPU-Leistung und Dienstmetriken. Die Anzeige verwendet die im Hintergrund gesammelten und zuletzt gültigen Messwerte. Eine fehlende oder zu alte Leistungsprobe wird nicht als aktuelle Messung ausgegeben. |
3. Status richtig lesen
Ein rotes oder gelbes Signal bedeutet nicht automatisch, dass die Anwendung komplett
ausgefallen ist. Manche Dienste sind optional oder nur für bestimmte Funktionen relevant.
Ein deaktivierter Container ist kein Fehler, wenn er bewusst deaktiviert wurde. Problematisch
wird es, wenn ein Dienst aktiv sein soll, aber nicht antwortet oder wiederholt fehlschlägt.
school-ui-broker, school-ui-observer und school-ui-logrotate sollen im normalen
Betrieb als eigene bereite Container erscheinen. Fehlt Broker oder Observer, kann die Runtime
Containerzustände und Logstreams nicht zuverlässig liefern. Fehlt Logrotate oder ist der
Dienst gestoppt, läuft die vorgesehene Rotation der technischen Logdateien nicht.
Fehlende Temperatur-, Strom- oder VRAM-Werte sind deshalb nicht automatisch ein Fehler der Statusseite. Entscheidend ist, ob der Runtime-Snapshot diese Werte für die aktuelle Spark-Konfiguration liefert.
Die Leistungsanzeige bezeichnet den gemessenen GPU-Verbrauch. Sie ist kein Messgerät für den Gesamtverbrauch der Spark, des Webservers oder des Schulnetzes. Eine daraus berechnete Energieangabe ist eine Schätzung für die jeweilige Anfrage. Ein bereiter Dienst oder eine gültige Messung beweist zudem noch keine bestimmte Antwortzeit bei hoher gleichzeitiger Nutzung.
4. Datenschutz und Sichtbarkeit
Die Statusseite zeigt technische Zustände, keine privaten Chatinhalte. Sie dient der Betriebsdiagnose und soll nicht zur Analyse einzelner Nutzerverläufe verwendet werden. Wenn Detaildiagnose nötig ist, erfolgt sie über Logs, Cronstatus oder das Supervisor-Terminal mit klarer Fragestellung.
5. Typische Reaktion auf Probleme
- Prüfen, ob der Webserver selbst erreichbar ist und Anmeldungen funktionieren.
- Auf der Statusseite Spark, Inference, Broker, Observer und Runtime vergleichen.
- Bei Containerproblemen im Supervisor-Webterminal Logs und Status abfragen.
- Bei wiederkehrenden Wartungsproblemen Cronstatus und letzte Läufe prüfen.
- Erst danach Dienste gezielt neu starten oder Super-Admin-Aktionen ausführen.