Disable exception logging for certain path in `UseSerilogRequestLogging`

[lonix1]

Is your feature request related to a problem? Please describe.
Suppose an exception occurs on some path. When using app.UseSerilogRequestLogging() it logs the normal template as well as the exception.

In our exception handler we already log the exception, therefore our logs show the exception twice.

I tried to override the template but that doesn't help:

app.UseSerilogRequestLogging(x => {
  x.MessageTemplate = "HTTP {RequestMethod} {RequestPath} responded {StatusCode} in {Elapsed:0.0000} ms";
});

Describe the solution you'd like
A way to suppress logging the exception, if it occurs on the exception handling path, ie. /Error.

Describe alternatives you've considered
Changing our exception handler, so it doesn't log the exception. But that makes no sense of course, because that's where it belongs..

[nblumhardt]

Hi! Reordering middleware should work here (put the exception handler inside the Serilog request logging).

If you grab the -dev-* packages, your EH middleware can also choose to call IDiagnosticContext.SetException(ex) to include the exception in Serilog's request log under any conditions where you'd like that.

[lonix1]

Thank you for your reply @nblumhardt 😄

If you grab the -dev-* packages ...

I assume you mean the upcoming v6? Looks like an awesome change, but I think I'll wait for it to be released (any timeline on that?)

put the exception handler inside the Serilog request logging

I'm a little confused, the order is:

// ...
if (app.Environment.IsProduction()) app.UseExceptionHandler("/Error");
// ...
app.UseSerilogRequestLogging();
// ...

Unsure what you meant by putting one in the other?

[nblumhardt]

Hi @lonix1 - no, no timeline just yet.

When middleware is added to app, things added from "outside" to "inside" - i.e. requests will hit your EH middleware, which will forward on to the Serilog middleware. Reversing the order of Use...() calls will reverse this.

[lonix1]

Oooooh... 😄 I thought you meant I should include the one in a lambda inside the other somehow. 😕

Yes now it makes sense.

For anyone else with this double logging issue, here is the solution:

app.UseSerilogRequestLogging();
if (app.Environment.IsProduction()) app.UseExceptionHandler("/Error");

Remember that the error here is logged when the response is travelling UP the pipeline. So it hits the exception handling middleware before the serilog middleware (and so only one log is written, because the exception handling middleware writes the response and terminates the pipeline).

[lonix1]

Oh no I found a problem with that solution.

• The first middleware should be the exception handler
• But then UseSerilogRequestLogging() will double-log as explained above
• So the solution was UseSerilogRequestLogging() and then UseExceptionHandler()

But that leads to another problem:

app.UseSerilogRequestLogging();
app.UseExceptionHandler("/Error");
// ....other middleware
app.UseStaticFiles();
// ....other middleware

Now serilog logs everything, including static assets. And moving UseStaticFiles up isn't sensible as it must come after the exception handling.

There does not seem a way around this, I think? So the idea in the OP is still valid.

[cocowalla]

@lonix1

There does not seem a way around this, I think?

You can configure Serilog's request logging to ignore certain paths, such as health check endpoints and static assets.

There's a good example here. In the example it ignores health check endpoints, but you can just as easily ignore paths for static assets too. For example, the IsHealthCheckEndpoint method could be changed to something like (freestyled, so syntax may not be 100%):

private static bool IsIgnorePath(HttpContext ctx)
{
    string[] ignorePaths= { "/health/", "/img/", "/js/", "/lib/", "/css/", "/fonts/" };

    var endpoint = ctx.GetEndpoint();

    if (endpoint == null)
        return false;

    var path = endpoint.DisplayName;

    return ignorePaths.Any(x => path.StartWith(x));
}

[lonix1]

Thanks @cocowalla that really helped me!

For anyone who needs it, my working code:

private static bool IsIgnoredPath(HttpContext ctx)
{
  string[] ignoredPaths = {
    "/img/", "/js/", "/lib/", "/css/", "/fonts/",         // from ~wwwroot/
    "/favicon.ico",                                       // from /
    "/healthz/", "/health/"                               // health checks
  };

  var path = ctx.Request.Path.Value;
  return path != null && ignoredPaths.Any(x => path.StartsWith(x));
}

One thing though - I can't help but feel that this is a very heavy operation to do for every request. That said I'm unsure if it's possible to improve the perf for this.

[cocowalla]

@lonix1

One thing though - I can't help but feel that this is a very heavy operation to do for every request. That said I'm unsure if it's possible to improve the perf for this.

I'd move ignoredPaths to a static field, to avoid allocating it on every request. Aside from that, it's only checking if the path starts with some string, which is barely even a rounding error compared to the other work done for each request 😄

You can profile if it you're concerned, or maybe use a loop instead of linq.

[lonix1]

@cocowalla Those are good tips I'm going to do that, thanks!

In the question above, I requested a way for the library to exclude logging certain paths. But after our discussion it seems there would be no magic improvement by moving the filtering (and perf tricks) from my codebase to the library - is my suspicion correct? (...do you agree @nblumhardt?)