opentelemetry-dotnet-contrib: the overflow repository for .NET telemetry

A home for components that do not fit the core SDK

The purpose of opentelemetry-dotnet-contrib is stated in one sentence: it is intended to provide helpful libraries and standalone OpenTelemetry based utilities that do not fit the express scope of the OpenTelemetry .NET project or the OpenTelemetry .NET Automatic Instrumentation project. That is a boundary statement, and it is the right way to read the repository. The core SDK and the automatic instrumentation project own the general case, the SDK itself and the out of the box instrumentation that works without code changes. Anything more specialised, a protocol specific instrumentation library, an exporter for a particular backend, a helper for a particular framework, goes here. The description says it directly: instrumentation libraries, exporters and other components can find their home here. The audience is a .NET developer who has already adopted OpenTelemetry and now needs the one integration their stack lacks, and who does not want to write that instrumentation themselves.

The version suffix tells you what you are taking on

The most useful thing this README does is define a maturity ladder and attach it to package version strings, because a repository of many packages maintained by many groups otherwise gives you no signal. A component in Development is not available on NuGet at all. Alpha is ready for limited non-critical workloads, the authors welcome feedback, bugs and performance problems should be reported but component owners might not work on them right away, components can go through significant breaking changes, and there are no backward compatibility guarantees. Beta is the same thing but comparatively more stable. Release candidate means the component is close to stability, there may be minimal breaking changes between releases, and the component is expected to have had exposure to non-critical production workloads during its alpha or beta phases. Stable is ready for general availability, bugs should be reported and the owners should triage or resolve them in a timely manner, and package versions must follow SemVer V2. The convention is that alpha packages carry the -alpha extension, beta packages the -beta extension, and release candidates the -rc extension.

Deprecated and development bracket the usable range

Two ends of that ladder deserve as much attention as the middle. Deprecated means development of the component is halted, no new package versions are planned, and new issues will not be worked on. For a production dependency that is a warning rather than a change, since a component can be marked deprecated while you still depend on it, and the fix is to migrate rather than to wait. Development, at the other end, means the component is not published to NuGet at all, so it cannot be consumed as a package in the usual way. The practical reading of the whole scheme is that a NuGet package name in this repository tells you three things at once: what the component does, which maturity level it sits at, and whether its maintainers are obliged to answer a bug report promptly. Only the stable category carries the promise of timely triage, and only stable is bound to SemVer V2, so a lock file pinning a beta package is pinning something that can still move in a breaking way.

Maintainers, approvers and triagers do not own every component

The support section sets out an honest governance model, and the key sentence is that this repository is maintained by the .NET Contrib maintainers team and the .NET Contrib approvers who can help with reviews and code approval, but since individual components are developed by numerous contributors, approvers and maintainers are not expected to directly contribute to every component. The list of owners for each component is in that component's own README. So when a bug is filed against a specific package, the people who will look at it are the component owners, not the general maintainer team. Above that sit the roles, a triagers team that handles community triage, an approvers team with named engineers from Grafana Labs and Elastic, and a maintainers team with engineers from New Relic, Grafana Labs, Splunk and Microsoft. The emeritus section lists people who have stepped back, which is a public record of turnover rather than a formality, and the community repository holds the written definition of each role.

One solution file, many packages and many examples

The repository layout shows how a multi package C# repository is organised in 2026. There is an opentelemetry-dotnet-contrib.slnx solution file and an opentelemetry-dotnet-contrib.proj project, with src/ holding the components, test/ the test projects and build/ the build logic. Versioning across dozens of packages is centralised in Directory.Build.props and Directory.Packages.props, and global.json pins the SDK used to build, while Directory.Packages.props is the natural place to manage a shared package version for a set of components. Code ownership is declared in CODEOWNERS, which is what routes a pull request to the right component owners. The examples/ directory is unusually broad, with sample projects for AspNet, InfluxDB, enrichment, event-counters, grpc.core, kafka, owin, process-instrumentation, redis, runtime-instrumentation and wcf, and those examples are the fastest way to see how a component is wired into an application. The remaining files are the standard modern hygiene set: an .editorconfig, a .clomonitor.yml for the OpenSSF monitor, an .oss-scanner/ directory, .yamllint and .markdownlint.yaml, a .typos.toml, a REVIEW.md, an AGENTS.md and a benchmark.ps1 script.

Releases are per component and they do not move together

The release history is the clearest illustration of the component model. The three most recent releases are PersistentStorage-1.1.2 from 2026-10-16, Instrumentation.ServiceFabricRemoting-1.20.0-beta.2 from 2026-10-16 and Instrumentation.EventCounters-1.20.0-alpha.2 from 2026-10-16, all published on the same day. Read them as separate release trains. PersistentStorage is a stable package with a plain version, the ServiceFabric remoting instrumentation is still in beta at 1.20.0, and the EventCounters instrumentation is at an alpha of 1.20.0, which matches the alpha suffix rule described earlier. The consequence for dependency management is that a single application can end up pinning one component at a stable version, one at a beta and one at an alpha on the same day, and each of those moves on its own schedule. Planned releases are tracked in the repository milestones, and the README points there for upcoming dates and features. The last push to the main branch was on 2026-10-20, so the tree moves faster than any single component's version number suggests.

How contrib differs from the core SDK and automatic instrumentation

The alternative to using this repository is to put the component in one of the two neighbouring projects, and the difference in approach is a question of scope and support rather than of code. The OpenTelemetry .NET project is the SDK itself, the core API, the pipeline and the exporters that every user of OpenTelemetry in .NET needs, so anything there is treated as part of the framework surface and changes with the SDK's own compatibility promises. The automatic instrumentation project covers the case where you attach OpenTelemetry to a .NET application with no code changes, through a profiler or a startup hook, and it ships the agent, the runtime and the set of instrumentations that must work in that no-touch model. Contrib is where the long tail lives, where a component is useful to a narrower group, is easier to build outside the core release cadence, and can be owned by a team with a specific interest. The practical difference when something breaks is where you file the issue and what promise you were given, and the answer to that is written in the component's README rather than in the core project's.

Editorial conclusion

opentelemetry-dotnet-contrib suits .NET teams that need an exporter or instrumentation library for a specific stack and cannot find it in the core SDK or the automatic instrumentation project, and who are willing to read the component README before depending on it. It is a poor fit if you want one uniformly supported telemetry stack, because components here are maintained by different authors and can change with breaking changes while still carrying an alpha suffix. Before adding a package, read the status section of that component's own README and check whether the version you are pinning carries the -alpha, -beta or -rc extension.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. open-telemetry/opentelemetry-dotnet-contrib on GitHub
3. Project website
4. README
5. Releases