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
otelcolbinary/service.
Alternatively, you can also build the Collector from its source code.
Docker
To install using a container image for Docker, run the appropriate command for the Core or Contrib distribution type.
1docker pull otel/opentelemetry-collector
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.
1apiVersion: opentelemetry.io/v1alpha12kind: OpenTelemetryCollector3metadata:4 name: otel-col5 namespace: otel-col6spec:7 mode: daemonset8 image: otel/opentelemetry-collector9 config: |10 ...
Helm
For Helm, OpenTelemetry provides the following charts, which need to be configured in values.yaml.
1image:2 repository: otel/opentelemetry-collector34command:5 name: otelcol
Deployment Modes
The Collector can be deployed as a standalone agent, a gateway, or a sidecar.
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.
It's also possible to combine these deployment modes and chain Collector instances. Consider this if you are deploying the Collector in large environments.