Allow filtering when collecting standard ASP.NET Core request metrics

[nahk-ivanov]

Feature Request

Is your feature request related to a problem?

When you add ASP.NET core metrics instrumentation (MeterProviderBuilder.AddAspNetCoreInstrumentation()) it will start collecting request metrics (just the duration at this point). While there are no issues with that, and it is exactly what you would want, there could be platform/infrastructure requests that you are not interested in. For example, if you expose health check APIs, then health check endpoint will be constantly queried by your external monitoring software. Hence, right after enabling standard ASP.NET Core metrics instrumentation, you will immediately get hundreds of requests counted.

Describe the solution you'd like:

We already support filtering in the trace instrumentation code path, where custom filter delegate can be applied to determine whether activities for the given request should be traced or not. I'd suggest we use the same configuration for the metrics code path.

Describe alternatives you've considered.

We could perhaps suggest consumers to filter out metrics on the other end, after collection, based on the http.target attribute, but this results in inconsistent APIs between traces and metrics, and it is also beneficial to reduce telemetry traffic by not emitting unnecessary events to begin with.

Additionally, for gRPC health checks currently we don't log http.target (another issue), so it becomes impossible altogether.

[vishweshbankwar]

open-telemetry/opentelemetry-dotnet-contrib#1765