[net/http] Allows adding custom request atributes to otelhttp metrics

[RangelReale]

Option sample:

otelhttp.WithMetricAttributes(func(params *otelhttp.MetricAttributesParams) []attribute.KeyValue {
	return semconv.HTTPServerAttributesFromHTTPRequest(params.Operation, "", params.Request)
}),

[hanyuancheung]

Pls add a Changelog for this PR. @RangelReale

[codecov[bot]]

Codecov Report

Merging #2748 (82229bf) into main (e439286) will decrease coverage by 5.0%. The diff coverage is 100.0%.

:exclamation: Current head 82229bf differs from pull request most recent head d58de7b. Consider uploading reports for the commit d58de7b to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #2748     +/-   ##
=======================================
- Coverage   79.3%   74.4%   -5.0%     
=======================================
  Files        166     145     -21     
  Lines      10336    6719   -3617     
=======================================
- Hits        8206    5005   -3201     
+ Misses      1996    1566    -430     
- Partials     134     148     +14     

Files Changed	Coverage Δ
instrumentation/net/http/otelhttp/config.go	88.5% <100.0%> (+5.7%)	:arrow_up:
instrumentation/net/http/otelhttp/handler.go	82.2% <100.0%> (-4.8%)	:arrow_down:

... and 99 files with indirect coverage changes

[RangelReale]

This duplicates the functionality already provided by the Labler

Labeler does this at the context level, this PR adds the attributes at initialization level. If I were to do this with Labler, I would need to add a handler for each received context.

[MrAlias]

This duplicates the functionality already provided by the Labler

Labeler does this at the context level, this PR adds the attributes at initialization level. If I were to do this with Labler, I would need to add a handler for each received context.

Each handler receives its own context in the request. A user can just as easily write their own function that accepts that requests and adds their desired attributes based on the known request attributes.

I am not in favor of adding duplicative functionality to the package, it will only serve to confuse users with which one they should use where. If you find something that cannot be achieved with the current labelers, please open an issue to identify the bug and they can be updated or replace.

[RangelReale]

This duplicates the functionality already provided by the Labler

Labeler does this at the context level, this PR adds the attributes at initialization level. If I were to do this with Labler, I would need to add a handler for each received context.

Each handler receives its own context in the request. A user can just as easily write their own function that accepts that requests and adds their desired attributes based on the known request attributes.

I am not in favor of adding duplicative functionality to the package, it will only serve to confuse users with which one they should use where. If you find something that cannot be achieved with the current labelers, please open an issue to identify the bug and they can be updated or replace.

This option was made as a couterpoint to the WithSpanOptions option, which allows setting trace parameters (including a WithAttributes one like this), but we didn't have any function to set metric options, and the only option available for metrics are the attributes, so this was the reasoning.

[MrAlias]

but we didn't have any function to set metric options, and the only option available for metrics are the attributes, so this was the reasoning.

Understood. The reason there are no options to set metric attributes is because the Labler exists. Adding an option to set metric attributes would duplicate functionality, that is why it does not exist.

[pellared]

@RangelReale FYI I added this PR to the OpenTelemetry Go SIG meeting's agenda.

[pellared]

Closing per agreement during SIG meeting. @RangelReale if you want you can create a follow-up issue or even join the SIG meeting to discuss it.