Create subcategories for better filtering Kestrel logs

[halter73]

Kestrel logs bad request details using the "Microsoft.AspNetCore.Server.Kestrel" category at the debug level. The reason for the low severity is to reduce the log noise misbehaving clients can create. Here's an example log:

dbug: Microsoft.AspNetCore.Server.Kestrel[17]
      Connection id "0HM6L1I0L7H4A" bad request data: "Invalid request header: 'X-Http-Method : PATCH\x0D\x0A'"
      Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Invalid request header: 'X-Http-Method : PATCH\x0D\x0A'
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpParser`1.ParseHeaders(TRequestHandler handler, SequenceReader`1& reader)
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TakeMessageHeaders(SequenceReader`1& reader, Boolean trailers)
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.ParseRequest(SequenceReader`1& reader)
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest(ReadResult result, Boolean& endConnection)
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequestsAsync[TContext](IHttpApplication`1 application)

This can be a problem when the misbehaving clients are legitimate clients of a production service, and developers want to see more detail about why request are being rejected without enabling all "Microsoft.AspNetCore.Server.Kestrel" debug logs in production which could be overwhelming.

One workaround might be to filter logs by EventID (e.g. don't log debug-level "Microsoft.AspNetCore.Server.Kestrel" logs unless it has EventId(17, "ConnectionBadRequest")). The problem with that is that AddFilter doesn't support this. As of today, you are stuck writing your own ILoggerProvider to get this functionality which is quite complicated.

To make it easier to see details around bad requests without increasing the log severity, I'm proposing a new category for bad request logs. Maybe "Microsoft.AspNetCore.Server.Kestrel.BadRequests". These logs would still be debug-level, but it would be much easier to filter.

If we do this, we'll have to decide whether we duplicate logs to avoid breaking logic depending on bad request logs log being in the "Microsoft.AspNetCore.Server.Kestrel" category. I think duplicate logs are annoying enough we shouldn't do that, but we do need to consider this is technically a breaking change.

[halter73]

This is a good opportunity to split Kestrel logs into multiple subcategories. It doesn't have to just be bad requests and everything else. Here are some potential categories:

1. Microsoft.AspNetCore.Server.Kestrel (current category): ApplicationError, ApplicationNeverCompleted, RequestBodyStart, RequestBodyDrainTimeout, ...
2. Microsoft.AspNetCore.Server.Kestrel.BadRequests: ConnectionBadRequest, RequestBodyMinimumDataRateNotSatisfied, ...
3. Microsoft.AspNetCore.Server.Kestrel.Connections: ConnectionAccepted, ConnectionStart, ConnectionDisconnect, NotAllConnectionsAborted, ...
4. Microsoft.AspNetCore.Server.Kestrel.Http2: Http2FrameReceived, Http2ConnectionError, Http2StreamError, HPackDecodingError, Http2StreamResetAbort, Http2ConnectionClosed, ...
5. Microsoft.AspNetCore.Server.Kestrel.Http3: Http3FrameReceived, Http3ConnectionError, Http3StreamAbort, ...

@davidfowl

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.