// the find
open-telemetry/opentelemetry-collector
OpenTelemetry Collector
This is the core OpenTelemetry Collector repo — the vendor-neutral agent/gateway for receiving, processing, and exporting traces, metrics, and logs. It's the foundational library that contrib and vendor distros build on top of, not the full batteries-included distribution (that's opentelemetry-collector-contrib). Primarily aimed at platform/infra engineers building custom collector distributions or contributing components.
- The ocb (OpenTelemetry Collector Builder) tool is genuinely useful — you declare which receivers/processors/exporters you want in a YAML manifest and it generates a custom, minimal collector binary, reducing attack surface and binary size vs. shipping the kitchen-sink contrib distro.
- API stability is taken seriously: there's a VERSIONING.md, a CHANGELOG-API.md tracking API-level changes separately, and a checkapi workflow that enforces compatibility. Breaking changes in core interfaces are rare and well-telegraphed.
- mdatagen (metadata generator) automates a lot of boilerplate for component authors — generates typed metric builders, config structs, and tests from a metadata.yaml declaration, which enforces consistency across the ecosystem.
- Supply chain security is solid for an OSS project: Cosign image signing, OSSF scorecard, CodeQL, oss-fuzz integration, and SBOM via FOSSA are all wired into CI.
- This repo is intentionally minimal — it ships almost no useful receivers or exporters by itself. You almost always need opentelemetry-collector-contrib, which is a 400+ component monorepo with wildly varying stability levels. The split creates confusion for newcomers about which repo to file issues in or where to look for components.
- The Go module structure is fragmented into many independent modules (client/, cmd/builder/, each component has its own go.mod), which makes cross-cutting dependency updates painful and means `go get` on the top-level module won't pull what you actually need.
- Configuration syntax has historically been unstable — feature gates, confmap providers, and the telemetry config section have all gone through breaking changes in recent minor versions. Running the collector in production means you need to read the changelog carefully on every upgrade.
- Lack of a built-in flow control / backpressure story between pipeline components is a real operational pain point; if an exporter backs up, the default behavior is dropping data or blocking, and tuning queue sizes requires understanding internals that aren't well documented for operators.