Choosing the right OpenTelemetry Collector distribution

The OpenTelemetry (OTel) Collector plays a central role in collecting, processing, and exporting telemetry data. If you’re deploying the Collector in production, chances are you’ve reached for the otelcol-contrib distribution. It’s the easiest, most flexible, and most documented distribution, used in nearly every demo and getting-started guide.

But here’s the catch: It’s not actually recommended for production use.

So what should you use instead? Should you choose one of the leaner official distributions, pick a vendor-maintained distro, or build your own from scratch? In this post, we’ll explore the different OpenTelemetry Collector distributions (also known as distros), how they differ, and how to decide which one best fits your environment.

What distributions are available?

The OpenTelemetry community currently maintains five official distributions, each released every two weeks:

• OpenTelemetry Collector, or otelcol
• OpenTelemetry Collector Contrib, or otelcol-contrib
• OpenTelemetry Collector for Kubernetes, or otelcol-k8s
• OpenTelemetry Collector OTLP, or otelcol-otlp
• OpenTelemetry Collector eBPF Profiler, or otelcol-ebpf-profiler

Each distribution includes a curated set of components maintained by the OpenTelemetry community. The otelcol-contrib distribution includes all components from both the core and contrib repositories, including both open source and third party. This makes it a popular choice for demos, experimentation, and official documentation, such as the OpenTelemetry Demo and the Collector installation guide.

In fact, in May 2025 we analyzed OpenTelemetry Collector usage from over 1,000 organizations that send telemetry data to Datadog. Almost nine out of 10 organizations were using the otelcol-contrib distribution in their infrastructure.

Close dialog

However, as we mentioned, using the otelcol-contrib distro in production is not recommended. According to the official repository page, while otelcol-contrib is a good starting point, for production purposes “it is recommended to limit the collector to contain only the components necessary for an environment.” Reasons for this include reducing the size, deployment times, and available attack surface area of the Collector for faster updates and improved security.

So, what are your options?

If otelcol-contrib is too broad for your production needs, there are three common paths you can take:

• Use a leaner open source software (OSS) distribution
• Choose a vendor-maintained distribution
• Build your own Collector with only the components you need

Let’s take a realistic scenario as an example to explore when and how you might choose one of these options. You’re running an application in Kubernetes on a specific cloud provider, and your architecture is composed of several microservices and Kafka brokers that are all instrumented with OpenTelemetry—with Datadog as your observability backend.

Your Collector setup should be able to:

• Receive telemetry data from your instrumented services
• Scrape Kafka and Kubernetes metrics
• Enrich telemetry with Kubernetes metadata
• Export everything to Datadog

With this scenario in mind, let’s explore the pros and cons of each distribution type and how to decide which one is right for you.

Exploring OSS distributions

Beyond otelcol-contrib, the OpenTelemetry community maintains four additional Collector distributions. Each is designed with a specific use case in mind and includes a minimal set of components to reduce overhead and complexity.

Let’s take a closer look at each:

otelcol: The core Collector

The otelcol distribution includes all components from the core OpenTelemetry Collector repository, along with a limited selection of vendor-neutral components from the contrib repository. It’s intentionally lightweight and doesn’t include any Kubernetes-specific components, even though those are open source. Since our use case involves Kubernetes and cloud-specific integrations, this distribution wouldn’t meet our needs.

otelcol-k8s: Optimized for Kubernetes

At first glance, otelcol-k8s seems like a good candidate for our Kubernetes-based deployment. However, it includes only vendor-neutral components, meaning there’s no support for cloud provider-specific integrations or Kafka. This rules it out for our scenario as well.

otelcol-otlp: OTLP-focused Collector

The otelcol-otlp distribution is purpose-built to receive and export telemetry data via the OpenTelemetry Protocol (OTLP), supporting both gRPC and HTTP transports. It contains only OTLP receivers and exporters—no processors, no additional components. While it’s ideal for simple OTLP pipelines or edge deployments, it doesn’t provide the flexibility we need.

otelcol-ebpf-profiler: For eBPF profiling

The otelcol-ebpf-profiler includes the eBPF profiler receiver and a minimal set of components from both the core and contrib repositories. However, like otelcol-k8s, it omits cloud provider and vendor-specific components. As a result, it also falls short for our scenario, where Kafka and cloud-specific integrations are required.

Thinking back to our Kubernetes cluster example, none of the OSS distros provide the full set of components we need. That brings us to the next available option: vendor distributions.

Exploring vendor distributions

OpenTelemetry is a vendor-neutral project, collaboratively maintained by contributors from many companies and the broader community. Some vendors choose to offer their own distribution of the OpenTelemetry Collector, often including a curated set of components that integrate well with their backend. Many of these vendor-maintained distributions are listed on the official OpenTelemetry Collector distributions page.

Choosing a vendor distribution can be a good fit depending on your use case. For example, some vendors offer production-grade support for their distribution and ensure that the included components are secure, stable, and compatible with their telemetry pipelines.

However, in most cases, vendor distributions don’t allow fine-grained control over which components are included. You get the full set as provided by the vendor—no more, no less. This can result in deploying components that aren’t necessary for your environment, which brings you back to the same production concerns mentioned earlier, albeit with vendor support in place.

To illustrate, let’s look at the AWS Distro for OpenTelemetry (ADOT). It includes many community-maintained components along with AWS-specific ones such as the ECS Container Metrics Receiver, X-Ray Exporter, and others. If you’re running in AWS, ADOT could be a solid choice. But even then, it includes components you might never use, such as receivers for Jaeger or Zipkin. And if you’re operating in a different environment (e.g., Azure or on-prem), deploying AWS-specific components offers no benefit.

This same logic applies across all vendor distributions. The Datadog Distribution of the OpenTelemetry Collector (DDOT) supports custom components, offering more flexibility than most alternatives while still requiring some components that you may not need.

Vendor-managed distributions are often optimized for ease of use and quick integration with specific backends, making them a fast and reliable choice for many teams. But if you're operating in a highly customized environment or looking for full control over which components are included in your Collector, you may want to consider a more tailored approach.

In that case, let’s explore a third option: building your own Collector distribution.

Build your own Collector

To give users more control over what components are included in their Collector, the OpenTelemetry project offers a tool called the OpenTelemetry Collector builder (OCB). As the name suggests, this tool lets you build a custom distribution of the Collector by specifying exactly which components you want to include.

Sounds ideal, right?

Let’s look at an example manifest file used by the OCB:

1
dist:
2
  module: github.com/example/dist/my-opentelemetry-collector
3
  name: otelcol
4
  description: Custom OpenTelemetry Collector
5
  version: 0.126.0
6
  output_path: ./_build
7

8
receivers:
9
  - gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.126.0
10

11
exporters:
12
  - gomod: go.opentelemetry.io/collector/exporter/debugexporter v0.126.0
13
  - gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.126.0
14
  - gomod: go.opentelemetry.io/collector/exporter/otlphttpexporter v0.126.0
15

16
processors:
17
  - gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.126.0
18
  - gomod: go.opentelemetry.io/collector/processor/memorylimiterprocessor v0.126.0
19
  - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/processor/resourcedetectionprocessor v0.126.0
20
  - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/processor/resourceprocessor v0.126.0
21

22
providers:
23
  - gomod: go.opentelemetry.io/collector/confmap/provider/yamlprovider v1.32.0

To build your custom Collector, you’ll need to identify and specify the correct gomod paths and versions for each component. While all the latest components are compatible with each other, you still need to manually declare each one and ensure they all align with the same Collector API version. So even though compatibility isn’t typically an issue, it’s not just a matter of copy-paste. A custom Collector requires deliberate version management and ongoing maintenance.

The OpenTelemetry Registry helps with this by providing a search engine for finding the gomod for each necessary component. However, keeping everything in sync becomes your responsibility. You’re now maintaining an additional manifest file, tracking versions, and rebuilding the binary every time a new release comes out.

It’s true that you'll need to update your Collector regularly anyway, but using the OCB can turn what would typically be a simple image tag update into a full custom build process. With the Collector on a two-week release cadence, this can quickly become a significant maintenance burden.

In fact, keeping the Collector up to date is already a challenge for many organizations. From the usage data we analyzed in May 2025, nearly half of Collectors deployed are 20 or more versions behind the latest version.

Close dialog

This data, coupled with the fact that almost nine out of 10 organizations use the otelcol-contrib distro, highlights a clear trend: While the community acknowledges that otelcol-contrib isn’t ideal for production, many users default to it because it’s the most convenient option.

In discussions with the OpenTelemetry community, it became clear that the OCB is just an initial step toward a more comprehensive solution. There’s recognition that the tool still has room to mature. One promising direction would be a build system that takes a standard Collector configuration file and automatically generates a distribution with only the necessary components; this would eliminate the need for a separate manifest entirely. The ocbConfig app is a step in that direction, but much still needs to be done to make this the default choice for users.

Some community members have expressed concern that this approach might limit the ability to include custom components. However, based on the data above, such a solution could still address the needs of the vast majority of users, potentially simplifying the experience for up to 90% of real-world deployments.

If this resonates with you, we encourage you to join the conversation or contribute to the OCB to help shape the future of the OpenTelemetry Collector. Even small contributions, like feedback or use cases, can help drive the project forward.

Find the right distribution for your architecture

Choosing the right Collector distribution is more nuanced than it may first appear, and that’s why it’s so important to understand the alternatives to popular choices like otelcol-contrib. While this OSS distro is widely used, it is not designed for production and it is likely worth your time to explore alternatives.

To bring it back to the original question: What should you use instead? As with most things in tech, the answer depends on your specific architecture and use cases.

Consider your system requirements, weigh your architectural constraints, and evaluate what your vendors offer. While OSS and third-party distributions may give you all the tools you need for your organization, the OCB provides the most customization options to help you build a distribution to fit any architecture. Though by collecting and analyzing data on Collector use, it’s clear that the community still needs a simpler, config-driven way to manage these custom builds.

With the context and comparisons we’ve explored, you’re now better equipped to make an informed decision. For an in-depth breakdown on setting up OpenTelemetry with Datadog, check out our Learning Center course. Or, if you’re new to Datadog and want to test out distributions on your own, get started with a 14-day free trial.