add OTEL_PYTHON_HTTP_SERVER_REQUEST_DURATION_SERVER_ATTRIBUTES_ENABLED flag

[zeitlinger]

Description

add

• OTEL_PYTHON_HTTP_SERVER_REQUEST_DURATION_SERVER_ATTRIBUTES_ENABLED flag to add server.address and server.port for http.server.request.duration - which are opt-in
• OTEL_PYTHON_HTTP_SERVER_ACTIVE_REQUESTS_COUNT_SERVER_ATTRIBUTES_ENABLED - flag to add server.address and server.port for http.server.active_requests - also opt-in

This env var does not exist for any other language so far.

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How Has This Been Tested?

tests included in this PR

Does This PR Require a Core Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[zeitlinger]

@xrmx can you check again?

[emdneto]

Thanks for working on this one. Left some comments

[emdneto]

We don't need to run this for all instrumentation migrated to new semconv, right? because not every instrumentation has metrics implemented. Wdyt we have a way to explicitly initialize this per instrumentation we want to support the opt-in attributes?

[zeitlinger]

this field is only used for metrics here - maybe rename the field?

https://github.com/zeitlinger/opentelemetry-python-contrib/blob/http-metrics-server-arributes/opentelemetry-instrumentation/src/opentelemetry/instrumentation/_semconv.py#L223

[lzchen]

+1 to supporting this individually per instrumentation. _OpenTelemetrySemanticConventionStability should only be used for semantic convention migration. We do not want to mix this functionality with semantic conventions.

[zeitlinger]

is this going in the right direction?

https://github.com/zeitlinger/opentelemetry-python-contrib/compare/http-metrics-server-arributes...zeitlinger:opentelemetry-python-contrib:http-metrics-server-arributes-asgi-trial?expand=1

[lzchen]

@zeitlinger

Yeah you mostly like don't need to store the config as part of the global _OpenTelemetrySemanticConventionStability . I think you can store the config information in each instrumentation instance themselves when creating them. You can then have a static set of attributes with the one without the flag enabled and one with the flag enabled.

[emdneto]

I'm sympathetic to the @lzchen approach. With that we can be more selective in which instrumentation we want to support to opt-in attributes

[zeitlinger]

ok - changed now 😄

[zeitlinger]

@emdneto please have another look 😄

[zeitlinger]

feedback from SIG meeting

• Should not add new environment variables - opens up too many possibilities (and file config will take care of that)
• But it should be possible to do programmatically (or a PR to allow this would be welcome)

[xrmx]

Maybe I am late but would adding a single environment variable that takes a list of additional attributes to export would be more acceptable? The caveat would be to require specifying the accepted literals with types so at least it's clear what the code supports.
I understand the concern for avoiding too many environment variables but I'm sympathetic to the auto-instrumentation cause 😅

[emdneto]

@xrmx That's the suggestion I made at SIG yesterday. I don't know if my explanation was very clear, but we ended up discussing and agreed to do that per instrumentation using the kwargs at the instrument level.

[lzchen]

@xrmx

I'm open to having a separate discussion about what efforts we should make for auto instrumentation to not block this PR. Seems like we have enough interest for autoinstrumentation that we should definitely do an audit of it.

[lzchen]

Would you be able to add tests for django, asgi and wsgi as well?

[lzchen]

Blocking until we remove env var mechanism.