Betrieb, Abnahme und Wiederherstellung

Abnahme in Ihrer Infrastruktur

Anmeldung als Leser und Operator prüfen; Leser dürfen keine Alarme quittieren.
Einen echten Agenten und Collector anbinden; Host, Worker und Testtask kontrollieren.
HTTPS-Verbindung des Agenten kurz sperren: Outbox wächst. Wieder öffnen: Daten werden nachgeliefert, keine doppelten UUIDs. Alte Samples bleiben als alt erkennbar.
Agent mit gefüllter Outbox neu starten und Nachlieferung prüfen.
Django/UI und Flower separat neu starten. Historie im Dashboard und Flower prüfen.
Host-Heartbeat unterbrechen; nach Timeout und Alarmzyklus Alarm prüfen.
SMTP-Zustellung, Wiederholungen, Quittierung und automatische Auflösung prüfen.
Datenbanksicherung in separater Datenbank wiederherstellen und Stichproben vergleichen.
Mit erwarteter Host-/Task-Menge einen Lasttest ausführen; Aufbewahrung passend dimensionieren.
Browser auf Desktop und Mobilgerät, TLS und WebSocket-Verbindung hinter Nginx prüfen.

Diagnostik

sudo systemctl status dilib-api dilib-ui dilib-worker dilib-beat
sudo journalctl -u dilib-api -u dilib-ui -n 100 --no-pager
sudo journalctl -u dilib-agent -n 100 --no-pager

Keine Werte: Token, HTTPS-Verbindung, Systemzeit/NTP und Agentlog prüfen. Keine Tasks: Broker-URL und aktivierte Celery-Events prüfen; Collector muss laufen. Keine Mails: Beat, Worker, SMTP und Empfängerliste prüfen. Flower offline: lokale URL, Authentifizierung und Dienst prüfen. Dauerhafter HTTP-400 beim Upload: invaliden Payload in der Outbox untersuchen; Agent blockiert den Batch absichtlich und löscht keine Daten ungeprüft.

Backup

sudo -u postgres bash /opt/dilib-dashboard/scripts/backup.sh /var/lib/postgresql/dilib-backups

Zusätzlich geschützt sichern: /etc/dilib-dashboard, /etc/dilib-agent, /var/lib/dilib-dashboard und Flower-Dateien. SQLite-Outbox nur bei gestopptem Agenten vollständig kopieren (einschließlich WAL-Dateien) oder SQLite-Backup-API nutzen. Flower vor Kopie seines Dateistands stoppen. Backups verschlüsselt extern aufbewahren. Automatische Backupplanung und externe Ausfallüberwachung betreiberseitig einrichten.

Wiederherstellung zunächst in separate DB:

sudo -u postgres createdb --owner=dilib dilib_restore_test
sudo -u postgres pg_restore --no-owner --role=dilib --dbname=dilib_restore_test /pfad/backup.dump

Für Umschaltung Dienste stoppen, DATABASE_URL auf geprüfte Wiederherstellung setzen, Migration prüfen und Dienste wieder starten. Keine laufende DB blind überschreiben. Nach Datenverlust können bereits bestätigte Agentenevents nicht erneut aus der Outbox rekonstruiert werden; RPO richtet sich nach Backup/WAL-Archivierungsstrategie.

Updates

Backup anfertigen, Änderungen zuerst in Testumgebung prüfen, Dienste stoppen, Code aktualisieren, Requirements installieren, Migration und collectstatic ausführen, Dienste starten und Abnahmetests wiederholen. Getestete Paketstände stehen in requirements.txt; Versionsbereiche für bewusste Updates in requirements.in.

Lokale Prüfungen dieser Lieferung

Prüfstand und Testanzahl: siehe VALIDATION.md. Tests umfassen: Authentifizierung und Ablauf, Rate Limit, Rollen, Batchvalidierung, Idempotenz, verspätete Task-Events, veraltete Hostwerte, Alarme/Quittierung, Retention, SMTP-Wiederholung, API/CSV/PNG sowie persistente Agent-Outbox/Redaktion. Tests liefen mit SQLite; PostgreSQL-Sperrverhalten und externe Integrationen sind nicht durch diesen lokalen Testlauf nachgewiesen.

Die NiceGUI-Anwendung startete lokal ohne Startfehler. Eine visuelle Browserabnahme war hier mangels verfügbarer Browserinstallation nicht möglich.

3.6 KiB Raw Blame History