Collector deployment

The Collector comes in different distribution flavors and with different setup and deployment options.

Distributions

OpenTelemetry provides the following two principal distributions of the Collector:

Collector Core
Collector Contrib

Collector Core

The Core distribution contains the basic proxy service and a few fundamental service components:

A receiver for OTLP over HTTP and gRPC
Processors for batching requests and ensuring memory usage constraints
Exporters for console logging and OTLP over HTTP and gRPC

Collector Contrib

The Contrib distribution builds on top of Core and enhances its functionality by shipping with a large number of additional receivers, processors, and exporters, contributed by third parties.

Given that the Contrib distribution is an all-in-one package and comes with all service components pre-compiled, it may use more system resources (storage and memory) than an optimized Collector build. Generally, we recommend using the Contrib distribution for testing purposes and a custom build of the Collector (see Builder) in production.

Collector Builder (ocb)

In addition to the two distributions, OpenTelemetry also offers the Collector Builder, a command line tool that allows you to build your own customized version of the Collector.

The Collector Builder typically is the preferred way to use the Collector, as it allows you to fully customize your Collector instance using only the Collector components you need for your particular use case.

Which Collector should I use?

Type	When whould I use it?
Custom Builder version recommended	For most use cases, as it allows you to fully customize the Collector instance and only run the components required for your use case.
Core	When you primarily want to convert between OTLP protocols (HTTP ↔ gRPC), ensure memory usage constraints, or apply request batching.
Contrib	Ideal for test setups, as it contains all third-party components and doesn't require a custom build. It generally is not recommended for use in production systems, as it typically uses more resources and may be less stable than an optimized Builder instance.

Deployment Modes

The Collector knows about two deployment modes: Agent and Gateway

Agent mode—runs in parallel to the instrumented application and should be used only by that application. In Kubernetes, this may be a sidecar or a DaemonSet.
Gateway mode—runs as central and standalone Collector instance, serving several different applications.

For details, see the OpenTelemetry documentation on deployment.

Deployment Options

The Collector can be deployed either manually, with one of the available install packages, or using container images for Docker and Kubernetes.

Manual deployment

To install a Collector binary manually

Download the latest version for your operating system from GitHub.
Install the application package or decompress the archive file.
Set up the desired configuration.
Start the otelcol binary/service.

Alternatively, you can also build the Collector from its source code.

Docker

To install using a container image for Docker, run the appropriate comamnd for the Core or Contrib distribution type.

CoreContrib

bash
docker pull otel/opentelemetry-collector

bash
docker pull otel/opentelemetry-collector-contrib

More information (for example, Docker Compose) can be found in the Collector documentation.

Kubernetes

For Kubernetes, OpenTelemetry provides different deployment options:

OpenTelemetry Operator

The image used for the Collector has to be configured in the Collector CR.

CoreContrib

yaml
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: otel-col
  namespace: otel-col
spec:
  mode: daemonset
  image: otel/opentelemetry-collector
  config: |
  ...

yaml
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: otel-col
  namespace: otel-col
spec:
  mode: daemonset
  image: otel/opentelemetry-collector-contrib
  config: |
  ...

Contrib is the default used for the Collector by the operator, so this is needed only if you want to use a specific version or tag.

Helm

For Helm, OpenTelemetry provides the following charts, which need to be configured in values.yaml.

CoreContrib

yaml
image:
  repository: otel/opentelemetry-collector

command:
  name: otelcol

yaml
image:
  repository: otel/opentelemetry-collector-contrib

command:
  name: otelcol-contrib

The Helm charts use Contrib by default, so you don't need to add this to your values.yaml. This is shown just for completeness.

Deployment Modes

The Collector can be deployed as a standalone agent, a gateway, or a sidecar.

AgentGatewaySidecar

As an agent, the Collector is deployed either with the application or (recommended) on the same host as the application. This Collector can receive telemetry data and enhance it with, for example, tags or infrastructure information.

As a gateway, one or more Collector instances can be deployed as standalone services. This Collector can be deployed additionally, for example, per cluster, region, or data center. A load balancer can help scale the independently operating Collector instances.

In Kubernetes clusters, you can use a variant of the agent mode and deploy the Collector as a sidecar to your application pods.

You need to use the OpenTelemetry operator for this deployment option. Be aware that using the Collector as a sidecar might increase resource consumption.

It's also possible to combine these deployment modes and chain Collector instances. Consider this if you are deploying the Collector in large environments.