Was ist OpenTelemetry Collector?
Der OpenTelemetry Collector ist ein Dienst, der zwischen deinen Anwendungen und dem Ziel der Telemetrie sitzt. Anwendungen schicken ihm Traces, Metriken und Logs, meist über OTLP, das eigene Protokoll von OpenTelemetry; der Collector bündelt sie, verwirft oder ändert, was du festlegst, und leitet Kopien an ein oder mehrere Backends weiter. Alles wird in einer YAML-Pipeline aus Receivern (Eingängen), Processors (Filtern, Sampling, Schwärzen), Exportern (Ausgängen) und Connectors (die Pipelines verbinden) konfiguriert.
Für Agenten-Teams ist das der Ort, an dem ein Trace, der einen Planer, drei Tool-Worker und zwei Modellanbieter durchläuft, wieder zusammenkommt, und an dem sich klärt, wo die End-to-End-Latenz geblieben ist. LLM-Spans folgen den GenAI-Semantikkonventionen von OpenTelemetry, einem gemeinsamen Satz von Namen wie gen_ai.request.model und gen_ai.usage.input_tokens, sodass ein Collector dieselben Spans an Langfuse oder Arize Phoenix für das LLM-Debugging und an Grafana oder Datadog für den Rest des Stacks schicken kann.
Das Kern-Repository enthält das Framework und eine kleine Auswahl an Komponenten; die meisten Receiver, Processors und Exporter liegen in opentelemetry-collector-contrib. Beide sind CNCF-Projekte unter Apache 2.0. Es gibt fünf offizielle Distributionen, darunter einen Core-Build, einen Contrib-Build und einen Kubernetes-Build, und der Collector Builder (ocb) kompiliert eine eigene Variante mit genau den Komponenten, die du brauchst.
Lohnt sich OpenTelemetry Collector?
Der Collector sorgt dafür, dass das Tracing eines Agentensystems portabel bleibt. Einmal mit OpenTelemetry instrumentieren, jeden Dienst auf einen Collector zeigen lassen, und die Entscheidung, ob Traces an Langfuse, Phoenix, Datadog oder alle drei gehen, wird zu einer YAML-Änderung statt einer Codeänderung. Nichts anderes in der Observability hat diese Reichweite: Das Kern-Repository hat rund 7.700 GitHub-Sterne und Contrib rund 5.000, Releases kommen alle paar Wochen, und Version 0.165.0 erschien am 6. November 2026.
Er übernimmt auch Aufgaben, die ein LLM-Backend nicht leisten kann. Ein Redaction- oder Transform-Processor kann Kundendaten aus Prompt-Attributen entfernen, bevor sie dein Netzwerk verlassen. Das zählt, weil die GenAI-Konventionen vollständige Ein- und Ausgabenachrichten in Span-Attribute legen und warnen, dass sie personenbezogene Daten enthalten können. Sampling senkt die Rechnung: Jeden Trace eines gesprächigen Agenten zu behalten ist teuer, und Tail Sampling kann nur die langsamen oder fehlgeschlagenen behalten. Langfuses eigene Doku zeigt einen Collector, der OTLP über gRPC empfängt und über HTTP weiterleitet, weil Langfuse gRPC noch nicht annimmt.
Die GenAI-Schicht ist noch in Bewegung. Keine der GenAI-Konventionen hat den Status Stable erreicht, sie sind 2026 in ein eigenes Repository umgezogen, und Attribute wurden bereits umbenannt (aus gen_ai.system wurde gen_ai.provider.name). Backends hinken der Spezifikation hinterher: Langfuse bildet noch die veralteten gen_ai.prompt und gen_ai.completion ab. Instrumentierungsversionen festzuschreiben und zu prüfen, was dein Backend liest, gehört zur Arbeit. Auch Filtern braucht Sorgfalt, denn Langfuse benötigt den Root-Span eines Traces, und wer ihn verwirft, bekommt einen unvollständigen Trace.
Die Versionsnummer sagt den Rest ehrlich. Das Binary ist noch 0.x, die Stabilität schwankt von Komponente zu Komponente, und Breaking Changes stehen in den Release Notes; 0.165.0 entfernte vier veraltete HTTP-Einstellungen. Contrib trägt den Großteil des Sicherheitsrisikos: Zu den Advisories von 2026 gehören eine Umgehung der Authentifizierung in der Azure-Auth-Extension und ein GitHub-Receiver, der seine konfigurierte Authentifizierung ignorierte. Ein Team mit einem Agentendienst und einem Backend gewinnt wenig, denn laut Doku ist direktes Senden für kleine Setups in Ordnung; der Nutzen beginnt beim zweiten Dienst oder beim zweiten Ziel.
Wo es sich lohnt
Ein Plattformteam bei einem Fintech, das einen Support-Agenten über sechs Dienste betreibt
Eine langsame Antwort von Anfang bis Ende verfolgen und Kontonummern aus dem Trace-Speicher heraushalten
Jeder Dienst exportiert OTLP an ein Collector-Gateway; ein Redaction-Processor maskiert Kontonummernmuster in gen_ai.input.messages vor dem Export an ein selbst gehostetes Langfuse. Der Collector selbst kostet nur die Pods, auf denen er läuft.
Ein SRE bei einem Händler, der Datadog pro aufgenommenem Span bezahlt
Details für LLM-Debugging behalten, ohne für jeden Agentenschritt zu zahlen
Alle Spans gehen an Phoenix oder Langfuse für das KI-Team, nur per Tail Sampling ausgewählte langsame oder fehlgeschlagene Traces an Datadog. Tail Sampling braucht alle Spans eines Traces auf demselben Collector, also kommt zuerst eine Load-Balancing-Schicht.
Ein CTO eines Startups mit 15 Leuten, der einen Anbieter für LLM-Observability wählt
Nicht an das erste Tracing-Werkzeug gebunden sein
Von Anfang an mit OpenTelemetry instrumentieren und über einen Collector leiten; ein zweites Backend zu testen heißt, einen Exporter hinzuzufügen und beide einen Monat parallel laufen zu lassen, ohne SDK-Wechsel.
Bevor du dich festlegst
- Einrichtung
- Starte das otelcol-contrib-Docker-Image oder Binary mit einer YAML-Konfiguration aus Receivern, Processors und Exportern; Langfuse veröffentlicht eine fertige Beispielkonfiguration für die Weiterleitung. Für Kubernetes gibt es eine eigene Distribution, und ocb baut ein verschlanktes Binary.
- Integrationen
- OTLP über gRPC und HTTP als Eingang; Exporter für die meisten Observability-Backends über Contrib. Langfuse nimmt OTLP nur über HTTP an /api/public/otel an; Phoenix und OpenLLMetry erzeugen und lesen OpenTelemetry-Spans.
- Daten und Datenschutz
- Selbst gehostet; er speichert nichts außer Puffern im Arbeitsspeicher, sofern nicht anders konfiguriert, und sendet Daten nur an die Exporter, die du angibst. GenAI-Spans können vollständige Prompts und Ausgaben enthalten, also gehört das Schwärzen hierher. Apache 2.0. Das Kern-Repository listet zwei Sicherheits-Advisories, Contrib mehrere in 2026.
- Kosten im großen Maßstab
- Keine Lizenz und keine bezahlte Edition; die Kosten sind Rechenleistung für Agent- oder Gateway-Collectors plus die Ingest-Preise der Backends. Dimensionierungswerte für LLM-Workloads sind nicht veröffentlicht.
- Grenzen
- 0.x-Releases mit Breaking Changes; GenAI-Konventionen im Status Development; Tail Sampling braucht eine Load-Balancing-Schicht; ein verworfener Root-Span zerbricht Traces in Langfuse. Rund 690 offene Issues und Pull Requests im Kern und 1.060 in Contrib.
Was gut ist
- Herstellerneutral: Backends wechseln oder ergänzen, ohne Anwendungscode anzufassen
- Schwärzen, Filtern und Tail Sampling, bevor Daten dein Netzwerk verlassen
- Überbrückt Protokolle, etwa gRPC rein und HTTP raus zu Langfuse
- Eigene Builds mit ocb halten das Binary klein
Was nicht
- Noch 0.x, mit Breaking Changes in den Release Notes
- GenAI-Konventionen noch nicht Stable und werden weiter umbenannt
- Contrib-Komponenten sind unterschiedlich ausgereift und tragen die meisten Advisories
- Ein weiterer Dienst, der betrieben, dimensioniert und überwacht werden muss
Am besten für
Agenten-Teams mit mehreren Diensten oder mehr als einem Telemetrie-Backend, die LLM-Traces schwärzen, sampeln und umleiten wollen, ohne Code zu ändern.
Alternativen zu OpenTelemetry Collector
OpenTelemetry Collector: häufige Fragen
- Lohnt sich OpenTelemetry Collector?
- Der Standardort, um Agenten-Traces zu sammeln, zu bereinigen und zu verteilen, sobald mehr als ein Dienst oder Backend beteiligt ist, und bis dahin ein zusätzliches bewegliches Teil. Wir bewerten es mit 4.4 von 5.
- Was kostet OpenTelemetry Collector?
- Kostenlos und Open Source unter Apache 2.0, ohne bezahlte Edition des Projekts. Kosten entstehen durch die Maschinen, auf denen er läuft, und die Backends, an die er sendet; kommerzielle Distributionen kommen von Observability-Anbietern.
- Welche Nachteile hat OpenTelemetry Collector?
- Noch 0.x, mit Breaking Changes in den Release Notes; GenAI-Konventionen noch nicht Stable und werden weiter umbenannt; Contrib-Komponenten sind unterschiedlich ausgereift und tragen die meisten Advisories; Ein weiterer Dienst, der betrieben, dimensioniert und überwacht werden muss.
- Für wen eignet sich OpenTelemetry Collector?
- Agenten-Teams mit mehreren Diensten oder mehr als einem Telemetrie-Backend, die LLM-Traces schwärzen, sampeln und umleiten wollen, ohne Code zu ändern.
- Was kostet OpenTelemetry Collector für ein Team oder im Produktivbetrieb?
- Keine Lizenz und keine bezahlte Edition; die Kosten sind Rechenleistung für Agent- oder Gateway-Collectors plus die Ingest-Preise der Backends. Dimensionierungswerte für LLM-Workloads sind nicht veröffentlicht.
- Ist OpenTelemetry Collector sicher für Firmendaten?
- Selbst gehostet; er speichert nichts außer Puffern im Arbeitsspeicher, sofern nicht anders konfiguriert, und sendet Daten nur an die Exporter, die du angibst. GenAI-Spans können vollständige Prompts und Ausgaben enthalten, also gehört das Schwärzen hierher. Apache 2.0. Das Kern-Repository listet zwei Sicherheits-Advisories, Contrib mehrere in 2026.
- Was sind die besten Alternativen zu OpenTelemetry Collector?
- Die nächsten Alternativen, die wir getestet haben, sind OpenLLMetry.
Antworten geprüft am 9. Nov. 2026.
Du entwickelst OpenTelemetry Collector? Zeig diese Bewertung auf deiner Website
