Clarify FaaS span name

[lmolkova]

Reading

semantic-conventions/docs/faas/faas-spans.md

Line 35 in fa19325

Span `name` should be set to the function name being executed. Depending on the value of the `faas.trigger` attribute, additional attributes MUST be set. For example, an `http` trigger SHOULD follow the [HTTP Server semantic conventions](/docs/http/http-spans.md#http-server-semantic-conventions). For more information, refer to the [Function Trigger Type](#function-trigger-type) section.

and

semantic-conventions/docs/faas/faas-spans.md

Line 276 in fa19325

The function responsibility is to provide an answer to an inbound HTTP request. The `faas` span SHOULD follow the recommendations described in the [HTTP Server semantic conventions](/docs/http/http-spans.md#http-server-semantic-conventions).

It's not clear if the span name should be a function name or, according to HTTP semconv, {method} {route}.

Given that function can be called over HTTP using different methods, it makes sense to use HTTP server span name, but presence of route is not guaranteed.

Perhaps, the best approach would be to report HTTP function span name as {method} {function name} and route, if available, would remain as an attribute.

[trask]

cc @open-telemetry/lambda-extension-approvers

[stebet]

I'd rather see a clear distinction rather than mixing FaaS and HTTP semantics if we'd mix the {method} {function name} in the span name.

Either have it just the {function name} or {http method} {http route} if the http route is available. The span will always contain the faas.name attribute so the function name is always easily found.

Personally I'd like to have the HTTP Server span semantics apply when faas.trigger is HTTP but that's just a personal opinion.

[serkan-ozal]

As far as I see in the docs, using function name in span name is expressed with "SHOULD", not "MUST".

Span name should be set to the function name being executed.

and here

It is also highly likely that Span name will contain the function name (e.g. for Span displaying purposes), but it is not guaranteed (since it is a weaker "SHOULD" requirement)

So, this got me thinking like:

• For http triggers, span names should be in the {method} {target} format where {target} is optional. {target} is represented by the route of Lambda HTTP server spans. If there is no (low-cardinality) {target} available, span names SHOULD just be {method}: https://github.com/open-telemetry/semantic-conventions/blob/fa19325ac9942c0e5a82334469f17516fc4209dd/docs/http/http-spans.md#name
• For the rest, span name must be the {function name} which is always available

So in summary, for Lambda span names, my opinion is

• for http triggers {method} {route} or {method} if {route} is not available
• for the rest, {function name}