Instrumentation via OpenTelemetry Integration

In this lesson, you will learn how to standardize performance telemetry across your microservices ecosystem using the OpenTelemetry (OTel) framework.

Standardizing Telemetry with OpenTelemetry

When managing a fleet of microservices, individual logging strategies often lead to siloed data that is difficult to correlate. OpenTelemetry provides a vendor-agnostic specification that allows you to collect traces, metrics, and logs in a unified format, ensuring that your performance data remains consistent as it travels across service boundaries.

By integrating OpenTelemetry into your C# services, you move away from proprietary SDKs and toward a standardized telemetry pipeline. The core of this integration involves the OpenTelemetry.Extensions.Hosting package, which hooks directly into your service’s dependency injection container to automatically collect data from ActivitySource instances—the same source you previously used for tracing execution time.

Implementing the Standardized Provider

To standardize your reporting, you configure an OpenTelemetry builder in your Program.cs. This acts as the single source of truth for how telemetry is exported from your application:

using OpenTelemetry.Trace;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOpenTelemetry()
    .WithTracing(tracerProviderBuilder =>
    {
        tracerProviderBuilder
            .AddSource("MyMicroservice.ActivitySource")
            .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("OrderProcessor"))
            .AddAspNetCoreInstrumentation() // Standardizes incoming HTTP metrics
            .AddHttpClientInstrumentation() // Standardizes outgoing dependencies
            .AddOtlpExporter();            // Exports to a collector in OTLP format
    });

By adding AddAspNetCoreInstrumentation and AddHttpClientInstrumentation, you ensure that every microservice in your stack reports latency, status codes, and trace IDs using the same naming conventions. This eliminates the "babel" problem where different services report the same event using different schema keys. When you deploy this pattern, you gain the ability to visualize the entire lifecycle of a request as it passes through your system, regardless of which team maintains which specific service.

Key Takeaway: OpenTelemetry standardizes your diagnostic data schema, allowing you to correlate traces and metrics seamlessly across a distributed microservice architecture using a unified exporter.