Observability

In modern microservice architectures, a single user request can trigger a cascade of calls across numerous services. When something goes wrong, pinpointing the source of failure or a performance bottleneck becomes a significant challenge. This is where distributed tracing comes in, and OpenTelemetry has emerged as the industry standard for implementing it.

This post will guide you through integrating OpenTelemetry for distributed tracing into your ASP.NET Core applications. We’ll cover the core concepts, set up a basic project, and visualize traces in a backend like Jaeger.

What is Distributed Tracing?

Distributed tracing allows you to follow a single request’s journey from start to finish as it moves through different services. It stitches together individual operations into a unified view, helping you understand the flow, identify latency issues, and debug errors effectively.

Key concepts include:

• Trace: Represents the entire end-to-end path of a request. A trace is a collection of spans.
• Span: Represents a single unit of work or operation within a trace, like an HTTP call or a database query. Each span has a start time, duration, and associated metadata (tags).
• Trace Context: A set of unique identifiers (like a TraceId and SpanId) that are passed between services with each request. This context is what allows the system to link all related spans into a single trace.

Think of it like tracking a package. The trace is the entire journey from the warehouse to …

In modern distributed systems, a single user action can trigger a cascade of requests across multiple microservices. When something goes wrong, tracing that single action through a sea of log entries can feel like finding a needle in a haystack. This is where correlation IDs become an indispensable tool for observability.

A correlation ID is a unique identifier that follows a request from start to finish, even as it hops between services. By including this ID in every log message related to that request, you can easily filter and piece together the entire transaction.

The most effective way to implement this in ASP.NET Core is with custom middleware. Let’s dive into how to build it.

Why Middleware is the Perfect Solution

The ASP.NET Core request pipeline is a series of components, or middleware, that process an HTTP request. By creating our own middleware and placing it early in the pipeline, we can ensure that:

1. Every request is intercepted: No request gets processed without a correlation ID.
2. Logic is centralized: We avoid cluttering our controllers or services with repetitive logging code.
3. It’s set up once: Once the middleware is registered, the correlation ID is available for the entire scope of the request.

This approach is clean, efficient, and aligns perfectly with the ASP.NET Core design philosophy.

Building the Correlation ID Middleware

First, we’ll create the middleware component itself. This class will inspect incoming request headers for an …

Of course. Here is the rewritten blog post, following your style guide and prompt.

Stop Flying Blind: Safely Log EF Core SQL in Production

I remember the incident vividly. P95 latency for our main API shot through the roof overnight. Our logs showed a bunch of slow HTTP requests, but nothing about why they were slow. We were flying blind. After hours of frantic debugging, we found the culprit: a seemingly innocent LINQ query was generating a monster SQL join, causing a full table scan on a massive table.

We had no visibility into what Entity Framework Core was doing. This one burned me, and I promised myself: never again.

Most developers face this. They either accept the black box and pray, or they enable dangerous logging flags that leak sensitive user data. There’s a much better way to see exactly what SQL EF Core is executing in production without compromising security.

TL;DR: Use a custom DbCommandInterceptor to log SQL, execution time, and parameter metadata (but never the values). Correlate logs with a TraceId and use sampling or thresholds to avoid log noise.

The Common Mistakes That’ll Get You Paged at 3 AM

Before we get to the right way, let’s talk about the traps. I’ve seen these “temporary fixes” make their way into production code, and the results are always painful.

• Never use EnableSensitiveDataLogging() in production. I can’t stress this enough. It logs parameter values. That means passwords, personal user info, and …