// the take
This is the official grab-bag of OpenTelemetry-Go extensions: instrumentation for third-party libraries (loggers, HTTP frameworks, gRPC, etc.), cloud resource detectors for every major provider, propagators, exporters, and bridges. It's for Go developers already using opentelemetry-go who need auto-instrumentation for a specific library or need to tag telemetry with cloud metadata (AWS, GCP, Azure, Alibaba, IBM, Hetzner, Scaleway...) rather than writing that glue themselves.
Each subdirectory is its own Go module with its own go.mod/go.sum, so adding the Zap bridge doesn't drag in AWS SDK dependencies for the EC2 detector - you only pull what you use. CI matrix covers three OSes, two Go versions, and both amd64/386, plus OSS-Fuzz fuzzing and codecov tracking, which is a real commitment for a contrib repo this size. Backed by the CNCF project directly, not a single company's side project, so detector/exporter coverage is broad and the propagator implementations follow the actual specs rather than reinventing them.
The repo is explicitly a mix of stable and unstable modules (see versions.yaml) with no indication at the top level which is which - you have to go module by module to find out if what you're depending on can break under you. The root README is just a directory listing; there's no contrib-specific getting-started doc, so onboarding means reading individual package READMEs (several of which, like the cloud detectors, don't have one at all - just doc.go). Being tied to opentelemetry-go's release cycle means a bump there can force simultaneous updates across dozens of go.mod files in this repo if you depend on several packages. Maintenance quality is uneven by nature - some detectors (ecs, eks, lambda) are heavily used and well-tested, others (ibmcloud/vpc, vultr) look like single-contributor additions with thin test coverage.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →