init

README.md

@@ -1,2 +1,59 @@
-# dilib_operations
+# 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.