The OpenTelemetry Collector: OTCA practice questions

The OpenTelemetry Collector is a vendor-agnostic service that receives, processes and exports telemetry. It supports open source formats such as Jaeger, Prometheus and Fluent Bit and can send to one or more open source or commercial backends. Its value is operational: applications can hand data off quickly while the Collector handles retries, batching, encryption and filtering of sensitive data, and one Collector can replace several agents. For getting started or a small development setup, exporting directly from the SDK to a backend is often enough.

The Collector is configured in YAML, and components come in a few kinds. Receivers get data into the Collector. Processors modify data in flight; the documentation's examples include memory_limiter, attributes, resource, filter, span and probabilistic_sampler. Exporters send data on, for example over OTLP, to Kafka, a file, Prometheus or Zipkin, or to the debug exporter for troubleshooting. Connectors join two pipelines and act as an exporter for one and a receiver for the other. Extensions add capabilities that do not touch telemetry, such as health_check, pprof and zpages, and none are configured by default.

A component can be given more than one configuration with the type/name syntax, for example otlp and otlp/2, and pipelines use the same syntax. The most important rule is that configuring a component does not enable it. Components take effect only when the service section lists them: extensions under service.extensions, and receivers, processors and exporters inside pipelines. Pipelines are defined per signal, traces, metrics or logs, and processors run in the order they are listed, so order changes the result. The service.telemetry section configures the Collector's own logs and metrics. Values can come from environment variables with ${env:NAME}, with :- for a default.

Deployment follows a few patterns, all using the same binary. With no Collector, applications send straight to backends. In the agent pattern, a Collector runs alongside the application or on the same host, as a sidecar or a DaemonSet, and SDKs export to it; it is straightforward to start with and maps each application to its Collector, but it is inflexible for complex or growing setups. In the gateway pattern, one or more standalone Collectors per cluster, data center or region receive from many sources through a single OTLP endpoint, usually behind a load balancer. That centralizes credentials and policies such as filtering and sampling, at the cost of another component that can fail, extra latency and more resources. The agent-to-gateway pattern combines both.

Some processing needs related data on the same instance. Tail sampling must see all spans of a trace, so a first tier of Collectors uses the load-balancing exporter to route by trace ID to a second tier, and routing by service name serves the span metrics connector. With several gateways, each metric stream still needs a single writer, which is why the documentation recommends identifying sources with the Kubernetes attributes and resource detection processors.

Each component documents its own stability level, and the Collector's overall status is mixed because those levels differ. The OpenTelemetry Operator manages Collectors on Kubernetes.