Span name for http server spans should include http.method.

[gouthamve]

Current spec defines the span name as the route, for example, /users/:userID?.

But having the http.method in the span name helps a lot, imo: GET /users/:userID?.

Prompted by open-telemetry/opentelemetry-go-contrib#3040

[cyrille-leclerc]

I support this proposal as REST architectures rely on the verb (GET, PUT, DELETE) to convey the sense of the action performed on the resource identified by its URI.
GET /users/:userID, PUT /users/:userID and DELETE /users/:userID are completely different operations with completely different code execution paths.
For this reason, I support the idea that the name of an HTTP span should be ${http.method} ${http.route}

[jsuereth]

I'm also supportive of this change.

[trask]

if we make this change, does it makes sense to also change the fallback (when there's no http.route available) from "HTTP {http.method}" to just "{http.method}"?

this would have the nice symmetry:

• "{http.method} {http.route}" if route is available
• "{http.method}" if route is not available

[blumamir]

I support this change too.

It also happens many times that the route is / (just one slash). In these cases, the current span name is just /, and I think changing it to GET / gives context to what we are looking at.

[arielvalentin]

if we make this change, does it makes sense to also change the fallback (when there's no http.route available) from "HTTP {http.method}" to just "{http.method}"?

this would have the nice symmetry:

• "{http.method} {http.route}" if route is available
• "{http.method}" if route is not available

if we make this change, does it makes sense to also change the fallback (when there's no http.route available) from "HTTP {http.method}" to just "{http.method}"?

this would have the nice symmetry:

• "{http.method} {http.route}" if route is available
• "{http.method}" if route is not available

👍🏼 👍🏼 👍🏼 in favor!

[macieyng]

We consider faas handlers servers, but typically they use handler name as span name. How does this specification apply to faas?

• {handler_name} {http.method} {http.route} if route available and {handler_name} {http.method} when route unavailable

OR

• it should ignore handler_name and stick to specification - after all handler_name is commonly passed as a span attribute (faas.invocation_name) and resource attribute(faas.name) - unless I have mixed up something.

I'm currently working on open-telemetry/opentelemetry-python-contrib#1757 and this is something I came across when working on python aws-lambda instrumentation. I would really appreciate clarification in this matter.

[Oberon00]

The term "handler name" for faas is ambiguous, do you mean the name of the handler method in code or the logical FaaS function name? Also, what is faas.invocation_name?

In general, I think the span name is sometimes not 100% clear and this is one such case. I think either the FaaS conventions or the HTTP conventions, if applicable, are valid. In doubt, I would stick to the FaaS conventions, since that is probably the more natural implementation.

[macieyng]

I meant faas.invoked_name (src).

It make sense to apply FaaS conventions in those cases. Thanks!

[trask]

@macieyng if there's still an issue/concern, can you open a new issue so it doesn't get lost? thx