OpenTelemetry Collector — Pipelines & Deployment

OTel Collector: receivers, processors, exporters. Tail-based vs head-based sampling. Agent/Gateway topology. Kubernetes Operator.

Overview

Overview

The OpenTelemetry Collector is a vendor-agnostic telemetry agent and pipeline that receives, processes and exports traces, metrics and logs. It decouples instrumented services from observability backends: you reconfigure sampling or add a new destination without redeploying applications.

What the Collector handles

  • Protocol conversion — Jaeger or Zipkin in, OTLP out
  • Sampling decisions — Head-based or tail-based
  • Attribute enrichment — Add Kubernetes or environment metadata
  • PII redaction — Strip sensitive fields before export
  • Fan-out — One stream to several destinations

Pipeline components

Each pipeline is configured per signal type (traces, metrics, logs) in YAML.

  • Receivers — Accept telemetry — OTLP (gRPC/HTTP), Jaeger, Zipkin, Prometheus scrape, Fluentd, StatsD
  • Processors — Transform data — batch, memory limiter, attribute enrichment, filter, tail-based sampling, PII redaction
  • Exporters — Ship to backends — OTLP, Prometheus remote write, Jaeger, Datadog, Grafana OTLP, AWS X-Ray

> [!IMPORTANT] The memory limiter processor always goes first in the processor chain.

Head-based vs tail-based sampling

  • Decision point — At trace start — After the complete trace is buffered
  • Cost — Fast, zero memory overhead — Buffers spans in memory
  • Can sample on outcome? — No — Yes: "100% errors, 1% success"
  • Routing requirement — None — Sticky routing: every span of a trace must reach the same Gateway collector, via TraceID hash

Agent vs Gateway topology

  • Agent — One Collector DaemonSet per node — Receives from local apps; lightweight processing (batch, attribute enrichment); forwards to the Gateway
  • Gateway — Centralized, horizontally scaled Collectors — Expensive operations: tail sampling, PII redaction, rate limiting

The Kubernetes Operator

The OpenTelemetry Operator manages Collectors as OpenTelemetryCollector CRDs in Deployment, DaemonSet, StatefulSet or Sidecar mode, with HPA auto-scaling.

> [!TIP] Auto-instrumentation: add the annotation instrumentation.opentelemetry.io/inject-java: "true" and the operator's mutating webhook injects the OTel SDK with no code changes.

Sign up free to read the full topic

More Observability topics

Start free on Cariara · Coding problems · System design studio