
Monitoring und Observability begleiten mich seit über zehn Jahren. Angefangen hat es 2014 mit selbst gebauten Lösungen auf Basis des ELK Stacks, heute steht Grafana im Zentrum – als gemeinsame Oberfläche für mich und die KI-Agenten, die meine Websites betreiben. Diese Seite erzählt, wie sich mein Blick auf Monitoring verändert hat und warum Observability im Agenten-Betrieb wichtiger ist denn je.
- Grafana (aktiv im Einsatz): zentrale Monitoring-Oberfläche für bernd-zuther.de und ketovavaria.de, auf der ich die Arbeit von KI-Agenten überprüfe.
- Gemeinsame Faktenbasis: Agenten fragen dieselben Daten ab und gleichen ihre eigene Arbeit mit der Realität ab.
- ELK Stack (nur noch Beobachtung): historische Erfahrung aus 2014 mit Eigenbau-Lösungen für Log-Aggregation und Profiling – im laufenden Projektbetrieb nutze ich ELK nicht mehr.
2014: Log-Aggregation und Profiling im Eigenbau mit ELK
Als Elasticsearch, Logstash und Kibana noch wenig verbreitet waren, habe ich mit genau diesem Trio eigene Werkzeuge gebaut. Zwei Artikel aus dieser Zeit sind bis heute im Archiv veröffentlicht: der selbst gebaute Java-Profiler, der Messdaten über Logstash in Elasticsearch schrieb und in Kibana sichtbar machte, und eine „Homebrew Edition“ als Alternative zu Splunk für die zentrale Log-Aggregation.
Der Reiz lag damals darin, mit freier Software etwas nachzubauen, wofür sonst teure kommerzielle Produkte nötig waren. Logs aus verschiedenen Quellen an einem Ort sammeln, durchsuchen und visualisieren – das war der Kern dessen, was man heute unter Observability versteht, auch wenn der Begriff damals noch kaum gebräuchlich war.
Warum ELK bei mir heute auf „Beobachtung“ steht
Auf meinem Technologie-Radar steht der ELK Stack deshalb im Ring Assess – als Beobachtung, nicht als aktive Empfehlung. Im laufenden Projektbetrieb setze ich ihn nicht mehr ein. Vieles aus den Eigenbau-Lösungen von 2014 würde ich heute anders angehen: Statt selbst Infrastruktur für Log-Sammlung und Auswertung zusammenzustecken, würde ich auf Cloud-native Dienste setzen, die Betrieb und Skalierung bereits mitbringen.
Die Erfahrung ist trotzdem wertvoll. Wer einmal selbst eine Pipeline von der Log-Zeile bis zum Dashboard gebaut hat, versteht, wo Daten verloren gehen, wo Latenzen entstehen und warum ein schönes Dashboard allein noch nichts über die Qualität der darunterliegenden Daten aussagt. Genau dieses Verständnis prägt mein heutiges Monitoring.
Heute: KI-Agenten betreiben meine Websites
Auf bernd-zuther.de und ketovavaria.de übernehmen KI-Agenten einen großen Teil der laufenden Arbeit. Sie schreiben Inhalte, deployen Änderungen, prüfen Ergebnisse und reparieren Fehler. Das spart enorm viel Zeit – wirft aber eine neue Frage auf: Woher weiß ich, dass die Arbeit tatsächlich erledigt ist?
Ein Agent, der „erledigt“ meldet, hat nicht automatisch recht. Er sieht die Welt nur durch die Werkzeuge, die man ihm gibt. Fehlt ihm ein Werkzeug oder liefert eines unvollständige Informationen, kann er überzeugt eine falsche Erfolgsmeldung abgeben. Agenten blind zu vertrauen, ist deshalb keine Option – wie ein stiller Ausfall eines Benachrichtigungskanals in der Praxis gezeigt hat.
Grafana als gemeinsamer Ort für Mensch und Agent
Deshalb betreibe ich ein eigenes Monitoring mit Grafana als zentraler Oberfläche für beide Websites. Grafana ist bei mir im Ring Einsatz – also aktiv in Benutzung, jeden Tag. Observability schließt dabei eine Lücke in zwei Richtungen:
Erstens für mich: Ich sehe, was auf den Websites wirklich passiert, ohne jede einzelne Nachricht eines Agenten nachprüfen zu müssen. Statt Berichten zu glauben, schaue ich auf Daten.
Zweitens für die Agenten: Sie können dieselben Daten abfragen und ihre eigene Arbeit gegen die Realität prüfen. Ein Agent, der eine Änderung deployt hat, kann im Monitoring nachsehen, ob sie tatsächlich die erwartete Wirkung zeigt – und nicht nur, ob sein Befehl ohne Fehlermeldung durchgelaufen ist.
Damit wird Grafana zum gemeinsamen Ort, an dem Mensch und Agent auf dieselben Fakten schauen. Das verändert die Zusammenarbeit grundlegend: Diskussionen drehen sich nicht mehr darum, wer recht hat, sondern darum, was die Daten zeigen.
Vom Eigenbau zum Betriebsfundament
Zwischen dem ELK-Experiment von 2014 und dem heutigen Grafana-Setup liegt eine klare Entwicklung. Damals ging es darum, überhaupt Sichtbarkeit herzustellen – Logs sammeln, durchsuchen, auswerten, oft aus technischer Neugier. Heute ist Observability ein Betriebsfundament: Sie ist die Voraussetzung dafür, dass ich Verantwortung an autonome Agenten abgeben kann, ohne die Kontrolle zu verlieren.
Geblieben ist die Grundidee, Daten aus verschiedenen Quellen zusammenzuführen und verständlich darzustellen. Verändert haben sich Zielgruppe und Zweck. Früher war das Dashboard ein Werkzeug für Entwickler, die ein Problem suchten. Heute ist es eine gemeinsame Wahrheit für ein Team aus Mensch und Maschine.
Ausblick
Mein Monitoring-Setup wächst mit jeder neuen Aufgabe, die Agenten übernehmen. Wie es im Detail aufgebaut ist und welche Erfahrungen ich damit im Alltag mache, beschreibe ich in einem eigenen Artikel, der in Planung ist. Bis dahin gilt die Kernaussage: Wer KI-Agenten produktiv einsetzt, braucht Observability – nicht als Kontrolle aus Misstrauen, sondern als gemeinsame Faktenbasis.
- Archivartikel: „Java Profiler – Marke Eigenbau mit Elasticsearch, Logstash und Kibana“ (2014)
- Archivartikel: „Splunk – Marke Eigenbau mit Elasticsearch, Logstash und Kibana“ (2014)
- Eigene Praxis: Grafana-Monitoring für den KI-Agenten-Betrieb von bernd-zuther.de und ketovavaria.de