Zum Inhalt springen
CASOON

Agenten vor der KI-Ära: Was Telegraf über autonome Systeme lehrt

Telegraf läuft seit 2015 autonom in Millionen Infrastrukturen — 300+ Plugins, ein Binary, kein Mensch dahinter. Was klassische Agenten über Autonomie lehren.

7 Minuten
#Telegraf #Observability #Monitoring #Plugin-Architektur
SerieKI-Agenten
Teil 5 von 5

Der Begriff „Agent” ist in der Softwareentwicklung viel älter als KI-Agenten. Lange bevor Hermes, CrewAI oder AutoGen existierten, liefen Agenten bereits unbeaufsichtigt auf Servern, sammelten Daten, verarbeiteten sie und schrieben sie weiter — autonom, 24 Stunden am Tag, ohne menschlichen Eingriff. Telegraf von InfluxData ist eines der bekanntesten Beispiele: ein Daten-Agent, der seit 2015 in Produktion läuft, mit 17.500 GitHub-Stars, über 300 Plugins und einer Community von 1.200+ Contributors.

Wer versteht, wie Telegraf aufgebaut ist und warum es seit einem Jahrzehnt zuverlässig funktioniert, versteht etwas Grundlegendes über Agenten — etwas, das jenseits des KI-Hypes gilt.

GitHub: influxdata/telegraf — ~17.5k ⭐, 5.8k Forks

Was Telegraf ist

Telegraf sammelt Metriken, Logs und beliebige Daten aus einer Quelle, verarbeitet sie optional, und schreibt sie in ein Ziel. Das klingt trivial — ist es aber nicht, wenn man es auf hunderten von Systemen gleichzeitig betreibt, zuverlässig, mit minimalem Overhead und ohne dass jemand eingreift.

Die Architektur ist konsequent plugin-basiert und in vier Phasen gegliedert:

  • Input-Plugins erfassen Daten: CPU-Auslastung, Kafka-Lag, MQTT-Topics, OPC-UA-Signale von Industriemaschinen, Prometheus-Endpunkte, Docker-Statistiken, Windows-Event-Logs, SQL-Abfragen — über 300 Quellen.
  • Processor-Plugins transformieren Daten: Felder umbenennen, Werte berechnen, Tags hinzufügen, Datenpunkte filtern.
  • Aggregator-Plugins verdichten: Durchschnitte, Perzentile, Histogramme über Zeitfenster.
  • Output-Plugins schreiben: InfluxDB, Prometheus, Kafka, Elasticsearch, HTTP, Dateien — ebenfalls Dutzende Ziele.

Die Konfiguration geschieht per TOML-Datei. Danach läuft Telegraf — ein einzelnes statisch kompiliertes Go-Binary, keine externen Dependencies — und braucht keine weitere Aufmerksamkeit.

[[inputs.cpu]]
  percpu = true
  totalcpu = true

[[inputs.docker]]
  endpoint = "unix:///var/run/docker.sock"

[[outputs.influxdb_v2]]
  urls = ["http://localhost:8086"]
  token = "$INFLUX_TOKEN"
  bucket = "metrics"

Das ist Autonomie im klassischen Sinne: Das System handelt kontinuierlich nach definierten Regeln, ohne für jede Entscheidung auf menschliche Eingabe zu warten.

Die strukturelle Ähnlichkeit zu KI-Agenten

Wer die Architektur von Telegraf mit der von modernen KI-Agenten vergleicht, findet strukturelle Parallelen.

Plugins ≈ Skills. In Teil 1 dieser Serie wurde beschrieben, wie Skills wiederverwendbare Fähigkeiten sind, die ein Agent aktiviert, wenn sie zu einer Aufgabe passen. Telegraf-Plugins funktionieren nach demselben Prinzip: modular, kombinierbar, austauschbar, ohne den Rest des Systems zu berühren. Ein neuer Input-Plugin verändert nichts an den Output-Plugins. Ein neuer KI-Skill verändert nichts an den anderen Skills des Agenten.

Der autonome Loop. Telegraf läuft in einem definierten Takt: sammeln, verarbeiten, schreiben, warten, wiederholen. KI-Agenten laufen in einem analogen Loop: wahrnehmen, denken, handeln, warten, wiederholen. Die Struktur ist dieselbe — was sich unterscheidet, ist das „Denken”: bei Telegraf deterministisch und regelbasiert, bei KI-Agenten probabilistisch und interpretierend.

Der entscheidende Unterschied. Telegraf interpretiert nicht. Es sammelt CPU-Auslastung und schreibt sie weg — ohne zu bewerten, ob die Auslastung ein Problem ist, ob sie mit anderen Metriken zusammenhängt oder welche Aktion folgen sollte. Genau diese Lücke — zwischen Datenpunkt und Entscheidung — ist der Raum, in dem KI-Agenten operieren.

Warum Telegraf für KI-Agenten relevant wird

KI-Agenten sind selbst Systeme, die beobachtet werden müssen. Sie verbrauchen Token, erzeugen Latenz, schlagen fehl, rufen Tools auf — und all das passiert in Produktionsumgebungen, oft unbeaufsichtigt. Genau hier wird Telegraf wieder relevant: nicht als KI-System, sondern als Observability-Schicht für KI-Systeme.

Ein paar konkrete Messdimensionen:

Token-Verbrauch. Welches Modell, welcher Agent, welche Routine verbraucht wie viele Tokens pro Stunde? Ohne Messung keine Kostenkontrolle. Telegraf kann per HTTP-Input-Plugin API-Endpoints abfragen, Token-Zählungen als Metrik aufzeichnen und in Dashboards sichtbar machen.

Latenz und Fehlerquoten. Wie lange braucht ein Agent-Run? Wie oft scheitern Tool-Calls? Welche Input-Channels haben die höchste Fehlerrate? Das sind Standardmetriken — aber für KI-Agenten werden sie erst relevant, wenn jemand sie auch tatsächlich misst.

System-Seiteneffekte. KI-Agenten, die Code schreiben, PRs erstellen, Datenbanken abfragen oder externe APIs aufrufen, hinterlassen Spuren im restlichen System. Telegraf sieht diese Spuren: Docker-Container-Starts, Disk-I/O-Spitzen, Netzwerktraffic-Muster.

Telegraf fungiert dabei als neutrale Schicht, die keine Kenntnisse über KI hat — sie sieht nur Metriken. Das ist eine Stärke: Beobachtbarkeit ohne Abhängigkeit vom beobachteten System.

Das Konvergenz-Muster

Der Trend, der sich abzeichnet, geht in zwei Richtungen.

Erstens: Klassische Monitoring-Systeme werden um KI-Schichten ergänzt. Telegraf sammelt Metriken — und ein KI-Agent wertet sie aus, erkennt Anomaliemuster, schlägt Konfigurationsänderungen vor oder öffnet automatisch einen Incident-Ticket. Telegraf ist die Datenquelle, der KI-Agent ist die Interpretationsschicht.

Zweitens: KI-Agenten bekommen klassische Monitoring-Daten als Kontext. Teil 2 dieser Serie beschrieb Context Engineering — die Idee, dass gute Agenten-Ergebnisse weniger von Prompts abhängen als vom Kontext, den ein Agent beim Start einer Aufgabe bekommt. Metriken aus Telegraf sind genau dieser Kontext: „Der Server hat gerade 94% CPU-Auslastung, Disk-I/O ist erhöht, drei Pods wurden in den letzten zehn Minuten neu gestartet” — das ist ein anderer Ausgangspunkt für einen Debugging-Agent als kein Kontext.

Was Telegraf über Produktion lehrt

Telegraf läuft seit 2015 in Produktion. Das ist eine Seltenheit im schnellen Open-Source-Ökosystem, und es erklärt die vergleichsweise moderate Sternzahl: Dieses Tool ist in Infrastrukturen vergraben, nicht in Trend-Repositories entdeckt. 300+ Plugins bedeuten, dass Contributoren aus allen Bereichen — Industrie, Netzwerk, Cloud, IoT — ihre Integrationen beigesteuert haben, weil sie Telegraf tatsächlich einsetzen.

Das ist ein Muster, das im KI-Agenten-Bereich noch fehlt: Systeme, die über Jahre stabil laufen, in kritischen Umgebungen getestet wurden und einen Ruf für Zuverlässigkeit aufgebaut haben. Die meisten KI-Agenten-Frameworks sind ein Jahr alt, manche Wochen. Telegraf zeigt, was entsteht, wenn ein Agent-System genug Zeit hatte, sich zu bewähren.

Einordnung

Telegraf passt nicht in die Kategorie KI-Agenten — es ist kein LLM, es interpretiert nicht, es lernt nicht. Aber es zeigt etwas Wichtiges: Agenten, die autonom handeln, einen klaren Scope haben und konsequent plugin-basiert aufgebaut sind, funktionieren über Jahrzehnte.

Für Teams, die heute KI-Agenten einführen, ist Telegraf die naheliegende Wahl für die Observability-Schicht darunter: bewährt, schlankes Binary, keine Cloud-Abhängigkeit, 300+ Integrationen. Und für alle, die über Agenten nachdenken — ob mit oder ohne KI — ist Telegraf ein gutes Referenzmodell: Was bedeutet es, autonom zu handeln, ohne Interpretation? Und wo genau beginnt der Mehrwert der Interpretation?