Open-Source Observability · open-telemetry

opentelemetry-dotnet

OpenTelemetry .NET is the official .NET implementation of OpenTelemetry, providing standardized instrumentation for distributed tracing, metrics, and logging across .NET applications. It supports modern .NET versions and .NET Framework, offering stable APIs and multiple export backends (OTLP, Prometheus, Zipkin, console).

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/open-telemetry/opentelemetry-dotnet

3.7k

GitHub stars

889

Forks

Primary language

Apache-2.0

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	open-telemetry/opentelemetry-dotnet
Owner	open-telemetry
Primary language	C#
License	Apache-2.0 — OSI-approved
Stars	3.7k
Forks	889
Open issues	143
Latest release	core-1.16.0 (2026-06-10)
Last updated	2026-07-08
Source	https://github.com/open-telemetry/opentelemetry-dotnet

What opentelemetry-dotnet is

A production-ready SDK implementing the OpenTelemetry specification for C#/.NET, delivering three signals (traces, metrics, logs) via pluggable exporters and extensible instrumentation libraries. Integrates natively with ASP.NET Core and standard .NET logging/metrics APIs; components are distributed as NuGet packages with modular architecture.

Quickstart

Get the opentelemetry-dotnet source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/open-telemetry/opentelemetry-dotnet.git2cd opentelemetry-dotnet3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Distributed tracing in microservices

Instrument ASP.NET Core services to emit traces via OTLP or Zipkin; correlate requests across service boundaries with built-in context propagation and W3C Trace Context support.

Metrics collection for observability

Export application and system metrics to Prometheus, Jaeger, or other OTLP backends; leverage instrumentation libraries for HTTP, database, and message queue metrics out-of-the-box.

Centralized application logging with correlation

Emit structured logs with trace/span IDs to centralized logging platforms; maintain correlation between logs, metrics, and traces for end-to-end visibility.

Implementation considerations

Start with one signal (traces, metrics, or logs) and the appropriate getting-started guide (ASP.NET Core or console) to avoid configuration complexity.
Pre-release components can introduce breaking changes; review individual component READMEs and versioning guidance before selecting them for production.
Exporter choice (OTLP, Prometheus, Zipkin) depends on downstream observability stack; OTLP is the standard, but ensure backend support.
Instrumentation libraries (in opentelemetry-dotnet-contrib) cover common frameworks; verify availability for your specific dependencies before adoption.
Context propagation (trace IDs across services) requires compatible instrumentation on all .NET services; mixed-language environments need language-specific implementations.

When to avoid it — and what to weigh

Targeting .NET Framework 3.5 exclusively — Project explicitly does not support .NET Framework 3.5; requires .NET Framework 4.6.2+ or modern .NET versions.
Requiring proprietary vendor lock-in observability — OpenTelemetry is vendor-neutral and standardized; if your architecture demands tight coupling to a specific commercial tool's SDK, this may not align.
Lightweight single-process applications with no distributed requirements — For simple console applications without cross-service communication, the overhead and complexity of OpenTelemetry instrumentation may be unnecessary.
Pre-release components in production without strong governance — Some components (noted in individual READMEs) remain pre-release and may have breaking changes; verify stability of specific components before production deployment.

License & commercial use

Licensed under Apache License 2.0 (Apache-2.0), a permissive OSI-approved license.

Apache-2.0 permits commercial use, modification, and distribution with minimal restrictions (retain copyright/license notices, state significant changes). No warranty is provided. For complex commercial scenarios or enterprise SLAs, consult the full license terms and consider organizational compliance review.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Strong
License clarity	Clear
Deployment complexity	Low
DEV.co fit	Strong
Assessment confidence	High

Security considerations

OpenSSF Scorecard and Best Practices badge indicate security focus. FOSSA license and security status monitoring in place. Standard practices: credential management for exporter endpoints (OTLP, Prometheus auth), TLS for remote export, and secrets not embedded in instrumentation. No CVEs claimed in provided data; refer to GitHub Security advisory for current status.

Alternatives to consider

Application Insights SDK (.NET)

Proprietary Microsoft solution tightly integrated with Azure Monitor; simpler setup for Azure-first workloads but lacks vendor neutrality and portability of OpenTelemetry.

Elastic APM Agent (.NET)

Vendor-specific APM agent optimized for Elastic Stack; mature and feature-rich for Elastic users but not standardized or portable across backends.

Datadog .NET APM

Proprietary agent for Datadog platform; deep integration with Datadog services but lacks flexibility and vendor independence of OpenTelemetry.

Software development agency

Build on opentelemetry-dotnet with DEV.co software developers

Start with the OpenTelemetry .NET getting-started guide. Choose ASP.NET Core or console app samples, select your signals (traces, metrics, logs), and export to your observability backend. Requires .NET 6+ or .NET Framework 4.6.2+.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

opentelemetry-go ApplicationInsights-dotnet opentelemetry-rust

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Observability API Development Application Development DevOps Talk to DEV.co

opentelemetry-dotnet FAQ

Is OpenTelemetry .NET production-ready?

Yes: the project status states 'Stable' across all three signals (Logs, Metrics, Traces). However, specific components marked pre-release may still undergo breaking changes; review individual component READMEs.

What .NET versions are supported?

All officially supported .NET versions and .NET Framework (except .NET Framework 3.5). Refer to dotnet.microsoft.com for current support timelines; exceptions noted in individual package READMEs.

How do I export telemetry to a specific backend?

Choose an exporter package: OTLP (generic), Prometheus, Zipkin, Console, or InMemory. For other backends, check opentelemetry-dotnet-contrib or the OpenTelemetry registry for community exporters.

Can I use OpenTelemetry with existing .NET logging and metrics libraries?

Yes: OpenTelemetry integrates with ILogger/ILoggerProvider and standard .NET metrics APIs without conflicts; it extends, not replaces, existing frameworks.

Work with a software development agency

DEV.co helps companies turn open-source tools like opentelemetry-dotnet into production software. Our software development services cover the full lifecycle — architecture, web development, integration, and maintenance — delivered by software developers and web developers who ship. Engage our software development agency to implement or customize it for your open-source observability stack.

Ready to instrument your .NET applications?

Talk to DEV.co Schedule a Consultation