OpenTelemetry Collector distributions compared: Core, Contrib, OCB, and vendor builds. Which one should you use?

If someone has told you to “use the OpenTelemetry Collector,” you may have noticed there is no single thing to download. There’s a lean default build. There’s a much larger repository of hundreds of community-contributed components. There’s a builder tool that lets you assemble your own binary. And there’s a growing set of vendor distributions, each pre-packaged and ready to install.

This is by design. The OpenTelemetry project chose this structure deliberately, and once you understand why, the landscape makes considerably more sense. In this blog, we walk through each option, the trade-offs it brings, and how to reach a decision you will not regret six months from now.

What is the OpenTelemetry Collector?

Think of the OpenTelemetry Collector as a small program that sits between your applications and your observability backends. It is the translation and routing layer that keeps your instrumentation code independent of whatever platform you use to store and analyze telemetry.

Internally, every Collector runs the same five-component model:

• Receivers pull or accept telemetry from a source. Examples include an application pushing OTLP, a Prometheus endpoint to scrape, or a Kafka topic to consume.
• Processors transform data as it passes through. Typical examples include batching, filtering, redacting sensitive attributes, and enriching spans with resource metadata.
• Exporters send the result to one or more backends, such as a vendor platform, an object store, or another Collector.
• Connectors join two pipelines, acting as an exporter for one and a receiver for the next. For example, the spanmetrics connector turns trace spans into request, error, and duration metrics, and a routing connector sends data down different pipelines based on its attributes.
• Extensions add cross-cutting capabilities outside the pipeline, such as health checks, profiling endpoints, and zpages for real-time debugging.

You wire these together in a YAML service section to declare named pipelines for traces, metrics, and logs. The power is in what the separation creates: your instrumentation code does not need to know where your telemetry is going.

If your instrumentation code knows about your vendor, you have lost the main benefit of the OpenTelemetry standard. The Collector is what keeps that promise.

Why isn’t there a single Collector?

The Collector is open source, but you do not ship the source repository. You ship a build of it, a compiled binary or container image that includes a specific set of components. Different builds include different components, and the build you choose is your distribution.

This is the part most teams miss. When someone says “we use the OTel Collector,” they are implicitly choosing a distribution. That choice determines which receivers and exporters are available, how stable they are, what the upgrade path looks like, and how much of the pipeline your team owns and maintains. It’s a foundational decision, not a minor implementation detail.

This blog focuses on the four options most teams encounter: Core (the otelcol binary), Contrib (otelcol-contrib), a custom build via OCB, and a vendor distribution.

The OpenTelemetry project also maintains three additional purpose-built distributions: otelcol-k8s, a Kubernetes-focused build that includes only vendor-neutral, Kubernetes-relevant components; otelcol-otlp, a minimal build restricted to OTLP receivers and exporters; and otelcol-ebpf-profiler, a specialist distribution for continuous profiling via eBPF. All three are scoped distributions built using the same OCB pattern covered here, rather than a separate category of choice.

Core: the conservative foundation

Core (released as otelcol) is the lean, intentionally minimal build maintained by the OpenTelemetry project. It ships the essentials: OTLP receivers and exporters, a debug exporter, the batch and memory_limiter processors, and a small set of extensions such as health_check, pprof, and zpages. That restraint is the point.

Core is intentionally minimal. Confirm the current component maturity and release notes for the version you deploy, especially if your pipeline depends on a specific signal or component. If your telemetry sources already speak OTLP and your topology is simple, Core can be a good starting point because a smaller default component set can make the pipeline easier to reason about.

Contrib: the full component library

Contrib (released as otelcol-contrib) is where the OpenTelemetry ecosystem lives. It includes hundreds of components contributed by the community and vendors, such as Prometheus, Kafka, Jaeger, AWS, Azure, GCP, MongoDB, MySQL, and many more. If you need to receive from or export to a specific system, Contrib almost certainly has a component for it.

The trade-off is stability. Each component carries its own maturity label (development, alpha, beta, or stable), and the label can vary by signal type (logs, metrics, or traces). A receiver may be stable for metrics but alpha for logs. Some capabilities sit behind feature flags that require explicit opt-in.

Contrib is useful for exploring what’s possible. Before using Contrib in production, review the maturity and support status of each included component, remove components you do not need, and test the selected build in your environment.

Build your own with the Collector Builder

Once you know which Contrib components you actually need, the OpenTelemetry Collector Builder (OCB) lets you assemble a custom distribution containing exactly those components. You describe the build in a manifest.yaml file, run OCB, and out comes a binary or container image you control entirely.

A custom build can reduce the number of included components and dependencies. Depending on implementation, that may simplify inventory and review. Validate security, startup performance, compliance controls, and upgrade behavior in your environment.

OCB is the standard answer when an organization is mature enough to know its component list and wants tight operational control over what it ships.

With the manifest in place, the build itself is a two-step process. Install OCB with go install go.opentelemetry.io/collector/cmd/builder@v0.120.0, then point it at your manifest: ocb --config otelcol-builder.yaml. OCB fetches only the modules you declared, compiles them together, and writes a single ready-to-run binary to the output_path you specified. Examples are illustrative; verify component names, maturity, and versions against current OpenTelemetry documentation before use. The OCB source and releases live on github. When you need to hunt for additional receivers, processors, or exporters to add to your manifest, the full component registry is on github.

Vendor distributions: curated packaging and support options

Vendor distributions are pre-assembled builds. Depending on the vendor and offering, they may include support, signed artifacts, compatibility testing, or documented upgrade guidance. Verify the specific distribution’s terms and practices before you depend on it.

Vendor distributions may be the path of least resistance, reducing some packaging and maintenance work by providing a curated build and support model. Evaluate the vendor’s included components, release practices, and support terms against your requirements.

Before committing, check the vendor’s published component manifest against your actual pipeline needs. Vendor distributions are built on OCB and include a curated subset of Contrib, not all of it. If your pipeline depends on a component that didn’t make the vendor’s cut, you will discover that gap at configuration time, not at evaluation time. A Kafka receiver or exporter is a common example: it is present in Contrib, but not every vendor distribution includes it. Review the manifest, map it to your receivers and exporters, and raise any gaps with the vendor before you build a dependency on their distribution.

How do I pick an OpenTelemetry distribution?

A practical way to choose is to start broad during evaluation, then narrow as your requirements become clearer. Contrib can help you understand which receivers, processors, and exporters you need. Once your component list stabilizes in a non-production environment, decide how much build, release, and support responsibility your team wants to own.

If your organization has the engineering capacity to own a build pipeline and wants precise control over every component version, OCB may be the right next step. If you prefer a curated distribution with a vendor support model, evaluate whether the vendor’s component selection, release practices, and support terms fit your requirements.

A few habits will serve you well regardless of which path you choose:

• Pin component versions.
• Stage upgrades the way you would stage any other infrastructure change.
• Track the maturity labels of components you depend on.
• Do not enable components you do not use, because every component in your binary is one you implicitly maintain.

What comes next?

Choosing a distribution solves the first problem. At scale, teams may need processes or additional tooling for coordinated upgrades, configuration distribution, health monitoring, and fleet visibility. Requirements vary by deployment model and the management capabilities already in use.

That is the subject of the next blog in this series: managing OTel Collectors at scale.