Skip to main content
This guide demonstrates how to configure an OpenTelemetry Collector using a single YAML file. It covers the top-level sections, a minimal working example, how to validate the configuration, running the Collector (Docker example), generating test telemetry with telemetrygen, and suggestions for extending the configuration for production. Core Collector configuration sections (in order):
  • receivers: how the Collector accepts telemetry (from applications, agents, or other collectors)
  • processors: optional transformers, batching, filtering, sampling, etc.
  • exporters: destinations for processed telemetry (backends, files, console)
  • service.pipelines: wiring that connects receivers → (processors) → exporters for each signal (traces, metrics, logs)
Summary table of the top-level sections:
SectionPurposeExample snippet
receiversDefines how telemetry is ingested (OTLP, Jaeger, Prometheus, Fluent Forward, etc.)yaml\nreceivers:\n otlp:\n protocols:\n grpc: {}\n
processorsOptional processing (batching, sampling, resource enrichment)yaml\nprocessors:\n batch: {}\n
exportersWhere telemetry is sent (OTLP, Prometheus, Jaeger, logging/debug)yaml\nexporters:\n otlp:\n endpoint: example:4317\n
service.pipelinesConnects receivers → processors → exporters per signalyaml\nservice:\n pipelines:\n traces: { receivers: [otlp], exporters: [debug] }\n

​
Minimal configuration skeleton

A minimal skeleton to remind the top-level layout:
Validate a Collector config with the built-in validator:
Note: Use the correct binary for your distribution (for example otelcol or otelcol-contrib).
If validation fails, carefully check YAML indentation and keys—most issues are typos or mis-indentation. You can also run otelcol --config customconfig.yaml --dry-run with some builds to surface runtime validation errors.

​
Receivers

Receivers determine how the Collector accepts telemetry. The Collector supports many receiver types (examples: Fluent Forward, Prometheus, Jaeger, Kafka, OpenCensus, OTLP, Zipkin). Below are example snippets for several common receivers. Example receiver snippets:
OTLP receiver (recommended for examples & local testing — supports gRPC and HTTP):
Notes:
  • 0.0.0.0 binds to all interfaces. For local-only testing, use 127.0.0.1 or a specific interface.
  • Add TLS (cert/key) or authentication under each protocol if required.

​
Processors

Processors run between receivers and exporters and can transform, filter, aggregate, or limit telemetry. Common processors: batch, memory_limiter, attributes, resource, probabilistic_sampler. Processors are optional—omit them for minimal configs. Example placeholder:

​
Exporters

Exporters send processed telemetry to destinations. Typical exporters include OTLP, Prometheus, Jaeger, Zipkin, Kafka, file, cloud vendor backends, and a debug exporter that prints telemetry to stdout. Example exporter snippets:
Note: Historically some distributions used logging instead of debug—check the Collector version and distribution.

​
Wiring it together: service.pipelines

Pipelines connect receivers to processors and exporters. You must define a pipeline for each signal you want to process (traces, metrics, logs). Each pipeline lists receivers, optionally processors, and exporters. Minimal complete config (receives OTLP gRPC + HTTP; exports all signals to debug):
With this configuration the Collector accepts traces, metrics, and logs via OTLP and prints them to the console for inspection.

​
Running the Collector (Docker example)

You can run the Collector as a binary, Docker image, Docker Compose service, or inside Kubernetes. Example using the contrib Docker image (includes many receivers/exporters):
When OTLP is configured you should see logs indicating the gRPC and HTTP OTLP servers started and that the service is ready. Example (trimmed):
Be mindful of which image you use: otel/opentelemetry-collector (core) includes fewer components than otel/opentelemetry-collector-contrib. Choose the image that contains the receivers/exporters you need. Binding ports to 127.0.0.1 restricts access to localhost; remove 127.0.0.1: to expose to all interfaces.

​
Generating test telemetry with telemetrygen

Use telemetrygen to generate test traces, metrics, and logs to validate the Collector without instrumenting an application. Install telemetrygen (Go required):
Generate traces (OTLP via HTTP, insecure—suitable for local testing):
Expected telemetrygen output (informational):
Collector debug exporter will print received spans like:
Generate logs:
Collector debug output for logs:
If you see the spans and log records printed, the pipelines are functioning and the Collector is receiving and exporting telemetry correctly.

​
Common receivers and exporters (quick reference)

CategoryExamplesWhen to use
Receiversotlp, prometheus, jaeger, fluentforward, kafkaUse based on the telemetry source (instrumentation, agent, or external pipeline)
Exportersotlp, prometheus, jaeger, zipkin, kafka, debugSend telemetry to vendor ingest, monitoring systems, or stdout for testing

​
Extending this configuration

  • Replace the debug exporter with a production backend exporter (e.g., OTLP to vendor ingest, Prometheus remote write, Jaeger, Zipkin, Kafka).
  • Add processors like batch, memory_limiter, resource, or attributes to shape telemetry.
  • Add multiple receivers and create pipelines that route different signals to different exporters.
  • For production, enable TLS/authentication for receivers and exporters, and tune processor parameters (e.g., batch sizes, sampling rate).

​
Final full example (copy/paste)

This concludes the basic OpenTelemetry Collector configuration guide: receivers, processors, exporters, wiring, validation, and local testing using the debug exporter and telemetrygen.

Watch Video

Practice Lab