OpenTelemetry-Collector: Konfiguration, Pipelines und Betrieb

otelcol (OpenTelemetry Collector) und das Werkzeug otel-cli gehören zum OpenTelemetry-Ökosystem. Der Collector ist das zentrale Element: Er nimmt Telemetriedaten entgegen, verarbeitet sie und leitet sie an ein oder mehrere Backends weiter. Diese Referenz zeigt Konfiguration, Prüfung und Diagnose.

Start und Prüfung

# Mit Konfigurationsdatei starten
otelcol --config /etc/otelcol/config.yaml

# Konfiguration vor dem Start prüfen
otelcol validate --config /etc/otelcol/config.yaml

# Als Dienst
systemctl status otelcol
systemctl enable --now otelcol

# Endpunkte: OTLP gRPC 4317, OTLP HTTP 4318, interne Metriken 8888

Aufbau der Konfiguration

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  prometheus:
    config:
      scrape_configs:
        - job_name: node
          static_configs:
            - targets: ["web01:9100"]

processors:
  batch:
    timeout: 5s
    send_batch_size: 1000
  memory_limiter:
    check_interval: 1s
    limit_percentage: 75
    spike_limit_percentage: 20
  resourcedetection:
    detectors: [env, system]

exporters:
  otlphttp/tempo:
    endpoint: http://tempo:4318
  prometheusremotewrite:
    endpoint: http://mimir:9009/api/v1/push
  debug:
    verbosity: basic

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/tempo]
    metrics:
      receivers: [otlp, prometheus]
      processors: [memory_limiter, batch]
      exporters: [prometheusremotewrite]
  telemetry:
    metrics:
      readers:
        - pull:
            exporter:
              prometheus:
                host: 0.0.0.0
                port: 8888

Drei Bausteintypen sind zu unterscheiden: Receivers nehmen Daten an, Processors verändern sie, Exporters geben sie weiter. Die service-Sektion verbindet sie zu Pipelines pro Signalart (traces, metrics, logs).

Zwei wichtige Prozessoren

• memory_limiter: gehört an den Anfang jeder Pipeline. Bei Speicherdruck verwirft der Collector Daten, statt selbst abzustürzen – ein abgestürzter Collector verliert alles, ein überlasteter nur einen Anteil.
• batch: gehört ans Ende. Es bündelt Datensätze und reduziert die Anzahl der Netzwerkaufrufe an das Backend erheblich.

Konfiguration prüfen und testen

# Gültigkeit prüfen
otelcol validate --config config.yaml

# Mit Debug-Ausgabe starten: zeigt Datensätze auf der Konsole
# exporter "debug" in die Pipeline aufnehmen
otelcol --config config.yaml | grep -i "Resource"

# Testdaten erzeugen
otel-cli exec --service demo --name "test-span" --attribute key=value true
otel-cli span --service demo --name "mein-span" --endpoint localhost:4317

# Direkt per curl testen (OTLP/HTTP, Protobuf)
# Praktischer: ein SDK-Beispielprogramm senden lassen

Betrieb und Skalierung

# Collector als DaemonSet auf jedem Knoten (Konfiguration in Kubernetes)
# kubectl get pods -n observability -l app=otelcol

# Collector als Deployment für zentrale Aggregation
# - Agent-Modus: jede Node liefert an den zentralen Collector
# - Gateway-Modus: nur Export nach außen

# Mehrere Collectoren hintereinander: loadbalancing-Exporter
exporters:
  loadbalancing:
    routing_key: traceID          # oder service
    protocol:
      otlp:
        ttl: 30s
        timeout: 5s
    resolver:
      static:
        hostnames:
          - otelcol-0:4317
          - otelcol-1:4317

Der loadbalancing-Exporter ist die Antwort auf horizontale Skalierung: Er verteilt Spans desselben Traces immer an dieselbe Instanz, weil sonst Teile eines Traces in verschiedenen Collectoren landen und dort verworfen würden.

Wichtige Filter und Transformationen

processors:
  # Nicht benötigte Attribute entfernen (spart Volumen und Kosten)
  attributes/scrub:
    actions:
      - key: http.request.header.authorization
        action: delete
      - key: k8s.pod.uid
        action: delete

  # Nur bestimmte Dienste durchlassen
  filter/traces:
    error_mode: ignore
    traces:
      span:
        - 'attributes["service.name"] == "healthcheck"'

  # Attribute umbenennen
  transform:
    trace_statements:
      - context: span
        statements:
          - set(attributes["env"], "prod")

Praxis-Tipps

• memory_limiter immer zuerst: Ohne ihn kann der Collector bei Lastspitzen den gesamten Knoten in Speichernot bringen.
• Debug-Exporter nur kurzzeitig: Er schreibt jeden Datensatz auf die Konsole – bei realer Last ist das selbst eine Lastursache.
• Sampling nicht vergessen: Vollständiges Tracing in großen Umgebungen erzeugt enormes Volumen. Sampling-Entscheidungen gehören in die Anwendung oder in den Collector, nicht ins Backend.
• Auth für OTLP: Ein offener OTLP-Empfänger im Netz nimmt Daten von jedem an. Für den internen Betrieb genügt TLS plus ein Token-Header; nach außen gehört ein Reverse-Proxy mit Authentifizierung davor.

Verwandte Grundlagen: OpenTelemetry, Observability, promtool-Befehle, Jaeger.