Skip to main content
This lesson explains OpenTelemetry Collector distributions: how they’re packaged, extended, and when to build a custom collector. You’ll learn the differences between Collector Core and Contrib, how to pick components safely, how to create a tailored build with the OpenTelemetry Collector Builder (OCB), and high-level Kubernetes deployment patterns. Here’s the big-picture outline: compare Collector Core vs Contrib, decide when to build a custom collector, review support and releases, and preview Kubernetes deployment patterns.
The image outlines the key aspects of "OTel Collector Distributions: The Big Picture," including comparing OTel Collector Core vs Contrib, deciding when to build a custom collector, and understanding support and release.

​
Collector Core — minimal, stable foundation

The Collector Core distribution is intentionally conservative and small. It contains the officially maintained components required to build predictable telemetry pipelines: receivers, processors, exporters, and extensions. Core’s limited surface area and slower cadence make it easier to audit, upgrade, and operate safely in production.
The image outlines the OTel Collector Core, highlighting a lean set of components: Receivers, Exporters, Processors, and Extensions.
What Core typically includes
  • Receivers: otlp and simple/no-op receivers for testing or when no external input is required.
  • Exporters: otlp, no-op, debug/logging exporters.
  • Processors: batch, memory_limiter, and other stability-focused processors.
  • Extensions: health_check, pprof, zpages, etc.
Keeping your runtime close to Core reduces upgrade risk and simplifies security reviews.
The image shows a table describing components of a "Collector Core," divided into "Core Data Flow" and "Stability & Extensions," listing different types of receivers, exporters, processors, and extensions. It emphasizes that a minimal core ensures predictable upgrades.

​
Collector Contrib — broad integrations, faster change

Contrib extends Core with community- and vendor-contributed components. It includes integrations for Prometheus, Kafka, Jaeger, cloud providers (AWS, Azure, GCP), and many other systems. Contrib is feature-rich and moves faster, but many components are experimental or community-maintained—validate maturity before production use.
The image is an educational slide titled "Understanding Contrib" featuring logos and names of various technologies like Prometheus, Kafka, Jaeger, AWS, Azure, and GCP. It includes notes stating "Not default for production" and "Validate maturity first."
Component stability Contrib components typically progress through these stability stages: Development → Alpha → Beta → Stable. Use Development/Alpha/Beta for experimentation. Only promote a component to production once it is declared Stable and validated in your environment. Stability may vary across signals (traces/metrics/logs) and across different features of the same component.
The image depicts a bar diagram showing stages of component stability: Development, Alpha, Beta, and Stable, progressing from testing to production. It illustrates how stability can vary per signal or feature.
Feature gates Experimental features are often controlled by feature gates (runtime toggles). Only enable feature gates after testing. Feature gates can be set via CLI or environment variables; check each component’s documentation for exact gate names and semantics. Example usage patterns:

​
Core vs Contrib — quick comparison

AspectCoreContrib
ScopeMinimal, vetted componentsWide range of community/vendor integrations
Change cadenceSlower, conservativeFaster, more experimental
RiskLower upgrade/surface area riskHigher; validate maturity per component
Use caseProduction-critical, audit-sensitive environmentsIntegration testing, rapid prototyping, broad connector needs
The image compares "Core" and "Contrib" components, highlighting attributes like minimal set and slower change for Core, versus broad coverage and faster change for Contrib. It also suggests guidelines for production usage of these components.

​
When to build your own collector

If Contrib components you rely on are stable but you want a smaller, more controlled runtime, build a custom collector. Benefits:
  • Smaller images/binaries containing only needed components.
  • Reduced attack surface and fewer third-party dependencies.
  • Easier compliance and security reviews.
  • Predictable upgrades and consistent test results across environments.
The image is an infographic titled "Why Build Your Own Collector?" outlining benefits such as smaller images, reduced attack surface, easier compliance, and operational ease at scale.

​
How to build a custom collector (OCB)

Use the OpenTelemetry Collector Builder (OCB) to generate a tailored collector binary or container image:
  1. Create a manifest YAML that lists the receivers, processors, exporters, and extensions you require.
  2. Run OCB to generate a custom binary or container image containing only those components.
  3. Publish the resulting image to your registry and deploy it.
Example minimal OCB manifest snippet:
Recommended workflow
  • Build the OCB image in CI, pinning component versions.
  • Run integration tests in staging and validate upgrade paths.
  • Push the image to a private registry and roll out via your normal deployment pipelines.
The image outlines a process for using the OpenTelemetry Collector Builder (OCB), involving defining a manifest file, running OCB to generate a binary/container, and publishing the image to a registry.
Useful commands and links

​
Support models: community vs vendor

Support typeTypical characteristicsRecommended when
Community (Core/Contrib)GitHub issues, community discussions, best-effort supportDevelopment, experimentation, and early testing
Vendor distributionsSLAs, tested bundles, official support channelsProduction-critical deployments needing guaranteed support
Vendor distributions often include compatibility testing with that vendor’s backend and may be preferable for production environments that require SLAs.
The image compares community support with vendor support models, highlighting features like GitHub issues and discussions for community and SLAs and tested bundles for vendors. It notes vendor distros are recommended for production.

​
Where to find releases

Core and Contrib binaries, OS packages, and container images are published in the OpenTelemetry Collector Releases repository: Use official artifacts for development and early testing. For production, prefer a validated OCB-built image or a vendor-supported distribution.
The image outlines two production paths for running collectors: building your own collector with OCB using validated components, or using a vendor-supported distribution for production.

​
Best practices

  • Start by experimenting with Contrib to validate integrations and workflow.
  • Track component stability labels and record feature gate usage.
  • Pin versions and run upgrade tests in staging before promoting to production.
  • Right-size your collector with OCB so only vetted components are included.
  • Avoid enabling unnecessary or unstable components in production unless protected by feature gates and covered by tests.
  • Automate build and deployment (CI/CD) and deploy collectors declaratively.

​
Kubernetes deployment patterns (high-level)

Common deployment patterns:
  • Sidecar: a collector runs alongside each application pod — ideal for fine-grained telemetry capture and low-latency forwarding.
  • DaemonSet: one collector per node — useful for node-level and host-level telemetry collection.
  • Centralized Deployment: a set of centralized collectors that aggregate, process, and export telemetry for multiple services.
These patterns are covered in depth in a dedicated Kubernetes lesson.
The image illustrates a high-level view of Kubernetes deployment, highlighting three patterns: Sidecar, DaemonSet, and Deployment. Each pattern is demonstrated through diagrams involving nodes, pods, and collectors within a Kubernetes cluster.

​
Operator-driven management

An OpenTelemetry Operator automates collector lifecycle management in Kubernetes:
  • Declare a Custom Resource (CR) manifest.
  • The operator watches and reconciles the CR, creating and managing collector pods.
  • This approach fits GitOps practices and simplifies upgrades and scaling.
Operator repo and docs: https://github.com/open-telemetry/opentelemetry-operator
The image illustrates an operator-driven setup concept in Kubernetes, showing a flow from a Custom Resource Definition (CRD) in a YAML file to an operator (controller), and finally to collector pods running in Kubernetes.
For production, prefer validated OCB builds or vendor-supported distributions and deploy collectors declaratively (for example, via the OpenTelemetry Operator) to ensure reproducibility and easier operations.

​
Wrap-up

  • Collector Core: minimal and stable — ideal for predictable, low-risk deployments.
  • Collector Contrib: broad integrations and faster innovation — validate component maturity and stability before production use.
  • Use feature gates to control experimental behavior and test thoroughly.
  • For scale and safety, build a tailored collector with OCB or adopt a vendor-supported distribution.
  • In Kubernetes, deploy collectors declaratively (Operator/CRDs) and choose the deployment pattern that fits your telemetry and operational needs.

Watch Video