OTel Collector¶
The OpenTelemetry Collector is a vendor-agnostic pipeline engine that receives, processes, and exports telemetry — a single codebase deployable as either an agent or a gateway, supporting traces, metrics, and logs (profiles exist experimentally behind feature gates). This is the component-level companion to the OpenTelemetry guidance topic, which covers how organizations deploy it.
Overview¶
Per the project's own repository objectives, the Collector is "unified: single codebase, deployable as an agent or collector with support for traces, metrics and logs." Every claim in this topic survived adversarial verification against live primary sources (opentelemetry.io docs, open-telemetry GitHub repos/APIs, pkg.go.dev) on 2026-08-27; four deliberately conservative claims carry 2-1 split votes and are labeled medium confidence. See Architecture for pipeline internals and deployment topologies, Operations for install, autoscaling, and release-hygiene recipes.
Releases And Versioning¶
The core repo uses dual-versioning: each release pairs a stable v1.x tag with a module/distribution v0.x tag. Latest verified: v1.65.0 / v0.159.0, published 2026-08-17.
- Release cadence measured at 13–15 days across ten consecutive releases (documented policy: strict 14-day intervals, short 2-week cycles).
- No formal LTS, end-of-life, or support-window policy exists — the only published commitment is an aim to ship security fixes within ~30 days.
Operational Implication
With two-week releases and no LTS, running Collectors means planning regular upgrades rather than freezing versions. The Operator's automatic upgrade handling exists partly to absorb this churn.
Official Distributions¶
Exactly five pre-built distributions are published from opentelemetry-collector-releases:
| Distribution | Binary | Focus |
|---|---|---|
| Core | otelcol |
Minimal foundation set |
| Contrib | otelcol-contrib |
Broad component zoo |
| Kubernetes | otelcol-k8s |
K8s-tailored defaults |
| OTLP | otelcol-otlp |
OTLP-only lean build |
| eBPF Profiling | otelcol-ebpf-profiler |
Profile signal collection (~mid-2025 addition — there were four before it) |
Third-party distributions (AWS Distro for OpenTelemetry, Grafana Alloy, Datadog DDOT, Splunk OTel) exist but are not project-published. Anything beyond these five is built with the Collector Builder — see Operations.
Position In The Vault¶
- OpenTelemetry guidance topic — blueprint doctrine and Adobe/Mastodon/Skyscanner production topologies; this folder supplies the engine internals those topologies run on
- Backend topics consuming Collector output: SigNoz, LGTM Stack, Victoria Stack, Apache SkyWalking
- Domain hub: Observability
Evaluation¶
Choosing between the five official distributions:
| If you need… | Pick |
|---|---|
| Smallest reasonable static build, OTLP-only pipelines | otelcol-otlp |
| Kubernetes install with sensible local defaults | otelcol-k8s |
| The wide receiver/exporter/processor zoo | otelcol-contrib |
| A hand-curated component set (incl. your own Go components) | ocb custom build |
| Profile-signal collection via eBPF | otelcol-ebpf-profiler |
Anti-pattern to avoid: running contrib everywhere by default when workloads only speak OTLP — the distributions exist precisely so platform teams do not ship unused components into every pod.
Sources¶
All URLs verified HTTP 200 on 2026-08-27.
| Source | Kind |
|---|---|
| Collector architecture | Primary docs |
| Collector configuration | Primary docs |
| Internal telemetry | Primary docs |
| Distributions | Primary docs |
| Collector Builder (ocb) | Primary docs |
| Gateway deployment | Primary docs |
| Agent-to-gateway pattern | Primary docs — modified July 2026 |
| Kubernetes install | Primary docs |
| Resiliency | Primary docs — verified in gap-closing pass |
| Scaling guide | Primary docs — tail-sampling routing + memory-limiter behavior |
| Benchmarks | Primary docs — fetched twice; no numeric claims survived yet |
| Operator HPA autoscaling | Primary docs |
| Core repo | Primary source + releases API + release.md |
| Releases repo | Primary source |
| pdata package docs | Primary — v1.65.0 |
| exporterhelper README | Primary code doc — queue/retry defaults |
| filestorage extension README | Primary code doc — max_size cap, rebound compaction |
| memorylimiterprocessor README | Primary code doc |
| loadbalancingexporter README | Primary code doc |
| tailsamplingprocessor README | Primary code doc |
| configauth README | Primary code doc — authenticator matrix |
| configtls README | Primary code doc |
| opAMP spec | Primary spec — formally Beta as of 2026-08-27 |
| OpAMP Supervisor specification | Primary — remote-config viable; package upgrades blocked (#47272) |
| contrib issue #35378 | Tracker — data loss on DNS change behind LB exporter |
| CNCF: Operating OpenTelemetry at scale with OpAMP | Practitioner corroboration |
| KEDA scaling concepts | Practitioner corroboration |
Questions¶
Resolved by the second verification pass (2026-08-27):
- Queue/retry/persistent-storage semantics → Resiliency Internals and resiliency recipes in Operations
- OpAMP readiness verdict → Management plane: remote config yes (conservatively), executable/package upgrades no
- Auth extension landscape → Auth matrix
Still open:
- Published reproducible benchmarks for tail sampling overhead (CPU/span, decision-cache ceilings)? → Open Gaps; starts from the benchmarks page
- Batch processor tuning guidance under overload/backpressure specifically?
- Documented secret-provider / confinement story beyond the static authenticator matrix (security best practices unexplored)?
- Joint sizing doctrine for
queue_size×filestorage max_size× disk budgets on persistent-queue deployments?