Make requests span attributes available to samplers for http instrumentations

[lzchen]

Like #931, we should do this for all http instrumentations/

• opentelemetry-instrumentation-urllib3 #937
• opentelemetry-instrumentation-urllib #938
• opentelemetry-instrumentation-aiohttp-client #939
• opentelemetry-instrumentation-django #943
• opentelemetry-instrumentation-httpx #946
• opentelemetry-instrumentation-wsgi #945
• opentelemetry-instrumentation-tornado #944

From spec

[srikanthccv]

@codeboten this should supported for the http server instrumentations also right?

[nstawski]

I would like to take this issue.

[lzchen]

@nstawski
Feel free to comment on the instrumentation issues so we can assign them individually.

[cheempz]

@lzchen @srikanthccv could you confirm that this issue can be understood as "Make HTTP span attributes available to samplers", i.e. would apply to both Client and Server attributes that have been called out by the semantic conventions for HTTP spans to be available at sampling time:

Common

Following attributes MUST be provided at span creation time (when provided at all), so they can be considered for sampling decisions:

http.method

Client

Following attributes MUST be provided at span creation time (when provided at all), so they can be considered for sampling decisions:

http.url
net.peer.name
net.peer.port

Server

Following attributes MUST be provided at span creation time (when provided at all), so they can be considered for sampling decisions:

http.target
http.scheme
net.host.name
net.host.port

This is something we're grappling with and would really help our approach to get a confirmation. Thanks!

[srikanthccv]

could you confirm that this issue can be understood as "Make HTTP span attributes available to samplers", i.e. would apply to both Client and Server attributes that have been called out by the semantic conventions for HTTP spans to be available at sampling time:

Yes, the issue description confirms it as there are both HTTP client and server instrumentations listed.

[cheempz]

@nstawski is this still on your radar? We'd love to see these server instrumentation changes!

[nstawski]

It is. I am out on maternity leave until end of April and can pick this up once I am back. Let me know if the timing works.

…

On Wed, Mar 22, 2023 at 12:57 Lin Lin ***@***.***> wrote: @nstawski <https://github.com/nstawski> is this still on your radar? We'd love to see these server instrumentation changes! — Reply to this email directly, view it on GitHub <#936 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAERYZNXQL6LKZVWFWP6IYTW5NKTFANCNFSM5PVGHBJA> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[cheempz]

It is. I am out on maternity leave until end of April and can pick this up once I am back. Let me know if the timing works.

That would be fantastic @nstawski, thank you :)

[tammy-baylis-swi]

Could we add an additional issue for opentelemetry-instrumentation-asgi? I'd be happy to take that one.

[tammy-baylis-swi]

Hi again, could we add another issue for opentelemetry-instrumentation-flask? I'd like to take that one too. The change is probably similar to the recent Django update.