Fünf Monitoring-Systeme, und keins hat gemerkt, dass die Datenbank leer ist

Kurzfazit: Monitoring beantwortet die Frage „lebt es?" — nicht die Frage „braucht es jemand?". Ein Container lief in meiner Infrastruktur drei Monate lang komplett unbenutzt, überwacht von fünf Systemen, grün auf allen Dashboards. Wie ein KI-Agent das aufgedeckt hat, und welcher 2-Stunden-Fix Verwaisung ab jetzt automatisch meldet.

Praxisserie „Agentic Ops", Folge 1. Transparenz: Alle Folgen basieren auf realen Vorfällen aus meiner eigenen Infrastruktur; Details, die Rückschlüsse auf interne Systeme erlauben, sind verallgemeinert.

Ich betreibe als Einzelperson einen Proxmox-Cluster mit rund 90 Gästen — Container und VMs für ein gutes Dutzend Projekte. Jeder neue Dienst durchläuft bei mir eine Monitoring-Pflicht: Verfügbarkeits-Check, CVE-Scanner, Runtime-Detection, zentrale Logs, Metriken. Fünf Systeme, die Tag und Nacht wachen. Klingt solide.

Heute hat mir ein KI-Agent gezeigt, dass alle fünf drei Monate lang etwas übersehen haben. Nicht, weil sie kaputt waren. Sondern weil sie die falsche Frage beantworten.

Der Verdacht

Angefangen hat es mit einer harmlosen Frage: Ich überlegte, ob eine Vektor-Datenbank für meine lokale Wissens-Suche sinnvoll wäre. Dabei stolperte der Agent über einen Container in meinem Inventar: eine Qdrant-Instanz, 2 Kerne, 4 GB RAM, Tag prod. Auffällig: keine eigene Doku-Seite, kein dokumentierter Nutzer, tauchte nur in Inventarlisten auf.

Der Agent formulierte einen Verdacht — und, wichtiger: er formulierte, was ihn widerlegen würde. Welche Collections liegen in der Datenbank? Wer greift zu? Gibt es undokumentierte Konsumenten?

Die Beweiskette

Am Abend, mit Zugang zum Netz, lief die Prüfung. Das Ergebnis war deutlicher als erwartet:

Die Datenbank enthielt null Collections. Das Storage-Verzeichnis: leer, Zeitstempel = Erstellungstag des Containers, drei Monate zuvor. Gesamtdatenmenge: 20 Kilobyte Verwaltungsstruktur.

Das komplette Container-Log enthielt 14 HTTP-Requests. Alle vierzehn: Smoke-Tests vom Einrichtungstag. Danach — nichts. Kein einziger Schreibzugriff. In drei Monaten. Der Rest des Logs: stündlich dieselbe Fehlermeldung, weil die Datenbank ihre Telemetrie nicht nach Hause funken durfte. 24 Zeilen am Tag, wie ein Metronom der Sinnlosigkeit.

Der vermutete Nutzer hat nie existiert. Es gab einen SSH-Tunnel-Dienst, der die Datenbank an ein anderes System anbinden sollte. Die Unit-Datei lag brav im systemd-Verzeichnis — aber ohne Aktivierungs-Symlink. Sie wurde kopiert und nie aktiviert. Der Tunnel ist kein einziges Mal gelaufen.

Die Gegenprobe über die ganze Flotte — jeder plausible Konsument, per grep durch Configs und per conntrack auf offene Verbindungen: nichts. Der spannendste Befund war also nicht „wird nicht mehr benutzt". Sondern: wurde nie benutzt. Ein Container, angelegt für ein Projekt, das dann anders abbog — und der einfach weiterlief. Gesichert alle vier Stunden. Überwacht von fünf Systemen. Grün auf allen Dashboards.

Warum waren fünf Monitoring-Systeme blind?

Der Punkt ist unbequem, aber einfach: Monitoring beantwortet die Frage „lebt es?" — nicht die Frage „braucht es jemand?"

• Der Verfügbarkeits-Check pingte: Container antwortet. Grün.
• Der CVE-Scanner scannte: keine kritischen Lücken. Grün.
• Die Runtime-Detection horchte: keine verdächtigen Prozesse. Grün.
• Die Logs flossen: Der Log-Agent lieferte brav die stündliche Telemetrie-Fehlermeldung ab. Grün.
• Die Metriken zeigten: 86 MB RAM von 4096 belegt. Auch grün — nur hat niemand gefragt, warum eine „Prod-Datenbank" seit Monaten bei 2 % Speicher idlet.

Verwaisung ist kein Ausfall. Sie ist das Gegenteil: perfekter, störungsfreier, kompletter Leerlauf. Und je besser deine Betriebsdisziplin ist, desto länger überlebt sie — denn nichts geht je kaputt.

Wie erkennt man verwaiste Systeme automatisch?

Die Konsequenz haben wir noch am selben Abend gebaut, in etwa zwei Stunden, mit Bordmitteln:

1. Experimente bekommen ein Ablaufdatum. Jeder Gast mit Lifecycle „experiment" trägt jetzt eine TTL-Zeile in seinen Metadaten: TTL: 2026-10-01. Nach Ablauf wird er gemeldet — egal, wie grün er ist. Nicht automatisch gelöscht, gemeldet. Die Entscheidung bleibt beim Menschen; nur das Vergessen wird abgeschafft.

2. Ein Orphan-Scan misst echten Service-Traffic. Täglich zieht ein Skript auf jedem Host eine conntrack-Stichprobe je laufendem Gast: Gibt es eingehende Verbindungen, die nicht von Monitoring, SSH oder Metrik-Scraping stammen? Montags kommt ein Telegram-Report: Welche Gäste hatten 30 Tage keinen einzigen echten Zugriff, welche TTLs sind abgelaufen. Die Handdiagnose von heute — automatisiert.

Der erste Testlauf fand übrigens sofort drei weitere Konfigurations-Lücken in Bestandssystemen. Solche Detektoren zahlen sich schneller aus, als man sie schreibt.

Was hat das mit KI zu tun?

Die ehrliche Antwort: Die gesamte Untersuchung — Verdacht aus der Doku, Beweiskette am Live-System, Gegenprobe über acht Kandidaten-Systeme, Stilllegung mit Backup und Monitoring-Pause, Bau und Test des Detektors — lief in einer einzigen Session eines KI-Agenten, mit meinen Freigaben an den Entscheidungspunkten. Zeitaufwand auf meiner Seite: ein paar Minuten Entscheidungen.

Aber die eigentliche Lektion ist keine KI-Lektion, sondern eine Betriebs-Lektion, die durch KI nur endlich bezahlbar wird: Infrastruktur lügt nicht, aber sie schweigt. Ein System, das niemand braucht, meldet sich nie von selbst. Man muss die Frage „wer benutzt das eigentlich?" systematisch stellen — und das war bisher zu teuer, um es wöchentlich zu tun.

Jetzt kostet es einen Cron-Job.

Häufige Fragen

Warum erkennt normales Monitoring keine verwaisten Systeme?

Weil Monitoring auf Ausfall optimiert ist: Es schlägt an, wenn etwas nicht antwortet, überlastet ist oder Fehler wirft. Ein verwaistes System tut nichts davon — es antwortet zuverlässig, verbraucht kaum Ressourcen und wirft keine Fehler. Genau dieses Muster (dauerhaft gesund, dauerhaft unbenutzt) muss man separat messen, etwa über eingehende Verbindungen abzüglich Monitoring-Traffic.

Reicht es nicht, die CPU-Auslastung anzuschauen?

Nein. Viele legitime Dienste idlen die meiste Zeit (Backup-Ziele, Standby-Systeme, selten genutzte interne Tools), und manche verwaisten Dienste erzeugen trotzdem Last (Cron-Jobs, Telemetrie, Log-Rotation). Entscheidend ist nicht Aktivität, sondern Nachfrage: Greift irgendjemand außer der eigenen Infrastruktur zu?

Sollte ein Verwaisungs-Scan Systeme automatisch abschalten?

Nein — melden, nicht handeln. Ein Traffic-Sample kann saisonale Nutzung übersehen (Jahresabschluss-Tools, Notfall-Systeme). Die Meldung gehört in einen wöchentlichen Report, die Stilllegungs-Entscheidung zu einem Menschen, und die Stilllegung selbst folgt einem Muster mit Backup und Beobachtungsfrist statt sofortiger Löschung.

In eigener Sache

Diese Serie dokumentiert, wie eine Ein-Personen-Infrastruktur mit KI-Agenten betrieben wird — echte Vorfälle, echte Fixes, keine Labor-Demos. Folge 2 erzählt vom Cryptominer, der zweimal kam: Der Cryptominer, der zweimal kam. Folge 3 zeigt das System dahinter: Wie ich einer KI beigebracht habe, meine Infrastruktur zu betreiben.

Die Vorlagen aus dieser Serie — Gast-Standard mit TTL-Konvention, Go-Live-Checkliste, Orphan-Scan — gibt es jetzt als Selfhost-Standards Pack (ab 79 €). Abonniere die KI-Rundschau, wenn du Updates zuerst erfahren willst. Und wenn du KI-Agenten in deinem Unternehmen produktiv einsetzen willst: ai.solavia.at.