Selbstdiagnostizierender Server
Fällt ein Dienst aus, sammelt der Server Belege, ein LLM stellt die Diagnose, und ich bekomme eine Nachricht mit Ursache und Lösung.
Privilege separationRedactionLLMsystemdUptime Kuma
Problem
Ein Alarm, der um 3 Uhr nachts nur "DOWN" sagt, startet eine lange Suche in Logs. Ich wollte die ersten zehn Minuten dieser Suche erledigt haben, bevor ich aufs Handy schaue.
Architektur
- 01 Monitor: DOWN
- 02 Re-check after 2 min
- 03 Whitelisted evidence + redaction
- 04 LLM with no tools
- 05 Push: cause + fix
Wichtige Entscheidungen
- Rechtetrennung: Ein deterministischer Collector führt eine feste Whitelist von Lesebefehlen aus; die Konfiguration wählt nur eingebaute Checks, niemals Befehle.
- Geheimnisse werden geschwärzt, bevor etwas den Collector verlässt (Tokens, Passwörter, E-Mail-Adressen, Push-Topics, lange Blobs) – mit Tests für die Schwärzung.
- Das Modell läuft als unprivilegierter Nutzer ohne Tools. Es diagnostiziert nur und führt nie eine Lösung aus.
- Flapping-Schutz, Ratenlimits und ein eigenes Monatslimit innerhalb des gemeinsamen KI-Budgets.
Was ich gelernt habe
- Ein LLM im Betrieb einzusetzen ist sicher, wenn das System drumherum so gebaut ist, dass es nichts tun kann.
- Gute Belege sind wichtiger als ein größeres Modell: Logs auf Warnungen und Fehler zu filtern halbierte den Input und verbesserte die Antworten.