// the find
open-telemetry/opentelemetry-collector-contrib
Contrib repository for the OpenTelemetry Collector
The community-maintained extension repository for the OpenTelemetry Collector, containing hundreds of receivers, processors, exporters, and connectors that don't belong in the core repo. This is the primary destination for anyone integrating OTel with real-world infrastructure—Kafka, AWS, Datadog, Prometheus, databases, cloud services, etc. If you're running the OTel Collector in production, you're almost certainly pulling from this repo.
- Massive breadth of components covering nearly every observable system—MySQL, PostgreSQL, Kafka, AWS CloudWatch, GCP, Datadog, Jaeger, Zipkin, and dozens more, each in its own isolated Go module so you only pull what you need
- CI infrastructure is genuinely impressive: scoped test runs, ARM/Windows/Darwin build matrices, Prometheus compliance tests, load tests, and golden file testing, plus automated codeowner pinging and stale issue management
- Stability levels (Development/Alpha/Beta/Stable) are tracked per-signal per-component, so you know exactly what you're getting into before shipping a component to prod
- Governance is explicitly designed to prevent vendor capture—the 25% per-employer cap on maintainers is enforced, and the current maintainer list spans Elastic, Splunk, DataDog, Grafana, Snowflake, Honeycomb, and Dynatrace
- Component quality variance is extreme: a Stable traces component from a major vendor and an Alpha metrics component with one part-time codeowner live side by side with no obvious UI distinction beyond reading individual READMEs
- The repo is a monorepo of ~300+ Go modules, which means `go get` or toolchain upgrades can turn into a multi-hour coordination exercise; the Makefile complexity alone is a maintenance burden that scares off casual contributors
- Many components list vendor employees as sole codeowners—when that person changes jobs or gets reassigned, the component quietly goes unmaintained, and the 'downgrade to unmaintained' process is reactive rather than proactive
- End-to-end testing requires spinning up real infrastructure (Kafka, databases, cloud accounts), so local development of certain components is impractical without either Docker Compose sprawl or cloud credentials, and the e2e tests are gated behind CI rather than easily runnable locally