Plans for opt-in OpenTelemetry attribute implementation and configuration?

[matt-hensley]

Opening this against the runtime repo as it covers ASP.NET Core and HttpClient but may have further implications, please let me know if this is the wrong location.

For opt-in OpenTelemetry attributes, what is the strategy for implementation and configuration?

A good example is the http.server.request.duration metric which has two opt-in attributes: server.address and server.port.

As noted in the .NET-specific OTel semantic conventions, these opt-in attributes are not reported and do not have an opt-in mechanism.

It is possible use tag enrichment via IHttpMetricsTagsFeature to add both attributes. Any user interested in opt-in attributes would need to write enrichment code to populate the values.

I am interested if there are plans for the addition of opt-in OpenTelemety attributes, and if consideration has been given to a common opt-in pattern.

[cijothomas]

https://github.com/open-telemetry/opentelemetry-dotnet/issues/3373#issuecomment-1204164425 This maybe a good option to consider.

[cijothomas]

If https://github.com/dotnet/aspnetcore/issues/52439 is not landing in .NET9 timeframe, then probably a good idea to implement something in OTel Instrumentation libraries itself: https://github.com/open-telemetry/opentelemetry-dotnet-contrib/issues/1786

[ericstj]

cc @tarekgh

[tarekgh]

CC @antonfirsov @JamesNK @noahfalk @lmolkova

[tarekgh]

CC @samsp-msft

[JamesNK]

There are other things to configure, such as the list of available HTTP method values in metrics.

This configuration is difficult because I don't think it should be static (yuck), but there also isn't anywhere good to place it. The http handler maybe?

It's not urgent and can be considered based on demand.