Routing, exception and hosting metrics

[JamesNK]

Background and Motivation

This is a collection of useful metrics identified by customers. Combined together

Proposed API

Microsoft.AspNetCore.Routing

routing-match-success

Name	Instrument Type	Unit	Description
routing-match-success	Counter	{count}	Number of requests successfully matched to an endpoint by routing.

Attribute	Type	Description	Examples	Presence
route	string	The matched route	{controller}/{action}/{id?}	Required
fallback	bool	A flag indicating whether the matched route is a fallback route	true	Required

routing-match-failure

Name	Instrument Type	Unit	Description
routing-match-failure	Counter	{count}	Number of requests that failed to match to an endpoint by routing.

Microsoft.AspNetCore.Diagnostic

diagnostics-handler-exception

Name	Instrument Type	Unit	Description
diagnostics-handler-exception	Counter	{count}	Number of request exceptions caught by exception handling middleware.

Attribute	Type	Description	Examples	Presence
exception-name	string	Name of the .NET exception thrown during the request.	Required
result	string	The result of exception handler.	Skipped, Handled, Unhandled, Aborted	Required
handler	string	The name of the .NET type that handled the exception.	MyNamespace.MyCustomExceptionHandler	Present if exception handled by IExceptionHandler or IProblemDetailsService.

Microsoft.AspNetCore.Hosting

http-server-unhandled-requests

Name	Instrument Type	Unit	Description
http-server-unhandled-requests	Counter	{count}	Number of HTTP requests that reached the end of the middleware pipeline without being handled by application code.

Usage Examples

Alternative Designs

Risks

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[halter73]

API Review Notes:

• Is it possible for a matched route to not have a route pattern?
  • Potentially with a custom policy, but it would be extremely rare. We could leave it as an empty string in this case.
• Are there any useful dimensions for failed routing?
  • No. The path has too high of a cardinality.
• What about routing-match-hit and routing-match-miss to avoid failure which may be expected?
• We're not too worried about people thinking failure is bad. It's clear it's only route matching.
• We use "success" and "failure" in the debug logs.
• Could you get multiple diagnostics-handler-exception events for a single exception? One for the IExceptionHandler and IProblemDetailsService.
  • No.
• Is the exception-name the full name of the type?
  • Yes. It's Type.FullName.
• Should we use exception-type instead of exception-name.
  • We already use exception-name for http-server-request-duration counter and other internal metrics use this name.
  • Let's go with consistency.
• Will the developer exception page emit diagnostics-handler-exception?
  • Yes. We don't think there will be an issue where people have both enabled at the same time and want independent counts.
• For consistency with the exception-name the handler uses the full type name.
• Should we go with handler-name for more consistency?
  • We'd like to keep it terse. We did -name on exception-name because of prior art and there are more interpretations that might include things like message.
• What about the http-server-unhandled-requests name?
  • The http-server- prefix is right, since this is when any server hits the terminal 404 middleware.
  • This is done by the UnexpectedRouteReportingMiddleware by some internal partners.
  • http-server-not-found-request might clarify what it means to be unhandled in the usual case, but people would expected it when returning NotFound from a minimal API.
  • http-server-request-reached-pipeline-end explains the implementation better, but it's wordy and more confusing to those who don't know the internals.
  • The description should cover.

API Approved!

Microsoft.AspNetCore.Routing

routing-match-success

Name	Instrument Type	Unit	Description
routing-match-success	Counter	{count}	Number of requests successfully matched to an endpoint by routing.

Attribute	Type	Description	Examples	Presence
route	string	The matched route	{controller}/{action}/{id?}	Required
fallback	bool	A flag indicating whether the matched route is a fallback route	true	Required

routing-match-failure

Name	Instrument Type	Unit	Description
routing-match-failure	Counter	{count}	Number of requests that failed to match to an endpoint by routing.

Microsoft.AspNetCore.Diagnostics

diagnostics-handler-exception

Name	Instrument Type	Unit	Description
diagnostics-handler-exception	Counter	{count}	Number of request exceptions caught by exception handling middleware.

Attribute	Type	Description	Examples	Presence
exception-name	string	Name of the .NET exception thrown during the request.	Required
result	string	The result of exception handler.	Skipped, Handled, Unhandled, Aborted	Required
handler	string	The name of the .NET type that handled the exception.	MyNamespace.MyCustomExceptionHandler	Present if exception handled by IExceptionHandler or IProblemDetailsService.

Microsoft.AspNetCore.Hosting

http-server-unhandled-requests

Name	Instrument Type	Unit	Description
http-server-unhandled-requests	Counter	{count}	Number of HTTP requests that reached the end of the middleware pipeline without being handled by application code.