OTel Collector

Receivers are how data gets into the Collector. They listen for data in various formats and protocols, acting as the ingestion endpoint. The Collector supports two primary types:

• Push Receivers: Accept data sent to them (e.g., OTLP, Jaeger, Zipkin).
• Pull Receivers: Actively scrape data from sources (e.g., Prometheus, host metrics).

A single Collector can run multiple receivers simultaneously, allowing it to consolidate data from diverse sources like applications, infrastructure, and legacy systems into a single pipeline.

Processors are run on data between reception and export. They perform actions like filtering, transformation, and enrichment within a pipeline. Common processors include:

• Batch: Groups signals to improve compression and reduce transmission overhead.
• Attributes Processor: Adds, modifies, or deletes attributes (tags) on spans, metrics, or logs.
• Filter Processor: Drops telemetry based on conditions, enabling cost control via sampling at the collector level.
• Memory Limiter: Prevents the Collector from exhausting memory by dropping data when limits are approached.

Processors are executed in the order they are defined in a pipeline's configuration.

Exporters are the exit points of the pipeline. They define where the processed telemetry data is sent. Exporters serialize the data into the format required by a specific backend. Examples include:

• OTLP Exporter: Sends data to any backend supporting the OpenTelemetry Protocol.
• Vendor-Specific Exporters: For platforms like Datadog, Splunk, New Relic, or Dynatrace.
• Logging Exporter: A debug exporter that writes data to the Collector's stdout.

A pipeline can have multiple exporters, enabling fan-out routing of the same data to multiple monitoring, analytics, and archival systems simultaneously.

Pipelines are the configuration construct that binds receivers, processors, and exporters together for a specific telemetry type. A pipeline defines a unidirectional data flow. The OTel Collector supports three pipeline types:

• Traces Pipeline: For processing distributed trace data.
• Metrics Pipeline: For processing numeric metric data.
• Logs Pipeline: For processing log records.

Each pipeline type is independent, allowing for different processing logic and routing destinations for traces versus metrics versus logs. A single Collector instance typically runs multiple pipelines.

The service section in the Collector's configuration glues all components together. It defines which pipelines are executed and what extensions are active.

Extensions are optional components that provide ancillary functionality not directly related to data processing pipelines:

• Health Check Extension: Provides HTTP endpoints for health monitoring.
• PPROF Extension: Enables runtime profiling for debugging.
• Bearer Token Auth Extension: Manages authentication tokens for exporters.
• zPages Extension: Provides live debugging pages for in-memory data.

The service orchestrates the lifecycle of all these components.

The Collector's design supports flexible deployment to fit different architectural needs:

• Agent Mode: Deployed as a daemon on each host (e.g., via Kubernetes DaemonSet). It receives local telemetry, performs initial processing (like batching), and forwards it to a central collector or backend. This offloads work from the application.
• Gateway Mode: Deployed as a centralized, cluster-level service. It receives data from multiple agents or applications, performs heavier processing (like tail-based sampling), and exports to final backends. This provides a consolidation and control point.

These models are often combined, creating a two-tier architecture (Agents -> Gateway) for scalable, enterprise-grade observability data flow.

A cloud-native deployment model where a helper container (the sidecar) is deployed alongside the main application container in a pod. This pattern is fundamental to deploying collectors.

• How it's used: The OTel Collector is often deployed as a sidecar to an application pod. This provides a dedicated telemetry proxy for that application, isolating concerns and simplifying service discovery.
• Benefits: Allows the application to send telemetry to localhost, the sidecar handles batching, retries, and authentication with backends. Lifecycle is tied to the app.

A Kubernetes workload controller that ensures a copy of a specific Pod runs on all (or some) nodes in a cluster. This is the standard pattern for deploying a cluster-wide collector.

• How it's used: An OTel Collector DaemonSet runs one collector instance per cluster node. All pods on that node can route telemetry to the local daemon.
• Benefits: Resource efficient (one collector per node vs. per pod). Simplifies network-level capture (e.g., host metrics). Often used in conjunction with the sidecar pattern for different layers of aggregation.

An advanced sampling strategy where the decision to keep or discard a complete trace is made after the request has finished. This requires a buffering component like the OTel Collector.

• Mechanism: The Collector's tail sampling processor buffers spans for a trace until it sees the root span is complete. It then evaluates the entire trace against policies (e.g., latency > 5s, error=true).
• Value: Enforces intelligent sampling rules based on actual outcome, ensuring all error traces or slow performance traces are kept, while safely dropping routine, fast traces. This optimizes storage costs without losing signal.