Configuring the OpenTelemetry Collector: OTCA practice questions

A Collector configuration is a YAML document built from a few top-level sections. Receivers, processors, exporters and connectors are the pipeline components that touch telemetry, while extensions add capabilities such as health checks or authentication without handling the data itself. Defining a component in its section only describes it. Nothing runs until the service section references it, either inside a pipeline or in the service extensions list, so a component that is configured but never referenced is simply not enabled.

Every component is named with an identifier of the form type[/name]. The type selects the implementation, for example otlp or batch, and the optional name lets you declare several instances of one type, such as otlp and otlp/2 listening on different ports. Pipelines use the same pattern, so traces and traces/2 can coexist. Identifiers only have to be unique; the type before the slash is what decides behaviour.

The Collector reads its configuration through providers. The --config flag accepts a plain path or a URI with a scheme, and the documented schemes are file, env, yaml, http and https. You can repeat --config to pass several sources, and they are merged into one in-memory configuration. Each source may be partial and may reference components defined in another, but the merged result must be complete, because the Collector does not add missing components for you. Values passed with --set are applied after all --config sources are merged, and nested keys in --set and yaml: values are separated with two colons.

Inside the YAML, environment variables are expanded with the ${env:NAME} syntax, and a fallback can be given with ${env:NAME:-default}. A doubled dollar sign produces a literal dollar sign. A provider can also be embedded in a value, so a line like exporters: ${file:exporters.yaml} pulls that file into the merged configuration.

Network-facing components default to binding localhost, which has been the default host since Collector v0.110.0. The OTLP receiver therefore listens on localhost:4317 for gRPC and localhost:4318 for HTTP unless you set an endpoint. In containers and Kubernetes this is a frequent reason why other workloads cannot connect, and the security guidance recommends binding to a specific interface such as the pod IP rather than 0.0.0.0.

Which components exist depends on the distribution. The project publishes core, contrib, Kubernetes, OTLP-only and eBPF profiling distributions, and the contrib README advises limiting production builds to the components you need. The OpenTelemetry Collector Builder, ocb, compiles such a custom distribution with Go from a YAML manifest that has a dist section plus lists of component Go modules.