Update HTTP server/client instrumentation span names

[srikanthccv]

Ref: open-telemetry/opentelemetry-specification#3165

HTTP Server

• {http.route} to {http.method} {http.route} (when route is available)
• HTTP {http.method} to {http.method} (when route is not available)

HTTP Client

• HTTP {http.method} to {http.method}

[nhtgl]

Hi 👋 I would love to work on that issue.

[nhtgl]

I wrote down instrumentations that I think should be updated. @srikanthccv does it cover the proper scope?

SERVERS

• asgi
• aws-lambda
• django
• falcon
• flask
• pyramid
• tornado
• wsgi

CLIENTS

• aiohttp
• botocore
• httpx
• requests
• tornado
• urllib
• urllib3

[srikanthccv]

Yes, this sounds good to me.

[nhtgl]

@srikanthccv Django does use _func_name or view_name for span name as fallback if route cannot be resolved. Should it be left as is or should it return just the http method? I lean towards the second option - compliant with specification.

But we could add django specific attribute (django.func_name and django.view_name) like tornado has. Wdyt?

[srikanthccv]

Yes, I think we should try to remain spec compliant.

But we could add django specific attribute (django.func_name and django.view_name)

I don't have a strong opinion on this because it's specific to Django. Maybe we could use some known semantic convention to represent it.

[nhtgl]

Okay, so I've found code.function and code.namespace that could be used in case of django view. The description does seem to fit in this case https://github.com/open-telemetry/opentelemetry-python/blob/main/opentelemetry-semantic-conventions/src/opentelemetry/semconv/trace/__init__.py#L518-L526. Tornado could also comply with it by replacing tornado.handler with one of those two above.

I would make that another issue though coz it's kind of a feature and doesn't fit the current issue.