# opentelemetry-go-contrib is a directory of modules, not one library

> The OpenTelemetry-Go Contrib repository is where the third-party packages around OpenTelemetry-Go live, split by kind into instrumentation, exporters, propagators, detectors, samplers, processors and bridges, plus an examples tree. The consequence is that it is not versioned as one thing, since a single release tag names eight module versions at once, and the project documents exactly which Go releases it tests against.

**open-telemetry/opentelemetry-go-contrib** — Collection of extensions for OpenTelemetry-Go.

- Repository: https://github.com/open-telemetry/opentelemetry-go-contrib
- Website: https://opentelemetry.io/
- Stars: 1,686 · Forks: 863
- Language: Go
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/open-telemetry-opentelemetry-go-contrib

## Eight kinds of package, one repository

The contents section is a taxonomy of the OpenTelemetry extension surface, and it is the fastest way to understand the project. The examples/ directory holds examples of OpenTelemetry library usage. The instrumentation/ directory holds packages providing OpenTelemetry instrumentation for third-party libraries. The propagators/ directory holds packages providing context propagators for third-party propagation formats. The detectors/ directory holds resource detectors for third-party cloud computing environments. The exporters/ directory holds exporters for third-party export formats. The samplers/ directory holds additional implementations of OpenTelemetry samplers. The bridges/ directory holds adapters for third-party instrumentation frameworks. And the processors/ directory holds additional implementations of processors. Every one of those directories is a set of Go modules rather than packages in a single module, and that is the single most important fact about this repository for anybody depending on it, because a dependency on one instrumentation package does not drag in the rest of the tree.

## One release, eight versions

The release tags make the multi-module structure visible. The v1.47.0 release is published as v1.47.0, v2.6.0, v0.72.0, v0.38.0, v0.27.0, v0.21.0, v0.17.0 and v0.19.0 on 2026-10-02, and the previous two releases have the same shape, with v1.46.0 covering eight versions on 2026-08-26 and v1.45.0 covering eight on 2026-08-04. The numbers tell you how uneven the maturity is across the tree, since a module at 2.6.0 has had two major versions of churn while one at 0.17.0 is still finding its shape. The project says so directly, that it contains both stable and unstable modules, and it points you at the module for its version or at a versioning manifest in versions.yaml at the root. The stability guarantees live in the versioning documentation in the upstream OpenTelemetry-Go repository, and the release automation is multimod, the multi-module tool built from the tools directory, which is what makes it possible to publish eight versions from one commit.

## The Go support window is two releases wide

The compatibility section is precise about the end of life, and it is the kind of policy that decides whether a dependency is safe to take. The project ensures compatibility with the current supported versions of the Go language, and quotes the upstream policy that each major Go release is supported until there are two newer major releases. For versions of Go that are no longer supported upstream, the removal procedure is spelled out. A minor release will be made to add support for the new supported release of Go, and the following minor release will remove compatibility testing for the oldest, now archived upstream, version of Go, and those and future releases may include features only supported by the currently supported versions of Go. In practice that means two minor releases of grace, and it means a module in this repository can gain a feature you cannot use without moving your Go version first.

## The tested matrix, and what is not promised

There is a table of the systems the project is tested on, and it is narrow in a useful way. Ubuntu, macOS and Windows are each tested with Go 1.27 and Go 1.26, and each of those with amd64, 386 and, on macOS, arm64, which gives twelve combinations in total. And then the sentence that follows, that while the project should work for other systems, no compatibility guarantees are made for those systems currently. The other guarantee on offer is the one the project makes about every module being fuzzed, with an OSS-Fuzz status badge pointing at the build logs, which matters for the parsers and the propagators in particular. The badges at the top of the README also show the build and test workflow, the code coverage report and the godoc documentation status, and there is a Slack badge for the CNCF OpenTelemetry channel, which is where the project discussions happen.

## The Makefile runs a precommit target and a ci target

The build tooling is described by two targets. The precommit target runs generate, toolchain-check, license-check, misspell, go-mod-tidy, golangci-lint-fix and test-default, and it is the default goal, so a local make runs what the pre-commit hook would run. The ci target swaps golangci-lint-fix for lint and adds build, check-clean-work-tree and test-coverage, which is the difference between a developer's loop and the pipeline. The tools themselves are not assumed to be installed. There is a tools/ directory with its own go.mod, and each tool is built on demand into a.tools directory, with golangci-lint, misspell, gocovmerge, stringer, multimod and crosslink among them, so a contributor needs a Go toolchain and nothing else. The Makefile also knows how to check that every contrib entry exists in the registry, using a base URL pointing at the open-telemetry.io content and the contrib repository URL, and there is a lychee.toml with a.lycheeignore for the link checker and a.markdownlint.yaml for the documentation, plus a dependencies.Dockerfile used to build the image the CI jobs run in.

## The examples tree is where the library shapes are shown

The examples/ directory is small and pointed, and each entry teaches a different way of using the API. There is dice, a self-contained demonstration, namedtracer, which shows the pattern of naming spans explicitly rather than relying on context, and passthrough, which is a minimal setup with a provider that does nothing but pass spans through. There is opencensus, which is a bridge example, and prometheus and prometheus-compatibility, which show how the metrics side lines up with what Prometheus already expects. And there is otel-collector, which shows an application sending to a collector rather than to a backend. The examples are not a tutorial, and the README points to the documentation site for that, but they are the reference for the shapes you are likely to need, and the opencensus one is the clearest way to understand what the bridges/ directory is for, since it shows a framework that predates OpenTelemetry being adapted into it.

## What contrib is, relative to the core

The relationship to the core project is worth being explicit about, because the two are versioned differently and people assume otherwise. This repository is a collection of third-party packages for OpenTelemetry-Go, which is the core SDK and API. The core defines the interfaces, the API and the SDK, and contrib fills in everything that talks to something outside the OpenTelemetry world, a specific HTTP client, a specific message broker, a specific cloud environment, a specific propagation format. That division is why the bridges/ directory exists, since a bridge adapts a third-party instrumentation framework into the OpenTelemetry API so that an application that has already instrumented itself does not have to be rewritten. The practical rule for an adopter is to take one or two modules rather than the repository, to check that module's own version in the versioning manifest rather than assuming the repository's tag applies to it, and to treat anything at 0.x as unstable by the project's own statement. The licence is Apache 2.0, and the project is a CNCF one with a Slack channel, a project board and milestones.

## Conclusion

opentelemetry-go-contrib is the right place to look when you need OpenTelemetry support for a specific library or backend and do not want to write the instrumentation yourself, because the packages are maintained with the upstream project and released on its cadence rather than on a stranger's. It is the wrong place to look for a coherent set of versions, since the modules carry independent version numbers and the release tag lists all of them, so a dependency update has to be reasoned about per module. Before you adopt a package from here, check the module's own version in the versioning manifest, since the README says the project contains both stable and unstable modules and points you at the module for its version, and confirm the Go version you run is one of the tested combinations, because the policy is that the oldest supported Go release loses compatibility testing one minor release after a new one is added.

## FAQ

### What is in the opentelemetry-go-contrib repository?

Third-party packages for OpenTelemetry-Go, grouped into instrumentation for third-party libraries, propagators for third-party propagation formats, resource detectors for third-party cloud environments, exporters for third-party export formats, samplers, processors, bridges that adapt other instrumentation frameworks, and an examples directory.

### Why does one release tag name several versions?

The repository is a set of independent Go modules, so a release publishes each of them, and the v1.47.0 tag covers v1.47.0, v2.6.0, v0.72.0, v0.38.0, v0.27.0, v0.21.0, v0.17.0 and v0.19.0. The project contains both stable and unstable modules, so you should check the version of the specific module you want, or the versions.yaml manifest.

### Which Go versions does opentelemetry-go-contrib support?

The currently supported Go releases, following the upstream policy that each major Go release is supported until there are two newer major releases. The tested matrix covers Go 1.27 and 1.26 on Ubuntu, macOS and Windows with amd64, 386 and arm64 on macOS, and no compatibility guarantees are made for other systems.

### How do the contrib project checks and tests work?

The Makefile has a precommit target that runs generate, toolchain-check, license-check, misspell, go-mod-tidy, golangci-lint-fix and test-default, and a ci target that adds build, a clean work tree check and coverage. The tools are built on demand from the tools/ directory go.mod into a .tools directory, so a contributor only needs a Go toolchain.

## Sources

- [License: Apache-2.0](https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/LICENSE)
- [open-telemetry/opentelemetry-go-contrib on GitHub](https://github.com/open-telemetry/opentelemetry-go-contrib)
- [Project website](https://opentelemetry.io/)
- [README](https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/README.md)
- [Releases](https://github.com/open-telemetry/opentelemetry-go-contrib/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/open-telemetry-opentelemetry-go-contrib