# OpenTelemetry .NET: wiring logs, metrics and traces into a .NET service > The OpenTelemetry .NET client is the vendor-neutral instrumentation layer for C# applications, stable across logs, metrics and traces. It is a set of NuGet packages, not a single drop-in agent, and that shape decides most of the adoption work. **open-telemetry/opentelemetry-dotnet** — The OpenTelemetry .NET Client - Repository: https://github.com/open-telemetry/opentelemetry-dotnet - Website: https://opentelemetry.io - Stars: 3,761 · Forks: 906 - Language: C# - License: Apache-2.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/open-telemetry-opentelemetry-dotnet ## The problem OpenTelemetry .NET solves for C# teams A .NET service usually produces three kinds of telemetry that were historically collected by three different vendor SDKs, each with its own API shape and its own upgrade cycle. OpenTelemetry .NET replaces that with one implementation of the OpenTelemetry specification, shipped as separate NuGet packages under the OpenTelemetry profile. The README describes the repository as containing only what is defined in the specification, with each component carrying its own README.md and CHANGELOG.md. The audience is the team that owns the application code. Because instrumentation happens through the API and SDK packages rather than a runtime agent, the developers who write the service are the ones who add it. That is a deliberate trade: more code changes than a bytecode-style agent, but the telemetry pipeline becomes a normal dependency you version and test like any other. The project status line is unusually blunt for a telemetry library: stable across all three signals, Logs, Metrics and Traces. That matters because OpenTelemetry implementations in other languages reached that point at different times, and a team choosing a stack has to know whether the .NET side is still moving under their feet. ## How the API, SDK and exporters fit together The architecture follows the specification's split between producing telemetry and shipping it. The OpenTelemetry API package is what application and library code calls. The OpenTelemetry SDK package is the implementation that actually records, samples and batches. The Hosting Extensions package is what wires the SDK into the generic host that ASP.NET Core applications already use. Exporters are separate libraries, and the README lists them explicitly: Console, In-memory, OTLP (OpenTelemetry Protocol), Prometheus AspNetCore and Prometheus HttpListener. That list is the whole story of where your data can go from this repository. Anything else is a different package or a collector that speaks OTLP. The data flow is therefore: instrumented code emits through the API, the SDK collects and processes, and an exporter serialises to a destination. Because those are distinct packages, you can change the destination without touching instrumentation, which is the practical reason teams accept the extra dependency surface. One consequence worth stating plainly: the repository ships no backend and no dashboards. It stops at the wire. ## Installing OpenTelemetry .NET and getting a first trace out The README does not give a top-level install command. It points to getting started guides per signal, each with an ASP.NET Core and a Console variant, under docs/logs, docs/metrics and docs/trace. For a console application tracing guide, the flow is a package reference, then a TracerProvider built with a service name and an exporter. The repository's package profile on NuGet is where the component names live, and the README links each component under src/ to its own README.md, which is where install and get started instructions sit. The repository also carries a runnable examples folder with AspNetCore, Console, GrpcService and MicroserviceExample projects, so the fastest way to see the wiring is to open one of those projects and follow its references into the component READMEs. What you should expect to find in a component README is the package to reference, the builder call that registers the component with the provider, and the exporter configuration. The README for this repository stops at that pointer; it does not reproduce the snippets itself. Read the component README for the exact package and API names before you write any code, because those are the files the project treats as authoritative. ## Where OpenTelemetry .NET is the wrong choice The project is explicit that some components are pre-release and can take breaking changes before a stable release, and it tells you to check each component's README.md to understand its current state. If your organisation cannot absorb a dependency that changes shape between minor versions, that warning is the deciding factor, not the feature list. A second boundary is the absence of an agent. Nothing in the README describes auto instrumentation for an already-compiled application. If you need telemetry from a service you cannot rebuild, this repository's packages will not give it to you; the related search phrase "opentelemetry dotnet auto instrumentation" points at a different project, and the README does not claim that capability here. Third, exporter coverage is finite. The README lists Console, In-memory, OTLP, and the two Prometheus exporters. If your backend has no OTLP endpoint and no collector in front of it, you are writing an exporter or waiting for one. Finally, .NET Framework is supported except version 3.5, with exceptions noted per component. Legacy Windows services on old runtimes should read the individual README before assuming parity with modern .NET. ## OpenTelemetry .NET compared with Application Insights SDK The closest thing to a default in the .NET world is the Application Insights SDK, and the difference is not a matter of quality but of where the coupling sits. Application Insights instrumentation is written against a vendor's API and sends to that vendor's ingestion endpoint. OpenTelemetry .NET instrumentation is written against the specification's API and sends through an exporter you choose. In practice that changes three things. Swapping backends becomes an exporter change in the host configuration rather than a rewrite of every instrumentation call site. Library authors can emit telemetry without taking a dependency on your monitoring vendor, which is the point of the API package existing separately from the SDK. And the configuration surface moves into the generic host, alongside the rest of your service configuration. The cost is real: you now own the pipeline, including the exporter choice and the collector that sits behind it. Teams that only ever intend to use one backend and value the shortest path to a working dashboard will find the vendor SDK faster to stand up. Teams that expect the backend to change, or that ship libraries consumed by other people, get more from the specification-based route. ## Release cadence, versioning and licence obligations Releases are frequent and versioned per component rather than as a monolith. The recent release list shows core-1.19.1 alongside coreunstable-1.19.1-beta.1 and a core-1.19.1-rc.1, which is the pattern to expect: a stable line and an unstable line that can break. The repository has a VERSIONING.md that defines pre-releases, and the README's caution box is a direct reference to it. That cadence has an upgrade cost. Because components version independently, a service can end up on several OpenTelemetry package versions at once, and the per-component CHANGELOG.md files are where you find out what moved. Budget for reading them at upgrade time rather than assuming a single version bump covers everything. The repository is licensed Apache-2.0, and the LICENSE.TXT is at the top level. Apache-2.0 is permissive and includes an explicit patent grant, which is why it is common in infrastructure projects. It also carries notice and attribution requirements; THIRD-PARTY-NOTICES.TXT in the repository root is where the project tracks its own third-party dependencies. If your legal team has questions about redistribution or notices, that file is the starting point rather than this article. The last push to the default branch was on 2026-09-23, and the most recent stable release core-1.19.1 was published on 2026-09-21. ## Conclusion Adopt OpenTelemetry .NET when you control the application source and want telemetry that is not tied to one backend; the repository lists the API, SDK, Hosting Extensions and exporter packages as the common starting set. Do not adopt it expecting a zero-code agent: the README points newcomers at the getting started guides in docs/ and leaves instrumentation to the individual component READMEs. Before committing, check the README.md of each component you plan to use, because the project warns that pre-release components can take breaking changes, and confirm which exporter matches your collector. ## FAQ ### What is OpenTelemetry .NET and what is it used for? It is the .NET implementation of the OpenTelemetry specification, shipped as separate NuGet packages for logs, metrics and traces. Teams use it to instrument C# applications once and export the resulting telemetry through a chosen exporter such as OTLP, Console or Prometheus. ### Is OpenTelemetry .NET free to use? The repository is licensed under Apache-2.0, which permits commercial use, and the packages are published on NuGet. The licence carries notice and attribution requirements, and the repository tracks third-party dependencies in THIRD-PARTY-NOTICES.TXT. ### Is OpenTelemetry .NET difficult to learn? The README does not make a claim about difficulty, but it does route newcomers to getting started in 5 minutes guides for each signal, in both ASP.NET Core and Console variants. The API, SDK and exporter split means there is more than one package to understand before telemetry reaches a backend. ## Sources - [License: Apache-2.0](https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/LICENSE) - [open-telemetry/opentelemetry-dotnet on GitHub](https://github.com/open-telemetry/opentelemetry-dotnet) - [Project website](https://opentelemetry.io) - [README](https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/README.md) - [Releases](https://github.com/open-telemetry/opentelemetry-dotnet/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-dotnet