The OpenTelemetry Collector is the central component of modern observability pipelines, receiving, processing, and exporting traces, metrics, and logs. Understanding the receiver-processor-exporter pipeline model, OTLP, and advanced features like tail sampling is essential for platform engineers.
0 / 5 completed
1 / 5
In the OpenTelemetry Collector, what is the role of a Receiver?
A Receiver is the entry point for data into the Collector. It listens for telemetry from clients using protocols like OTLP, Jaeger, Prometheus, or Zipkin, and converts the received data into the Collector's internal pdata format for processing and export.
2 / 5
What does the batch processor in an OpenTelemetry Collector pipeline do?
The batch processor buffers incoming telemetry until a configurable size or timeout is reached, then flushes to the exporter. This significantly reduces the number of outbound connections and requests, improving throughput and reducing per-request overhead on the telemetry backend.
3 / 5
What is tail sampling in the context of the OpenTelemetry Collector, and why is it more powerful than head-based sampling?
Tail sampling collects all spans of a trace first, then applies policies (e.g., always keep traces with errors, sample 1% of fast successful traces) before exporting. Head-based sampling decides at the first span, before knowing the outcome, so it cannot selectively keep interesting traces.
4 / 5
In an OTel Collector config, a pipeline is defined as traces: receivers: [otlp] processors: [batch] exporters: [jaeger, otlp/cloud]. How many copies of each trace does the Collector export?
When a pipeline lists multiple exporters, the Collector fans out the data to all of them. Each exporter receives an independent copy of the processed telemetry, enabling simultaneous export to on-prem (Jaeger) and cloud backends from a single Collector.
5 / 5
What is the OTLP (OpenTelemetry Protocol) and what transport options does it support?
OTLP is the native wire protocol of the OpenTelemetry ecosystem. It transports traces, metrics, and logs using Protobuf-defined schemas over gRPC (port 4317) or HTTP (port 4318, supporting both JSON and binary Protobuf). It is the default export format for all OTel SDKs.