OpenTelemetry .NET: The Monitoring Savior for Hybrid Tech Stacks

OpenTelemetry .NET: The "Swiss Army Knife" of the Observability Era

As a Java veteran who's been "tortured" by Spring Boot Actuator and Micrometer for years, I approached .NET's observability solutions with quite a bit of skepticism. But after diving into the OpenTelemetry .NET project, I have to say: Microsoft has truly caught up with the cloud-native rhythm this time.

What the Heck Is This Thing?

Simply put, OpenTelemetry .NET is the official .NET implementation of CNCF's "cloud-native observability standard framework." You might ask: "I don't write .NET, so what's it to me?" Brother, let me give you some advice—these days, which enterprise application isn't a microservices hodgepodge? Java, .NET, Go, Node.js all running together. Without a unified observability standard, troubleshooting can make you question your life choices.

The pain point this project addresses is very direct: enabling .NET applications to collect Logs, Metrics, and Traces data using a unified standard, then sending it to any compatible backend (Jaeger, Prometheus, Zipkin, etc.). It's like installing standardized "monitoring sockets" on applications written in different languages—you can plug in any vendor's "monitoring plug."

Architecture Design: Modular "LEGO Blocks"

The architecture design of OpenTelemetry .NET feels familiar to an old bird like me who's been折腾 by the Spring ecosystem. It adopts a highly modular design with three core components:

1. OpenTelemetry.API - Defines standard interfaces and abstractions, similar to SLF4J in Java
2. OpenTelemetry.SDK - The actual observability implementation, similar to Logback or Log4j2
3. Various Exporters - Responsible for sending data to different backend systems

The brilliance of this design lies in this: your business code only depends on the API, completely indifferent to which SDK is used underneath or where the data goes. Want to switch from Jaeger to Datadog someday? Just change a few lines of configuration—no need to touch a single line of business code. Isn't this the ultimate dream of "programming to interfaces" we've been chasing all these years?

From a code organization perspective, the project adopts a typical "multi-project solution" structure, with each component independently packaged and published to NuGet. This design allows users to introduce dependencies on-demand, avoiding unnecessary package bloat. For .NET applications that care about startup performance, this is particularly important.

Project Status: Rock-Solid Yet Vibrant

As of today (April 2026), this project has reached Stable status across all three signals (Logs, Metrics, Traces). This means the core interfaces won't have breaking changes, so you can use it with confidence in production environments.

But interestingly, the project team hasn't "laid flat" because of this. They clearly mark which components are still in pre-release status—this transparency deserves a thumbs-up. You know, many open-source projects either hesitate to mark themselves as stable, or stop iterating once they do. OpenTelemetry .NET chose the middle path: core stability, with innovative features continuing to be explored.

3,689 stars is quite impressive for a project focused on infrastructure tooling. More importantly, the maintenance team comes from top-tier companies like New Relic, Grafana Labs, Microsoft, and Splunk. This "big-company co-investment" model ensures the project won't suddenly go abandoned.

Code in Action: From "Zero" to "Observable"

Installation Methods

In the .NET world, the most standard way to introduce a project is through the NuGet package manager. Here are several common installation commands:

## Using .NET CLI (recommended)
dotnet add package OpenTelemetry
dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol

## Or using Package Manager Console (familiar to Visual Studio users)
Install-Package OpenTelemetry
Install-Package OpenTelemetry.Exporter.OpenTelemetryProtocol

## Or directly add references in .csproj file
<PackageReference Include="OpenTelemetry" Version="1.14.0" />
<PackageReference Include="OpenTelemetry.Exporter.OpenTelemetryProtocol" Version="1.14.0" />

If you need to get started quickly in a console application, the recommended minimal dependency combination is the core SDK plus one exporter. For ASP.NET Core applications, you can also introduce the OpenTelemetry.Extensions.Hosting package to simplify configuration.

Quick Start: Basic Tracing in 5 Minutes

Here's the simplest console application example, demonstrating how to send trace data to the console (suitable for debugging):

using System.Diagnostics;
using OpenTelemetry;
using OpenTelemetry.Trace;

public class Program
{
    private static readonly ActivitySource MyActivitySource = new("MyCompany.MyProduct");

    public static void Main()
    {
        using var tracerProvider = Sdk.CreateTracerProviderBuilder()
            .AddSource("MyCompany.MyProduct")
            .AddConsoleExporter()  // Output to console, for debugging
            .Build();

        using var activity = MyActivitySource.StartActivity("SayHello");
        activity?.SetTag("name", "User");
        activity?.SetTag("length", 5);
    }
}

The core logic of this code is very clear:

1. Create an ActivitySource, similar to a Logger instance in logging, used to generate trace data
2. Configure the trace provider through Sdk.CreateTracerProviderBuilder(), adding sources and exporters
3. Use StartActivity() to open a trace Span, adding Tags
4. Use using statements to ensure proper resource disposal (.NET's old tradition)

For production environments, you're more likely to want to send data to an OTLP-compatible backend (such as Jaeger or Tempo):

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddSource("MyCompany.MyProduct")
    .AddOtlpExporter(options =>
    {
        options.Endpoint = new Uri("http://localhost:4317");
    })
    .Build();

Metrics Collection Example: Monitor Your Application Performance

Besides tracing, Metrics are also core to observability. Here's an example of recording request duration and count:

using System.Diagnostics.Metrics;
using OpenTelemetry;
using OpenTelemetry.Metrics;

public class Program
{
    private static readonly Meter MyMeter = new("MyCompany.MyProduct", "1.0");
    private static readonly Counter<long> RequestsCounter = MyMeter.CreateCounter<long>("requests.count");
    private static readonly Histogram<double> RequestDuration = MyMeter.CreateHistogram<double>("request.duration");

    public static void Main()
    {
        using var meterProvider = Sdk.CreateMeterProviderBuilder()
            .AddMeter("MyCompany.MyProduct")
            .AddConsoleExporter()
            .Build();

        RequestsCounter.Add(1, new("method", "GET"), new("endpoint", "/api/users"));
        RequestDuration.Record(0.5, new("method", "GET"), new("endpoint", "/api/users"));
    }
}

Advanced Usage: Custom Processors and Samplers

OpenTelemetry .NET's extensibility design is quite excellent. You can write custom Processors to do additional processing before data export, or implement your own Sampler to control data collection strategies. This is very useful for scenarios where you need to control sampling rates or filter sensitive information in production environments.

// Custom sampler example: only sample a portion of requests
class CustomSampler : Sampler
{
    private readonly double _samplingRate;

    public CustomSampler(double samplingRate)
    {
        _samplingRate = samplingRate;
    }

    public override SamplingResult ShouldSample(in SamplingParameters samplingParameters)
    {
        var shouldSample = Random.Shared.NextDouble() < _samplingRate;
        return new SamplingResult(
            shouldSample ? SamplingDecision.RecordAndSample : SamplingDecision.Drop);
    }
}

// Add to configuration when using
data.TracerProviderBuilder.SetSampler(new CustomSampler(0.1)); // 10% sampling rate

Security & Verification: Digital Signatures and Artifact Attestations

Starting from version 1.10.0, the project introduced a digital signature mechanism, using Sigstore to sign DLLs published to NuGet. From version 1.14.0, GitHub Artifact Attestations were also added. This is an important guarantee for enterprise environments with high security requirements.

The commands to verify signatures are as follows:

## Verify signature using cosign
cosign verify-blob \
    --bundle OpenTelemetry.dll.sigstore.json \
    --certificate-identity "https://github.com/open-telemetry/opentelemetry-dotnet/.github/workflows/publish-packages-1.0.yml@refs/tags/core-1.14.0" \
    --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
    --use-signed-timestamps \
    OpenTelemetry.dll

## Verify artifact attestation using GitHub CLI (1.14.0+)
gh attestation verify --owner open-telemetry .\OpenTelemetry.dll

The introduction of this security mechanism shows that the project team takes supply chain security seriously. After all, observability components typically have high privileges—if tampered with, the consequences would be unthinkable.

Comparison with Other Solutions: Why Choose This?

In the .NET ecosystem, OpenTelemetry isn't the only observability solution. There's Microsoft's own Application Insights, third-party vendors' New Relic Agent, and so on. So why go through the trouble of adopting this standard?

Three core advantages:

1. Standardization - Once integrated, switching backends requires no business code changes, avoiding vendor lock-in
2. Uniformity - Logs, metrics, and traces use the same context propagation mechanism, making troubleshooting twice as effective with half the effort
3. Community Ecosystem - Backed by countless vendors behind CNCF, support won't suddenly be cut off by some vendor (remember Stackdriver's multiple renames?)

Of course, OpenTelemetry comes with its costs: compared to some "out-of-the-box" closed-source solutions, initial configuration is slightly more complex. But for projects that value long-term maintainability, this "technical debt" is worth prepaying.

My (An 8-Year Veteran's) Honest Opinion

To be honest, when I first saw this project, I felt a bit of "aesthetic fatigue"—another observability framework? But digging deeper, I found its design philosophy very pragmatic: not pursuing big and comprehensive, but pursuing standards and stability.

From a code quality perspective, the project's emphasis on test coverage (integrated with CodeCov) and regular security audits (FOSSA scanning) is reassuring. For enterprise applications, this "conservatism" is actually a strength.

If I were to use it, here's my advice:

• New projects - Go straight with OpenTelemetry, no hesitation.
• Legacy projects - Gradual migration, start with either metrics or tracing, optimize while running.
• Mixed tech stack teams - This is the biggest value scenario; unified standards can significantly reduce operational costs.

The only potential "pitfall" might be the scattered documentation. The main README is just an entry point; specific features require looking at detailed documentation in each subdirectory. This might require some patience for newcomers, but considering the project's scale and complexity, this is an understandable design trade-off.

Conclusion: Is It Worth Learning?

If your work involves .NET backend development, or your team is building a microservices architecture with mixed technology stacks, OpenTelemetry .NET is absolutely worth investing time to learn.

It may not dazzle you like some "flashy" new frameworks, but it's precisely this "plain and unadorned" nature that makes it more reliable and stable in production environments. In this era where "observability is a must-have," mastering such a standard tool is also a plus for your career development.

Finally, if you're mainly a Java user like I was before, this project is also a window into understanding the .NET ecosystem. You'll discover: turns out Microsoft is no longer "that Microsoft" from back in the day—they play open source better than anyone.