ms
60 lines
3.2 KiB
Markdown
60 lines
3.2 KiB
Markdown
# dilib Operations — Dashboard 1.1
|
|
|
|
Zentrales Monitoring für Django-Server und Celery-Cluster in getrennten Netzsegmenten.
|
|
Vollständiger Python-Quellcode mit Django-API, NiceGUI-Oberfläche, PostgreSQL-Modellen,
|
|
Migration, Agent, Tests und systemd-/Nginx-Konfiguration. Installation ohne Docker.
|
|
|
|
**Installation beginnen: [START_HERE.md](START_HERE.md).**
|
|
|
|
## Einstieg
|
|
|
|
1. ZIP entpacken und den Inhalt von `dilib_dashboard` nach `/opt/dilib-dashboard` kopieren.
|
|
2. [Installation](docs/INSTALLATION.md) auf dem zentralen Server durchführen.
|
|
3. Je Host einen Agenten registrieren und installieren; je Broker genau einen Event-Collector aktivieren.
|
|
4. [Abnahme](docs/OPERATIONS.md) vor Produktivbetrieb durchführen.
|
|
|
|
## Funktionsumfang
|
|
|
|
- Responsive NiceGUI-Oberfläche: Übersicht, Serverdetails, Celery & Tasks, Flower,
|
|
Historie, Alarme, dilibAI und Einstellungen. Deutsche Beschriftung, Netzsegmentfilter,
|
|
Suche, Zeiträume, Diagramme und CSV-/PNG-Export.
|
|
- Hostwerte CPU, RAM, Root-Dateisystem, lokale HTTP-Dienstprüfungen; Aktualisierung alle fünf Sekunden.
|
|
- Celery-Worker und Task-Zustände, Laufzeiten, Retries, Zeitstempel und Ereignisdetail.
|
|
- PostgreSQL-Ereignisarchiv, konfigurierbare Aufbewahrung (Standard 90 Tage).
|
|
- Ausgehende HTTPS-Verbindung der Agenten, individuelle widerrufbare Tokens,
|
|
dauerhafte lokale SQLite-Outbox und idempotente Übertragung.
|
|
- Alarmregeln für Auslastung, Heartbeats, Dienste und Collector/Flower-Verbindung;
|
|
Quittierung, Wartungsmodus, Audit-Einträge und SMTP-Versand mit Wiederholung.
|
|
- Benutzerverwaltung über Django Admin; Leser und Operatoren (`is_staff`).
|
|
- Optionale dilibAI-Auswertung über einen OpenAI-kompatiblen Endpoint.
|
|
- Flower-Dateipersistenz zusätzlich zur unabhängigen zentralen PostgreSQL-Historie.
|
|
|
|
## Projektstruktur
|
|
|
|
| Verzeichnis | Aufgabe |
|
|
|---|---|
|
|
| config | Django, PostgreSQL, Celery, Redis |
|
|
| monitoring | API, Datenmodell, Ingest, Alarme, Reports, Migration |
|
|
| frontend | NiceGUI-Anwendung |
|
|
| agent | Host- und Celery-Collector, persistente Outbox |
|
|
| deploy | systemd, Nginx, Flower-Konfiguration |
|
|
| scripts | Installation, Secrets, Management, Datenbanksicherung |
|
|
| tests | API-, Zustands-, Alarm- und Outbox-Tests |
|
|
| docs | Einrichtung, Architektur, API, Betrieb und Abnahme |
|
|
|
|
## Technische Grenzen
|
|
|
|
Die fünfsekündige Darstellung ist Near-Realtime-Polling. Keine harten Echtzeitgarantien.
|
|
Celery-Events sind kein garantiert lückenloses Audit-Log: Ereignisse während eines
|
|
Collector-Ausfalls können fehlen. Bereits lokal erfasste Events überleben den
|
|
Agentenneustart. Flower liest die zentrale PostgreSQL-Historie nicht zurück; seine
|
|
Ansicht verwendet eine eigene Zustandsdatei. Eine bestehende Flower-Historie kann optional über die Flower-API als Task-Snapshots
|
|
importiert werden; siehe docs/FLOWER_IMPORT.md. Der Collector ordnet Cluster-Tasks seinem registrierten
|
|
Server zu; Worker-Namen bleiben separat sichtbar. Kein Queue-Tiefenmonitoring und
|
|
keine Remote-Neustart-/Task-Abbruchfunktion. Alle angemeldeten Benutzer sehen alle
|
|
Netzsegmente; dies ist keine Mandantentrennung.
|
|
|
|
Prüfstand dieser Version: siehe docs/VALIDATION.md.
|
|
PostgreSQL, Redis, reale Broker, SMTP, TLS und dilibAI müssen in Ihrer Umgebung
|
|
integriert und abgenommen werden. Es wurden keine Ihrer Server verändert.
|