HTTP client metrics: url.scheme should be opt-in, server.port should be required

[lmolkova]

Description

OTel HTTP semconv made the last-minute change open-telemetry/semantic-conventions#459 before stability and now HTTP client metrics are not fully aligned with the spec (sorry).

Even though it's a pretty minor difference it'd be nice to align with the OTel spec at some point.

Reproduction Steps

N/A

Expected behavior

• url.scheme is now opt-in, so should be set when explicitly enabled (or not set at all)
• server.port should be set even when it has a default value

Actual behavior

scheme is always set, port is set when not default.

runtime/src/libraries/System.Net.Http/src/System/Net/Http/Metrics/MetricsHandler.cs

Lines 192 to 198 in 33d7f98

	tags.Add("url.scheme", requestUri.Scheme);
	tags.Add("server.address", requestUri.Host);
	// Add port tag when not the default value for the current scheme
	if (!requestUri.IsDefaultPort)
	{
	tags.Add("server.port", requestUri.Port);
	}

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

OTel HTTP semconv made the last-minute change open-telemetry/semantic-conventions#459 before stability and now HTTP client metrics are not fully aligned with the spec (sorry).

Even though it's a pretty minor difference it'd be nice to align with the OTel spec at some point.

Reproduction Steps

N/A

Expected behavior

• url.scheme is now opt-in, so should be set when explicitly enabled (or not set at all)
• server.port should be set even when it has a default value

Actual behavior

scheme is always set, port is set when not default.

runtime/src/libraries/System.Net.Http/src/System/Net/Http/Metrics/MetricsHandler.cs

Lines 192 to 198 in 33d7f98

	tags.Add("url.scheme", requestUri.Scheme);
	tags.Add("server.address", requestUri.Host);
	// Add port tag when not the default value for the current scheme
	if (!requestUri.IsDefaultPort)
	{
	tags.Add("server.port", requestUri.Port);
	}

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	lmolkova
Assignees:	-
Labels:	area-System.Net.Http, untriaged
Milestone:	-

[antonfirsov]

The current state (having a redundant scheme tag, not reporting default ports) doesn't actively hurt users from a practical POV. Given it's such a minor aspect, I wonder if maintaining maximum standard-compatibility is worth the burden of a breaking change where we may need to implement a compatibility switch, adding complexity to the code. @noahfalk what's your take on this?

[antonfirsov]

Triage: adding this to 9.0 for decision making, and potential fixing (see comment above).

[antonfirsov]

Related: #103302. Opt-in attributes likely need an API addition. Punting this to .NET 10.

[lmolkova]

@antonfirsov

would it be possible to report server.port (and don't change anything for scheme)? It would not require API changes, it does not seem to have any downsides (telemetry volume is the same, not breaking) and would align .NET metrics with OTel better.

[antonfirsov]

I was confused, since I was looking at the wrong metrics. We should add server.port.