Collect basic HTTP metrics - response time and requests per second

[alanwest]

Collect HTTP repsonse time and RPS metrics for relevant frameworks/libraries:

• ASP.NET Core
• HttpClient
• Grpc.Net.Client
• ASP.NET

High-level requirements:

• Metrics should be able to be collected irrespective of whether tracing has been enabled.
• If tracing is enabled, sampling should have no impact on the collection of metrics.
• Metric and label names should follow the semantic conventions.

[cijothomas]

linking our Python friends doing similar: open-telemetry/opentelemetry-python#1116

[dv42]

Current spec for http metrics defines only http.server.duration and http.server.active_requests.

I have few questions:

1. Request per second is definitely a useful metric to collect. Can opentelemetry-dotnet have metrics that are not defined in the spec?
2. Metrics such as current-requests, requests-per-second and others exist in Microsoft.AspNetCore.Hosting event counters https://docs.microsoft.com/en-us/dotnet/core/diagnostics/available-counters#microsoftaspnetcorehosting-counters. It's possible to integrate with EventCounters, however they don't provide breakdown per tag. Can you clarify whether tags must be present for http.server.active_requests metric?
   Kind of

http_server_active_requests_count 50
vs
http_server_active_requests_count{method="GET"} 30
http_server_active_requests_count{method="POST"} 20

[cijothomas]

Request per second is definitely a useful metric to collect.

Rate (request/sec) can be calculated from the backend. Only SUM (i.e count of total requests) need to be sent from the SDK, and rate can be calculated in backends.

Can opentelemetry-dotnet have metrics that are not defined in the spec?

Not likely, especially for metrics, as the spec is not yet stable, and very minimal semantic conventions exists, and we'll want to wait for things to stabilize a bit more. (note that all the instrumentation libraries are currently non-stable, due to the semantic conventions being non-stable)

[cijothomas]

Can you clarify whether tags must be present for http.server.active_requests metric?

If the semantic conventions says tags must be present, then yes. User can drop tags (using the concept of Metric Views), but there exists no ability (today) to add tags later. So instrumentations would likely need to provide all the tags, and users can drop some of them, if they don't want it.

[cijothomas]

Closing this as the basic support is already added. More specific issues are already opened covering additional libraries like grpc.