Telemetrie-Kosten für KI-Agenten mit dem OpenTelemetry Collector senken

Adnan Rahic von Bindplane by Dynatrace hat am 22. Oktober 2026 einen praxisorientierten Leitfaden veröffentlicht, der detailliert beschreibt, wie sich OpenTelemetry-Pipelines für KI-Agenten optimieren lassen. Der Artikel befasst sich mit einem häufig auftretenden Problem in Produktionsumgebungen: Die übermäßige Menge an Telemetriedaten, die durch Tools wie Claude Code erzeugt wird, führt zu hohen Speicherkosten und einer unhandlichen Datenkardinalität.

Was passiert ist

Die Aktivierung der Telemetrie für einen KI-Coding-Agenten führt oft zu einer enormen Datenmenge, deren Speicherung teuer und deren Interpretation schwierig ist. In einem Testfall, in dem Claude Code zwei fehlgeschlagene Tests korrigierte und Randtests hinzufügte, erzeugte ein einzelner Durchlauf 181 Telemetrie-Datensätze und 289 KB JSON-Daten. Diese Daten enthalten vollständige Prompts, Datei-Inhalte und Diffs, von denen die meisten für das laufende operative Monitoring unnötig sind.

Das Kernproblem besteht darin, dass die Standard-Instrumentierung für das Debugging einzelner Entwickler-Sitzungen konzipiert ist, nicht für das Management eines gesamten Agenten-Fleets. Bei großem Maßstab, beispielsweise bei 200 Sitzungen pro Tag, wird dieser Ansatz nicht tragfähig. Metriken tragen Attribute mit hoher Kardinalität wie Session-ID und Benutzer-E-Mail-Adresse, was Hunderte eindeutige Zeitreihen erzeugt, die nie ablaufen. Darüber hinaus werden Tool-Inhalte in Traces und Logs dupliziert, was den Speicherbedarf weiter erhöht.

Rahic zeigt auf, dass es nicht darum geht, willkürlich weniger Daten zu sammeln, sondern nur jene zu behalten, die spezifische operative Fragen beantworten. Indem die Daten im OpenTelemetry Collector vor der Übertragung an das Backend geformt werden, können Teams die Kosten erheblich senken, ohne die Sichtbarkeit auf kritische Leistungs- und Kostenmetriken zu verlieren.

Wie es funktioniert

Die Lösung umfasst die Konfiguration des OpenTelemetry Collectors so, dass jedes Signal in zwei separate Pipelines aufgeteilt wird: eine Rohdaten-Pipeline und eine optimierte Pipeline. Beide Pipelines erhalten byte-identische Eingaben von einem einzigen OTLP-Empfänger, um einen ehrlichen Vergleich zu gewährleisten. Die Rohdaten-Pipeline fungiert als Kontrollgruppe und enthält lediglich einen Dienstnamen und einen Batch-Prozessor, während die optimierte Pipeline spezifische Filter und Transformationen anwendet.

In der optimierten Pipeline entfernen Prozessoren Dimensionen mit hoher Kardinalität und redundante Inhalte. Beispielsweise werden vollständige Datei-Inhalte aus Tool-Ausgaben aus Spans und Logs entfernt, sodass nur wesentliche Metadaten übrig bleiben. Metriken werden vorab summiert oder angepasst, um sitzungsspezifische Kennungen zu entfernen, die zu einer Explosion der Kardinalität führen. Dies stellt sicher, dass die an das Backend gesendeten Daten schlank sind und sich auf handlungsrelevante Erkenntnisse konzentrieren.

Das Setup nutzt Grafana LGTM für beide Pipelines, um den Unterschied zu visualisieren. Dashboards vergleichen Kardinalität, Bytes pro Minute und Datensatzanzahlen nebeneinander. In einer Produktionsumgebung könnte die Rohdaten-Pipeline zur gelegentlichen tiefgehenden Fehleranalyse in den Objektspeicher geleitet oder ganz verworfen werden, während die optimierte Pipeline das primäre Monitoring-Backend speist.

Wichtige Details

• Ein einzelner Claude Code-Durchlauf generierte 181 Telemetrie-Datensätze und 289 KB JSON, wenn alle Inhaltsflags aktiviert waren.
• Standard-Metriken enthalten Attribute mit hoher Kardinalität wie session.id und user.email, was bei nur acht Metriken über 25 Sitzungen hinweg 300 Zeitreihen erzeugt.
• Tool-Inhalte werden sowohl in Traces als auch in Logs dupliziert, wobei Datei-Inhalte als Span-Ereignisse und Log-Attribute gespeichert werden.
• Die optimierte Pipeline reduziert die Anzahl der Metrik-Zeitreihen von 300 auf 12, indem sitzungsspezifische Dimensionen entfernt werden.
• Sechs zentrale Fragen treiben die Optimierung an: Kosten pro Modell, Token-Nutzung, Fehlerraten bei Tools, Ablehnung von Bearbeitungen, Latenz und Fehler.
• Die Metrik otelcol_exporter_enqueue_size_bytes existiert nur auf der Detailebene, wenn die Sendewarteschlange aktiviert ist.

Warum das wichtig ist

Für Engineering-Teams, die mit KI-Agenten arbeiten, können Telemetrie-Kosten schnell außer Kontrolle geraten, wenn sie nicht verwaltet werden. Eine hohe Kardinalität in Metriken führt zu steigenden Speicher- und Abfragekosten in Observability-Plattformen, während große Trace- und Log-Nutzlasten Bandbreite und Indexierungsressourcen verbrauchen. Durch das Filtern dieser Daten auf Ebene des Collectors können Organisationen umfassende Transparenz wahren, ohne die prohibitiven Kosten für die Speicherung jedes Prompts und jeder Dateiänderung.

Darüber hinaus verbessert die Fokussierung auf spezifische operative Fragen das Signal-Rausch-Verhältnis für Entwickler und SREs. Anstatt durch Textwände zu blättern, können Teams klare Indikatoren für die Leistung der Agenten überwachen, wie etwa die Token-Nutzung nach Typ, Erfolgsraten der Tools und Latenzzeiten. Dieser Wandel von der reinen Datensammlung hin zu einer zielgerichteten Observability ermöglicht schnellere Fehlerbehebungen und ein effektiveres Kostenmanagement.

Was Sie tun können

• Identifizieren Sie die sechs zentralen Fragen, die Ihr Team zur Leistung von KI-Agenten beantworten muss, wie etwa Kosten pro Modell und Fehlerraten bei Tools.
• Konfigurieren Sie Ihren OpenTelemetry Collector so, dass getrennte Rohdaten- und optimierte Pipelines für die Telemetrie von KI-Agenten erstellt werden.
• Entfernen Sie Attribute mit hoher Kardinalität wie Session-IDs und Benutzer-E-Mail-Adressen aus den Metriken, um eine Explosion der Zeitreihen zu verhindern.
• Streichen Sie vollständige Datei-Inhalte und Prompts aus Trace-Spans und Logs und behalten Sie nur wesentliche Metadaten und Fehlerinformationen bei.
• Verwenden Sie wo möglich vorab summierte Metriken, um die Anzahl der an Ihr Backend gesendeten Datenpunkte zu reduzieren.
• Visualisieren Sie den Unterschied zwischen Rohdaten- und optimierten Datenströmen, um Einsparungen beim Speicherplatz zu validieren und sicherzustellen, dass keine kritischen Daten verloren gehen.