OpenTelemetry Collector

The OpenTelemetry Collector serves as a vendor-agnostic engine designed to receive, process, and export telemetry data—including metrics, logs, and traces. Its primary value lies in decoupling data generation from data consumption. Applications simply emit telemetry data to the Collector without needing to know whether the final destination is Jaeger, Prometheus, Loki, or a commercial APM platform.

The Collector supports flexible deployment topologies. It can run as a sidecar or DaemonSet alongside application instances, or operate as a centralized standalone gateway. By utilizing YAML-based configuration files to define data flows, it delivers exceptional extensibility and robust observability.
An OpenTelemetry Collector configuration consists of several building blocks organized into pipelines within the service section. The primary components include:

• Receivers: Responsible for ingesting data into the Collector. Common examples include otlp, jaeger, prometheus, and filelog.
• Processors: Modify, filter, sample, or batch data before it is exported. Examples include batch, memory_limiter, attributes, and tail_sampling.
• Exporters: Send processed data to external backends or monitoring systems. Examples include otlp, otlphttp, jaeger, prometheus, and logging.
• Extensions: Provide auxiliary capabilities such as health checking, profiling, and internal storage without touching the telemetry data stream. Examples include health_check, pprof, zpages, and file_storage.
• Connectors: Bridge two pipelines by acting as both an exporter and a receiver, such as converting traces into metrics using components like spanmetrics or servicegraph.
• Service: Defines the enabled extensions and activates specific data pipelines, binding together the chosen receivers, processors, and exporters.

A typical pipeline combines receivers, processors, and exporters tailored separately for traces, metrics, and logs.

Configuration Example

Below is a standard Collector configuration that accepts OTLP data, applies memory protection and batching, and exports the payload to a remote OTLP endpoint while also printing to the local logs:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  batch:
    timeout: 1s
    send_batch_size: 1024

exporters:
  otlp:
    endpoint: "otel-collector.example.com:4317"
    tls:
      insecure: false
  logging:
    verbosity: detailed

extensions:
  health_check:
  pprof:
  zpages:

service:
  extensions: [health_check, pprof, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp, logging]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp]

In this setup, the memory_limiter processor should always sit at the very beginning of the processor chain to prevent out-of-memory crashes, while the batch processor optimizes network utilization by grouping payloads together. The health_check extension exposes an availability endpoint, and zpages provides a real-time debugging interface.

Deployment Modes

The Collector is commonly deployed in two primary patterns:

1. Agent Mode
   A Collector instance runs on every host node or alongside application pods as a sidecar. Applications route their telemetry to the local agent, which handles lightweight enrichment (such as adding host metadata) and batching before forwarding the data. This approach minimizes network hops, isolates applications from backend topologies, and attaches contextual infrastructure metadata.

2. Gateway Mode
   A centralized cluster of Collector instances aggregates data streams from multiple agents or applications. The gateway layer handles resource-intensive tasks such as tail-based sampling, data sanitization, and multi-backend routing. It also helps manage outbound connections to backends and centralizes authentication and rate limiting.

Organizations frequently combine both patterns: using Agents for local collection and lightweight processing, and Gateways for heavy lifting and routing.

Best Practices

• Always configure memory_limiter: Protect your Collector from crashing under heavy memory pressure.
• Tune batch parameters carefully: Adjust timeout and send_batch_size based on throughput volume and backend capacity.
• Enable health checks and self-monitoring: Use the health_check extension alongside internal Collector metrics to monitor pipeline vitality.
• Leverage tail sampling to control volume: Implement tail_sampling at the gateway layer to retain only anomalous, error-prone, or slow traces.
• Utilize connectors to generate metrics: Components like spanmetrics can derive request rates and error percentages directly from trace data.
• Build custom distributions when necessary: Use the OpenTelemetry Collector Builder (OCB) to compile only the specific components required, reducing binary size and attack surfaces.

The OpenTelemetry Collector acts as the central nervous system for modern observability architectures. By mastering its receivers, processors, exporters, and pipeline design, engineering teams can flexibly ingest, transform, and route telemetry data to fit any production environment.