Override fields.RequestId in ElasticSearch logs from ASP.NET Core app

Question

I have a simple ASP.NET Core console app with Serilog logging which writes logs to ElasticSearch:

private static void ConfigureLogging(bool isTestEnvironment)
{
    var configuration = new ConfigurationBuilder()
        .AddAppSettingsConfig()
        .Build();

    var loggerConfiguration = new LoggerConfiguration()
        .Enrich.FromLogContext()
        .WriteTo.Debug()
        .WriteTo.Console()
        .WriteTo.Elasticsearch(
            new ElasticsearchSinkOptions(new Uri(configuration["ElasticConfiguration:Uri"]))
            {
                AutoRegisterTemplate = true,
                IndexFormat = $"sample-{DateTime.UtcNow:yyyy-MM-dd}"
            })
        .ReadFrom.Configuration(configuration);
    
    Log.Logger = loggerConfiguration.CreateLogger();
}

And I have a controller with this method:

[HttpPost(nameof(AnalyzeUpdatedBug))]
public async Task<ActionResult> AnalyzeUpdatedBug(WiUpdatedChangePayload payload)

When I run the app and make request to this endpoint, I get logs in ElasticSearch like this:

As you can see there are a lot of fields. properties. But I'm interested in fields.RequestId. It's always the same and from what I've learned on the web it's OK for Kestrel server running as simple console app. But as far as I know we can use middleware to set HttpContext.TraceIdentifier and it will be used as RequestId. So I've added simple middleware on building the app:

app.Use(async (context, next) =>
{
    context.TraceIdentifier = Guid.NewGuid().ToString();
    await next();
});

But it didn't change anything. So my questions are:

1. Where fields.RequestId in ElasticSearch logs comes from? How ASP.NET Core app sets it?
2. How can I override this value?

Answer 1

Where fields.RequestId in ElasticSearch logs comes from? How ASP.NET Core app sets it?

Does this answer good enough ?

How can I override this value?

IMO, I don't think we should, at least the complicate interfering default logging scope HostingApplicationDiagnostics isn't a good idea at all. Instead, I saw we just need something to propagate the request and it should be simple and let us control it completely (who know if the logging mechanism have some breaking change in the future?)

So instead, how about making our own CorrelationId ?. Something like

app.Use(async (context, next) =>
{
    using (LogContext.PushProperty("XCorrelationId", Guid.NewGuid().ToString()))
    {
        // Place a try-catch here if the correlation was importance with exception.
        await next();
    }
});

Very simple way, completely control by us, not dependence on framework versions.