Getting Started with the OpenTelemetry Collector

OpenTelemetry Collector is a high-performance, scalable, and reliable data collection pipeline for observability data. It receives telemetry data from various sources, performs processing and translation to a common format, and then exports the data to various backends for storage and analysis.

The OpenTelemetry Collector supports multiple data formats, protocols, and platforms, making it a flexible and scalable solution for observability needs. You can also watch this introduction on YouTube.

How does OpenTelemetry Collector work?

OpenTelemetry Collector serves as a vendor-agnostic proxy between your applications and distributed tracing tools such as Uptrace or Jaeger.

The OpenTelemetry Collector operates through three main stages:

Receiving - Collecting data from various sources
Processing - Normalizing and transforming the data
Exporting - Sending processed data to different backends for storage and analysis

The OpenTelemetry Collector provides powerful data processing capabilities, including aggregation, filtering, sampling, and enrichment of telemetry data. You can transform and reshape the data to fit your specific monitoring and analysis requirements before sending it to backend systems.

The OpenTelemetry Collector is written in Go and licensed under Apache 2.0, which allows you to modify the source code and install custom extensions. However, this flexibility comes with the responsibility of maintaining your own OpenTelemetry Collector instances.

When to use OpenTelemetry Collector

While sending telemetry data directly to a backend is often sufficient, deploying OpenTelemetry Collector alongside your services offers several advantages:

Efficient batching and retries - Optimizes data transmission and handles failures gracefully
Sensitive data filtering - Removes or masks sensitive information before export
Whole-trace operations - Essential for tail-based sampling
Agent-like functionality - Pulls telemetry data from sources (e.g., OpenTelemetry Redis or host metrics)

otelcol vs otelcol-contrib

OpenTelemetry Collector has two repositories on GitHub:

opentelemetry-collector - The core repository containing only the most essential components. It is distributed as the otelcol binary.
opentelemetry-collector-contrib - Contains the core plus all additional available components, such as Redis and PostgreSQL receivers. It is distributed as the otelcol-contrib binary.

Recommendation: Always install and use otelcol-contrib, as it is as stable as the core and supports more features.

Installation

OpenTelemetry Collector provides pre-compiled binaries for Linux, macOS, and Windows.

Linux

To install the otelcol-contrib binary with the associated systemd service, run the following command replacing amd64 with the desired architecture:

shell Debian

wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.159.0/otelcol-contrib_0.159.0_linux_amd64.deb
sudo dpkg -i otelcol-contrib_0.159.0_linux_amd64.deb

Check the status of the installed service:

shell

sudo systemctl status otelcol-contrib

View the logs:

shell

sudo journalctl -u otelcol-contrib -f

Edit the configuration file at /etc/otelcol-contrib/config.yaml and restart the OpenTelemetry Collector:

shell

sudo systemctl restart otelcol-contrib

Compiling from source

You can also compile OpenTelemetry Collector locally:

shell

git clone https://github.com/open-telemetry/opentelemetry-collector-contrib.git
cd opentelemetry-collector-contrib
make install-tools
make otelcontribcol
./bin/otelcontribcol_linux_amd64 --config ./examples/local/otel-config.yaml

A configuration that works

The Collector does nothing until a pipeline is defined. This is the smallest configuration that receives OTLP and forwards it to a backend:

yaml

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

exporters:
  otlp/uptrace:
    endpoint: api.uptrace.dev:4317
    headers:
      uptrace-dsn: 'https://<secret>@api.uptrace.dev?grpc=4317'

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/uptrace]

The default configuration file lives at /etc/otelcol-contrib/config.yaml.

A component that is defined but not listed in service.pipelines is silently ignored. This is the most common reason a Collector starts cleanly and forwards nothing — see troubleshooting for the rest of the silent failure modes.

Check the configuration before restarting:

shell

otelcol-contrib validate --config /etc/otelcol-contrib/config.yaml

Three processors are worth adding to almost any production pipeline:

batch — groups telemetry before export. Always include it.
memory_limiter — drops data instead of letting the Collector be OOM-killed. Place it first in the pipeline, before batch.
resourcedetection — fills in host, cloud, and container attributes so you do not have to set them per service.

See Collector configuration for the full syntax, and exporters for backend-specific options.

Where to go next

Task	Page
Write and structure the configuration file	Collector configuration
Send data to a specific backend	Collector exporters
Collect CPU, memory, disk, and network from hosts	Host metrics receiver
Scrape Prometheus endpoints or write to Prometheus	Prometheus integration
Collect logs from files, syslog, or Kubernetes	OpenTelemetry logs
Run the Collector in Kubernetes	OpenTelemetry Operator
Sample traces across a whole trace	Tail-based sampling

What's next?

OpenTelemetry architecture — where the Collector sits in the pipeline
Data ingestion methods — alternatives to the Collector for specific sources
Get started with OpenTelemetry — instrument an application first
OpenTelemetry APM — where the Collector sends data