Do you use OpenTelemetry for observability?

Modern cloud applications are complex distributed systems where a single user request might touch dozens of services. When something breaks, you need comprehensive observability to understand what happened. Traditional monitoring tools often lock you into a specific vendor or don't provide the full picture across your entire stack.

OpenTelemetry is the industry-standard, vendor-neutral framework for collecting telemetry data (traces, metrics, and logs) from your applications. It's backed by the Cloud Native Computing Foundation and has become the dominant observability framework in 2026.

Why OpenTelemetry?

✅ Benefits

• Vendor neutrality - No lock-in. Send telemetry to Application Insights, Datadog, Grafana, or any other backend
• Industry standard - Single set of APIs and conventions across languages and platforms
• Comprehensive coverage - Distributed tracing, metrics, and logs in one framework
• Future-proof - Microsoft, Google, AWS, and other major vendors have adopted OpenTelemetry
• Rich instrumentation - Automatic instrumentation for popular libraries (ASP.NET Core, HttpClient, Entity Framework, etc.)

❌ Problems without OpenTelemetry

• Vendor lock-in with proprietary SDKs
• Inconsistent telemetry across different services
• Difficult to correlate traces across service boundaries
• Hard to switch observability backends when requirements change
• Missing distributed tracing context in complex workflows

OpenTelemetry vs Application Insights

Azure Application Insights has moved to OpenTelemetry-based implementations. Since 2023, the Azure Monitor OpenTelemetry Distro is now the recommended approach for new .NET applications.

Key point: You can use OpenTelemetry APIs and still send data to Application Insights - you get the best of both worlds.

Getting started with OpenTelemetry in .NET

1. Install the package

For ASP.NET Core applications sending to Azure Monitor:

dotnet add package Azure.Monitor.OpenTelemetry.AspNetCore

For other scenarios:

dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Instrumentation.AspNetCore
dotnet add package OpenTelemetry.Instrumentation.Http

2. Configure in Program.cs

var builder = WebApplication.CreateBuilder(args);

// Add OpenTelemetry with Azure Monitor
builder.Services.AddOpenTelemetry()
    .UseAzureMonitor(options =>
    {
        options.ConnectionString = builder.Configuration["ApplicationInsights:ConnectionString"];
    });

var app = builder.Build();

3. Add custom instrumentation

using System.Diagnostics;

public class OrderService
{
    private static readonly ActivitySource ActivitySource = new("MyApp.OrderService");

    public async Task<Order> ProcessOrder(string orderId)
    {
        using var activity = ActivitySource.StartActivity("ProcessOrder");
        activity?.SetTag("order.id", orderId);

        // Your business logic here
        await Task.Delay(100);

        activity?.SetTag("order.status", "completed");
        return new Order { Id = orderId };
    }
}

// Register the activity source in Program.cs
builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource("MyApp.OrderService"));

Best practices

Manage cardinality

High-cardinality data (e.g., user IDs in metric tags) can explode costs and impact performance.

❌ Bad example - High cardinality

// Don't use unique IDs as metric dimensions
meter.CreateCounter<int>("orders.processed")
    .Add(1, new KeyValuePair<string, object?>("user.id", userId)); // ❌ High cardinality!

✅ Good example - Low cardinality

// Use categories instead
meter.CreateCounter<int>("orders.processed")
    .Add(1, new KeyValuePair<string, object?>("user.tier", "premium")); // ✅ Low cardinality

Use semantic conventions

Follow OpenTelemetry semantic conventions for consistent naming.

❌ Bad example - Custom naming

activity?.SetTag("userId", userId); // ❌ Non-standard
activity?.SetTag("dbQuery", query); // ❌ Non-standard

✅ Good example - Semantic conventions

activity?.SetTag("enduser.id", userId); // ✅ Standard convention
activity?.SetTag("db.statement", query); // ✅ Standard convention

Proper lifecycle management

In .NET applications with dependency injection, let DI manage the lifecycle to ensure proper flushing.

❌ Bad example - Manual disposal

// Don't manually create and dispose
var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddSource("MyApp")
    .Build();
// May not flush properly! ❌

✅ Good example - DI-managed

// Let DI handle lifecycle
builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource("MyApp")); // ✅ Properly managed

Hybrid approach

You can send different telemetry to different backends:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource("MyApp")
        .AddAzureMonitorTraceExporter() // Critical traces to App Insights
        .AddOtlpExporter()) // High-volume to self-hosted backend
    .WithMetrics(metrics => metrics
        .AddMeter("MyApp")
        .AddAzureMonitorMetricExporter());

Resources

• OpenTelemetry Documentation
• Azure Monitor OpenTelemetry
• OpenTelemetry .NET Best Practices