Updating an ASP.NET Core web application with Serilog to Azure.Monitor.OpenTelemetry.AspNetCore

Hi @ritmo2k ,

Thanks for reaching out.

With OpenTelemetry, you generally do not need to keep a separate custom correlation ID just to connect request logs together. In ASP.NET Core, the value you want to line up with Azure Monitor/Application Insights is the current Activity trace ID. That trace ID is created and flowed using the W3C trace context, and Azure Monitor uses it to correlate requests, dependencies, traces, and logs.

If you want that same correlation value to show up in the console or App Service log stream, the key is to include the current Activity identifiers in your console logging output. For the built-in logging providers, you can enable activity tracking like this:

builder.Logging.Configure(options =>
{
  options.ActivityTrackingOptions =
    ActivityTrackingOptions.TraceId |
    ActivityTrackingOptions.SpanId |
    ActivityTrackingOptions.ParentId;
});

builder.Logging.AddSimpleConsole(options =>
{
  options.IncludeScopes = true;
  options.SingleLine = true;
  options.TimestampFormat = "yyyy-MM-dd HH:mm:ss.fff ";
});

Then configure Azure Monitor OpenTelemetry in the normal way:

builder.Services.AddOpenTelemetry()
  .UseAzureMonitor();

When a request is being processed, Activity.Current.TraceId is the value that works as the correlation ID. That is the value you can use to compare console or log stream output with what you see in Application Insights.

If you are keeping Serilog for console or file formatting, that is also fine. In that case, enrich the log events from Activity.Current and include those properties in the output template. For example, the output template could include TraceId and SpanId:

[{Timestamp:HH:mm:ss} {Level:u3}] trace={TraceId} span={SpanId} {Message:lj}{NewLine}{Exception}

You can do this with a Serilog enricher package, or with a small custom enricher. The important part is that the log stream is just showing what your application writes to stdout/stderr, so if you want the correlation value visible there, it needs to be rendered as part of the log message format.

For local development, I would usually keep the setup as close to production as practical, but only export to Azure Monitor when a connection string is configured. That lets developers use console or file logs locally without needing to send everything to Azure.

For example:

var openTelemetry = builder.Services.AddOpenTelemetry();

if (!string.IsNullOrWhiteSpace(builder.Configuration["APPLICATIONINSIGHTS_CONNECTION_STRING"]))
{
  openTelemetry.UseAzureMonitor();
}

With this approach, local development can still use console or file logging, and the logs can still include the same TraceId and SpanId values. In Azure, when the Application Insights connection string is present, the same OpenTelemetry setup exports the correlated telemetry to Azure Monitor.

So the general pattern I would recommend is to treat the OpenTelemetry trace ID as the correlation ID, render it explicitly in console/file logs when you need to see it, and only keep a separate custom correlation ID if there is a specific business requirement for one, such as exposing a friendly request ID back to users or matching an existing external system.

Hope this helps! If my explanation and the information I provided were helpful, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.