OpenTelemetry Collector

Was ist der OpenTelemetry Collector?

Der OpenTelemetry Collector ist die Datenebene von OpenTelemetry. Anwendungen mit OpenTelemetry-SDKs können Daten zwar direkt an ein Backend senden, in Produktion schalten die meisten Teams aber einen Collector dazwischen. Er entkoppelt Anwendungen vom Backend, nimmt dem Anwendungsprozess Batching und Retries ab und gibt Plattform-Teams einen zentralen Ort, um Telemetrie zu filtern, anzureichern, zu samplen und zu routen.

Der Collector ist ein einzelnes Go-Binary, das per YAML konfiguriert wird. Das Projekt liefert mehrere Distributionen: otelcol (Kernkomponenten), otelcol-contrib (zahlreiche Community-Komponenten) und eine auf Kubernetes zugeschnittene Variante. Mit dem OpenTelemetry Collector Builder (ocb) bauen Sie außerdem eine eigene Distribution, die nur die benötigten Komponenten enthält.

Komponenten: Receiver, Processor, Exporter

• Receiver bringen Daten in den Collector. Sie lauschen (etwa der otlp-Receiver auf gRPC-Port 4317 und HTTP-Port 4318) oder holen aktiv ab (etwa prometheus für Scrapes, hostmetrics, filelog für Logdateien, kubeletstats).
• Processoren verändern Daten unterwegs: memory_limiter schützt vor Speichermangel, batch bündelt Daten für effizienten Export, k8sattributes und resourcedetection ergänzen Metadaten, filter und transform verwerfen oder ändern Daten, tail_sampling behält Traces abhängig von ihrem Ergebnis.
• Exporter senden Daten weiter, meist per otlp oder otlphttp, aber auch an Prometheus Remote Write, Kafka, Dateien oder herstellerspezifische Endpunkte.
• Connectoren verbinden zwei Pipelines, indem sie Exporter der einen und Receiver der anderen sind. Der spanmetrics-Connector erzeugt zum Beispiel aus Spans Metriken zu Requests, Fehlern und Dauer.
• Extensions ergänzen Funktionen außerhalb des Datenflusses, etwa health_check, pprof oder Authentifizierung.

So funktionieren Pipelines

Komponenten werden erst aktiv, wenn sie im Abschnitt service.pipelines referenziert sind. Jede Pipeline verarbeitet einen Signaltyp (Traces, Metriken oder Logs) und nennt ihre Receiver, eine geordnete Liste von Processoren und ihre Exporter. Die Reihenfolge der Processoren zählt: memory_limiter gehört an den Anfang, damit der Collector unter Speicherdruck Daten ablehnt, bevor er Arbeit investiert. Batching steht meist weiter hinten; neuere Collector-Versionen können auch direkt im Exporter bündeln und puffern.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 20
  k8sattributes: {}
  batch: {}
exporters:
  otlphttp:
    endpoint: https://otlp.example.com
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, k8sattributes, batch]
      exporters: [otlphttp]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, k8sattributes, batch]
      exporters: [otlphttp]

Der Endpunkt ist ein Beispiel. Ein Receiver kann mehrere Pipelines speisen, und eine Pipeline kann an mehrere Exporter verteilen. So senden Teams während einer Migration Daten parallel an zwei Backends.

Agent oder Gateway?

Muster	Wo es läuft	Typische Aufgaben
Agent	Auf jedem Host, als Kubernetes-DaemonSet oder als Sidecar	Lokales OTLP annehmen, Host- und Kubelet-Metriken erfassen, Logdateien lesen, Host- und Pod-Metadaten ergänzen
Gateway	Zentral und horizontal skaliert, pro Cluster oder Region	Tail-based Sampling, PII-Maskierung, Routing an mehrere Backends, zentrale Zugangsdaten

Die meisten Produktionsumgebungen kombinieren beides: Agents nah an der Workload, Gateways vor dem Backend. Für tail-based Sampling gilt eine Zusatzbedingung: Alle Spans eines Traces müssen dieselbe Gateway-Instanz erreichen. Deshalb nutzen Agents dafür meist den loadbalancing-Exporter, der nach Trace-ID verteilt.

Skalierung und Dimensionierung

Agents skalieren automatisch mit der Zahl der Nodes. Gateways sind meist zustandslos und lassen sich hinter einem Load Balancer horizontal skalieren, mit einer wichtigen Ausnahme: Komponenten mit Zustand, etwa Tail Sampling oder die Umrechnung von kumulativen in Delta-Werte, brauchen konsistentes Routing, damit zusammengehörige Daten immer auf derselben Instanz landen. Dimensionieren Sie Gateways anhand gemessener Durchsatz- und Speicherwerte pro Replika unter realistischer Last statt nach Gefühl, und planen Sie Reserven für Lastspitzen während Incidents ein, wenn das Telemetrievolumen oft stark ansteigt.

Best Practices

1. Immer memory_limiter konfigurieren und Speicherlimits für Container setzen, damit Überlast zu Back Pressure statt zu Abstürzen führt.
2. Den Collector selbst überwachen. Seine interne Telemetrie zeigt angenommene, abgelehnte und fehlgeschlagene Einträge pro Komponente; alarmieren Sie auf steigende Exportfehler und Queue-Größen.
3. Versionen pinnen und schlanke Distributionen bauen. Weniger Komponenten bedeuten weniger Angriffsfläche und weniger Überraschungen beim Upgrade.
4. Persistente Queues nutzen, wenn ein kurzer Backend-Ausfall keine Daten kosten darf.
5. Konfiguration in Git verwalten und wie Code ausrollen, auf Kubernetes etwa mit dem OpenTelemetry Operator.

Eine ausführliche Checkliste finden Sie im Beitrag OpenTelemetry Collector in Produktion.

Typische Fehler

• Komponenten definieren, aber keiner Pipeline zuordnen, sodass sie stillschweigend nichts tun.
• Tail Sampling auf mehreren Gateway-Replikas ohne Load Balancing nach Trace-ID betreiben.
• Receiver auf 0.0.0.0 öffnen, ohne Network Policies oder Authentifizierung.

Wie Obseria hilft

Obseria nimmt OTLP nativ an, jeder Collector exportiert also mit einem Standard-Exporter otlp oder otlphttp. Teams mit bestehenden OpenTelemetry-SDKs sehen typischerweise innerhalb von 15 Minuten den ersten Trace. Obseria Pipeline übernimmt bei Bedarf Filterung, Anreicherung und PII-Maskierung beim Ingest, und weil die Daten in OpenTelemetry-Formaten bleiben, können Sie sie jederzeit per OTLP exportieren. Mehr dazu unter OpenTelemetry in Obseria.