Wo ein LLM in einem Monitoring-System wirklich hingehört

Die Aufgabe

Im Netz laufen ständig geplante Wartungsarbeiten, und parallel dazu treten Störungen auf. Gefährlich sind ihre Überschneidungen, etwa wenn ein Trupp einen Ring für Wartungsarbeiten abschaltet, wo die Redundanz durch eine Störung bereits verloren ist. Das hier beschriebene System erkennt solche Überschneidungen nach Stadt und Zeitfenster und warnt davor, bevor die Arbeiten beginnen.

Ereignisse kommen aus vier Quellen: dem Monitoringsystem, dem BPMS, der Firmen-E-Mail und manuellen Eingaben. Strukturiert sind alle außer der E-Mail.

Die Regel: ein LLM dort, wo es kein Schema gibt

Alles durch ein Modell zu schicken, ist teuer, sowohl finanziell als auch beim Debugging. In diesem System wird das Modell nur zur Auswertung der Schreiben externer Betreiber eingesetzt.

Diese Schreiben haben kein Schema. Ein Betreiber schreibt „planmäßige Wartungsarbeiten am 12.07. von 01:00 bis 05:00 Uhr Moskauer Zeit, Stadt N“, ein anderer hängt eine Tabelle an, und bei einem dritten muss man das Datum aus zwei Absätzen zusammensetzen. Reguläre Ausdrücke scheitern an solchen Schreiben jede Woche, das Modell kommt damit zurecht.

Alles andere ist gewöhnlicher deterministischer Code:

• Abfrage der Monitoring-API und Lesen der BPMS-Queue;
• Deduplizierung von Ereignissen;
• Vergleich von Zeitintervallen und Suche nach Überschneidungen;
• automatisches Schließen nicht mehr relevanter Konflikte;
• Metriken, Oberfläche, CSV/Excel-Import.

Für den Vergleich zweier Intervalle braucht man kein neuronales Netz. Die Bedingung start_a < end_b and start_b < end_a genügt, und sie liefert am Montag dieselbe Antwort wie am Freitag.

Was das in der Praxis bringt

Vorhersagbarkeit. Wird ein Konflikt falsch erkannt, lässt sich die Fehlerstelle finden. Trifft ein Modell die Entscheidung, ist die Ursache viel schwerer nachzuvollziehen.

Kosten. Das Modell wird im Umfang der eingehenden E-Mails aufgerufen, der um Größenordnungen kleiner ist als die Menge der Monitoring-Ereignisse.

Testbarkeit. Die Konflikterkennung ist durch Unit- und Integrationstests mit einer Datenbank im Container abgedeckt. Die LLM-Auswertung lässt sich so nicht testen, dort werden nur das Antwortformat und die Robustheit gegenüber fehlerhaften Eingaben geprüft.

Architektur aus drei Diensten

mail-agent  → IMAP → Rauschfilter → LLM → strukturiertes Ereignis ─┐
                                                                   ↓
Monitoring / BPMS / manuelle Eingabe ───────────────→ detector (Dedup, Suche nach
                                                                 Überschneidungen,
                                                                 Auto-Close)
                                                                   ↓
                                                        PostgreSQL → UI

Jeder Dienst liefert Metriken an Prometheus, Logs werden in Loki gesammelt, und das Datenbankschema wird über Migrationen versioniert. Ohne eine solide Infrastruktur dieser Art nützt auch der interessanteste Teil eines Systems niemandem.

Was ich anders machen würde

Den Rauschfilter vor dem Modell hätte ich gleich zu Beginn einbauen sollen, noch vor der ersten Token-Rechnung. Der Großteil der Firmen-E-Mails hat nichts mit geplanten Arbeiten zu tun und lässt sich mit einfachen Regeln aussortieren.