Add diagnostics exception handling metrics

[JamesNK]

Fixes #48625

Adds a new meter and counter. The counter is used by developer exception middleware and exception handler middleware.

Result of handler:

• Aborted - Error occurred because the request was aborted (OperationCanceledException + RequestAborted.IsCancellationRequested)
• Skipped - Response has already started. Middleware can't do anything with the response so skips doing anything.
• Handled
  • ExceptionHandlerMiddleware has some interesting rules here. An exception is considered handled if an IExceptionHandler returns true, IProblemDetailsService returns true, or the status code is anything other than 404. If an IExceptionHandler or IProblemDetailsService return true then the type name is set for the handler tag.
  • DeveloperExceptionMiddleware never reports exceptions it catches as handled
• Unhandled - All of the above are false.

Note: The exception-name is still enriched onto the main HTTP request counter. Other detail (result, handler) is only available on the new counter.

[JamesNK]

cc @geeknoid @tekian

[JamesNK]

I hate public middleware. We end up having to screw around with constructors and DI.

Any objection to creating an issue to make them obsolete and eventually remove them?

[mitchdenny]

I guess it means we only need to worry about API compat on AddX and UseX extension methods that might exist for each middleware.

[Tratcher]

Yes obsolete them as Error and make them throw, but we've about given up removing APIs due to binary compat.

[JamesNK]

I guess it means we only need to worry about API compat on AddX and UseX extension methods that might exist for each middleware.

Yes. The important thing is the constructor isn't public. It is easy to modify dependencies.

[Tratcher]

Handled? I guess not since it was not handled by the app, just default logic.

[JamesNK]

I put Unhandled here because it's literally right below a diagnostic event that reports the exception as unhandled:

aspnetcore/src/Middleware/Diagnostics/src/DeveloperExceptionPage/DeveloperExceptionPageMiddlewareImpl.cs

Lines 156 to 160 in 6575b28

	const string eventName = "Microsoft.AspNetCore.Diagnostics.UnhandledException";
	if (_diagnosticSource.IsEnabled(eventName))
	{
	WriteDiagnosticEvent(_diagnosticSource, eventName, new { httpContext = context, exception = ex });
	}

[Tratcher]

Not needed if you make the public middleware constructor throw.

[JamesNK]

It's not a big deal to add this.

Making the public middleware ctor throw would require breaking change process. I'd prefer to leave it working and go with obsoleting and eventually removing it. Less disruptive.

[JamesNK]

API review: #48670

[ghost]

@JamesNK, this change will be considered for inclusion in the blog post for the release it'll ship in. Nice work!

Please ensure that the original comment in this thread contains a clear explanation of what the change does, why it's important (what problem does it solve?), and, if relevant, include things like code samples and/or performance numbers.

This content may not be exactly what goes into the blog post, but it will help the team putting together the announcement.

Thanks!