Consider making faas.id a span attribute instead of a resource attribute

[mateuszrzeszutek]

What are you trying to achieve?

Currently faas.id is a resource attribute. In AWS Lambda functions its value (lambda function ARN) is only available as a property of the AWS lambda context passed to the function, so it's impossible to detect this part just from the environment.

[Oberon00]

Indeed all the FaaS resource attributes also caused problems at Dynatrace, to the point where we patched our SDKs to allow adding resource attributes until before the first span is sent.
So I would agree with changing all/most FaaS attributes to span attributes, or (preferably) allowing them to be set as either resource or span attributes.
From a technical perspective, since we need to flush after each incoming lambda invocation (since we might be suspended afterwards) there is usually a 1:1 ratio of incoming lambda spans and resource messages exported anyway, so we don't even conserve bandwidth on AWS by sending these as resources.

[Oberon00]

CC @thisthat @discostu105

[mateuszrzeszutek]

allowing them to be set as either resource or span attributes.

That would be perfect for all/most cloud/faas attributes. For example, if I wanted to add cloud.account.id on AWS Lambda there is no other way (I think?) then extracting it from the ARN, which again makes it impossible to add it as a resource attribute.

[mateuszrzeszutek]

Can somebody provide insight on how should we deal with the yaml files? Should I just duplicate the attributes in resources & traces?

[Oberon00]

I would say we keep it as resource but add a note in the markdown that they may also be sent as span attributes. We may later want to add support for the generator to mark an attribute as being able to be put on a span.