One instrumentation API. Any backend you want. That's the entire point.

Imagine instrumenting your entire application — every log line, every metric, every trace span — specifically for one vendor's monitoring product. It works great, until finance asks you to switch vendors to cut costs, or a client mandates a different tool, or the vendor you picked gets acquired and quietly sunsets the product you built your whole observability story on top of. Now you're not just switching a configuration setting — you're re-instrumenting your entire codebase, because your telemetry code was written directly against one vendor's proprietary SDK.

OpenTelemetry exists specifically to prevent that trap. You instrument your code once, against one open, vendor-neutral standard — and where that telemetry actually goes becomes a configuration decision, not a rewrite.

This is the capstone lesson of Part VII. You'll learn precisely what OpenTelemetry is (and, just as importantly, what it isn't), how it builds on .NET's own existing tracing and metrics primitives rather than replacing them, how to wire it into an ASP.NET Core app with automatic instrumentation for the HTTP, HttpClient, and EF Core calls you already know deeply — and, closing out this whole Part, how the last six lessons connect into one complete, production-ready ASP.NET Core story.

What Is It?

The Simple Explanation

OpenTelemetry (often shortened to "OTel") is an open, vendor-neutral standard for producing and exporting observability data — the logs, metrics, and traces from the previous lesson — in one common, agreed-upon format that many different tools and backends know how to consume. Crucially, OpenTelemetry itself is not a product, a dashboard, or a vendor — it doesn't store your telemetry, visualize it, or alert on it. It's the common language your app speaks, so that where the telemetry ends up is a choice you make separately, and can change later without touching your instrumentation code.

The Technical Definition

OpenTelemetry is a Cloud Native Computing Foundation (CNCF) project defining a standard API, SDK, and wire protocol for telemetry. In .NET, the OpenTelemetry SDK doesn't invent a whole new instrumentation mechanism from scratch — it builds directly on primitives .NET already had before OpenTelemetry adoption became standard practice: System.Diagnostics.Activity for distributed tracing, and System.Diagnostics.Metrics for metrics. The SDK's job is to collect what those built-in APIs already produce and route it, via configurable exporters, to whichever backend(s) you've chosen — Jaeger, Prometheus, Application Insights, Grafana, and many others, including several at once if you want.

Why Does It Exist?

The Problem — Every Vendor Wanted Its Own Instrumentation SDK

Before OpenTelemetry, observability vendors typically shipped their own proprietary instrumentation SDKs. Wanted distributed tracing from Vendor A? You instrumented your code with Vendor A's specific library, calling their specific APIs, in their specific way. Wanted to add metrics from Vendor B, or later switch tracing to Vendor C? You instrumented — and maintained — an entirely separate set of code for each one, scattered through your application. This is exactly the trap from the hook: your telemetry code became permanently coupled to whichever vendor you picked first, making switching (or even just running two backends side by side, which teams often genuinely want during a migration) expensive and disruptive.

The Solution — One Standard API, Many Possible Destinations

OpenTelemetry decouples producing telemetry from consuming it. Your application code instruments against one open, standard API — genuinely vendor-neutral, backed by essentially the entire observability industry as a shared standard, not just one company's product. Where that telemetry actually goes — which backend, or several at once — is purely an exporter configuration choice, made independently of your instrumentation code. Switch backends, and in the common case you change configuration, not application code.

Big Picture

                    YOUR APPLICATION CODE
                            │
        ┌───────────────────┼───────────────────┐
        │                   │                   │
   ILogger<T>          Activity            Meter / Instrument
   (Logs)               (Traces)            (Metrics)
        │                   │                   │
        └───────────────────┼───────────────────┘
                            │
                OpenTelemetry SDK for .NET
           (collects, batches, unifies the three)
                            │
                     EXPORTER (pluggable)
                            │
        ┌───────────────────┼───────────────────┐
        │                   │                   │
    Jaeger /            Prometheus /       Application Insights /
    Grafana Tempo        Grafana            Datadog / others...
      (traces)           (metrics)          (all three, vendor-hosted)

  ↑ Swap or add a backend here — WITHOUT touching your instrumentation code above.

The critical property this diagram is showing: everything above the "OpenTelemetry SDK" line is yours, standard, and stable. Everything below it — the exporter and destination — is configuration, and can change independently.

How It Works

.NET Already Had the Primitives — OTel Wires Them Up

Auto-Instrumentation — Telemetry "For Free"

Simple Example

Wiring OpenTelemetry into an ASP.NET Core app, with auto-instrumentation enabled for the three subsystems you already know well:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOpenTelemetry()
    .ConfigureResource(resource => resource.AddService("OrderApi"))
    .WithTracing(tracing =>
    {
        tracing
            .AddAspNetCoreInstrumentation()   // incoming HTTP requests — automatically
            .AddHttpClientInstrumentation()   // outbound HttpClient calls — automatically
            .AddEntityFrameworkCoreInstrumentation() // EF Core queries — automatically
            .AddOtlpExporter();               // send traces via the OTLP protocol
    })
    .WithMetrics(metrics =>
    {
        metrics
            .AddAspNetCoreInstrumentation()
            .AddHttpClientInstrumentation()
            .AddRuntimeInstrumentation()      // GC, thread pool, and other runtime metrics
            .AddOtlpExporter();
    });

var app = builder.Build();
app.Run();

Nothing in your controllers, endpoint handlers, or services needed to change at all. The moment a request comes in, calls a downstream API via a typed HttpClient, and queries the database via EF Core, three connected spans are created automatically — one for the inbound request, one for the outbound HTTP call, one for the database query — each carrying real timing data, with no manual Activity creation anywhere in that code path.

Real-World Example

Continuing the checkout scenario from the previous lesson: OrderService receives a request, calls PaymentGatewayClient (a typed HttpClient, exactly like the one from Intermediate lesson 130), and queries the database via EF Core to persist the order. With auto-instrumentation wired in as above, this single request automatically produces a trace like:

Trace: POST /api/orders                              340ms
  ├─ ASP.NET Core span (the whole request)             340ms
  │    ├─ HttpClient span → PaymentGatewayClient        210ms  ← the resilience-wrapped call from lesson 267
  │    │      (tags: http.status_code=200, retry attempts, etc.)
  │    └─ EF Core span → INSERT INTO Orders...           45ms
  │           (tags: db.statement, db.system=sqlserver)
  └─ (ASP.NET Core middleware/filter overhead — the rest)

You can add a custom span of your own for a specific piece of business logic worth naming explicitly, using the same Activity primitive OTel already builds on:

private static readonly ActivitySource ActivitySource = new("OrderApi.OrderService");

public async Task<Order> PlaceOrderAsync(OrderRequest request)
{
    using var activity = ActivitySource.StartActivity("CalculateOrderTotal");
    activity?.SetTag("order.itemCount", request.Items.Count);

    var total = CalculateTotal(request.Items); // your own business logic

    activity?.SetTag("order.total", total);
    // ... proceed with the order ...
}

This custom span nests naturally inside the automatically-generated request span — because it's built on the exact same underlying Activity mechanism the auto-instrumentation packages use. Auto-instrumentation gives you the surrounding structure "for free"; manual spans like this let you name and enrich the specific parts of your own business logic worth calling out individually.

Analogy

Under the Hood

Common Confusion

"OpenTelemetry is a monitoring tool, like a dashboard product" — it's the plumbing, not the faucet

This is the single most common misunderstanding, and it's worth being precise about: OpenTelemetry does not give you a UI to look at, does not store your telemetry long-term, and does not alert you when something's wrong. It's the standard that gets your telemetry produced and exported correctly — you still need to point it at an actual backend (open-source or vendor-provided) to actually store, query, visualize, and alert on that data. The vendor-neutrality is precisely what makes this genuinely valuable: the same instrumented application can export to a completely different backend without any code changes.

"OpenTelemetry replaces Activity and Meter" — it's built directly on top of them

Because OTel is often introduced alongside these APIs, it's easy to assume OpenTelemetry invented them or requires you to abandon them for something new. In .NET specifically, the opposite is true: Activity and Meter are .NET's own, pre-existing primitives, and OpenTelemetry's .NET SDK deliberately builds on top of them rather than replacing them — which is exactly why so much telemetry (from ASP.NET Core itself, for instance) is already available "for free" the moment you wire up the SDK, without waiting for every library author to write brand-new, OTel-specific instrumentation from scratch.

Common Mistakes

Mistake 1 — Manually instrumenting everything before checking what auto-instrumentation already covers

Hand-writing custom spans around every ASP.NET Core action, every HttpClient call, and every EF Core query — duplicating work the official instrumentation packages already do correctly.

Enable auto-instrumentation for the well-supported subsystems first (ASP.NET Core, HttpClient, EF Core), and reserve manual Activity/Meter usage for genuinely custom business logic worth naming explicitly.

Mistake 2 — Treating OpenTelemetry setup as "done" with no exporter configured

Adding AddOpenTelemetry() and the instrumentation calls but never configuring an actual exporter — the SDK is faithfully collecting telemetry with nowhere to send it.

Always pair instrumentation with a concrete exporter (OTLP being the standard, portable default) pointed at a real backend, even if that backend is a local development collector initially.

Mistake 3 — Assuming vendor-neutrality means zero migration effort, always

Assuming that because OTel is vendor-neutral, switching backends is always a zero-effort configuration change, regardless of any vendor-specific dashboards, alert rules, or custom attributes built on top of the old backend.

Understand vendor-neutrality accurately: the instrumentation and telemetry format itself is portable; anything you built specifically inside a particular backend's UI (dashboards, alert definitions) generally still needs to be recreated for a new one — the win is avoiding re-instrumentation, not avoiding all migration work everywhere.

When Should I Use It?

• Use OpenTelemetry as the default choice for any real ASP.NET Core service today — it's the modern, standard, actively supported approach across the .NET ecosystem and beyond.
• It earns its value especially strongly once you have more than one service, want the flexibility to change observability backends later, or want to avoid hand-writing tracing/metrics instrumentation for standard subsystems you already get auto-instrumentation for.
• Even a genuinely single-service, single-instance app benefits from wiring it up early — it costs little to enable, and retrofitting observability under production pressure (as the previous lesson stressed) is far harder than building it in from the start.

Mental Model

Key Takeaway

Closing Part VII — Production ASP.NET Core, Start to Finish

This lesson is the capstone not just of this six-lesson cluster, but effectively of this entire Part's journey through what it actually takes to run an ASP.NET Core API in real production, at real scale, with real users depending on it. It's worth stepping back and seeing the whole arc, because no single lesson in this Part tells the complete story on its own — together, they do.

Put together, that's a complete, coherent story: a request enters a well-structured pipeline, is authenticated and authorized correctly, is served efficiently thanks to caching, survives the inevitable hiccup from an external dependency thanks to resilience, and — whether it succeeds or fails — leaves behind exactly the telemetry needed to understand what happened, automatically, without anyone needing to have predicted the specific failure in advance. That's what "production-ready" actually means in practice: not one clever trick, but every one of these concerns handled deliberately, together.

Check Your Understanding

You've reached the capstone of Part VII. Let's confirm you understand both OpenTelemetry itself, and how it closes out everything this Part built.

You've completed Part VII — Production ASP.NET Core. From request pipeline, to security, to performance and resilience, to full observability with OpenTelemetry — you now understand what it genuinely takes to run an ASP.NET Core API in real production, end to end.

dotnetmadeeasy.com — Learn C# and .NET, the right way.