Issues with FaaS semantic conventions (too AWS-specific, faas.id/version unclear)

[Oberon00]

The current FaaS conventions were developed with AWS Lambda in mind and have several issues. All in all, I think they are not GA-ready yet (good thing all semantic conventions are still experimental). At least some of

• Google Cloud Functions
• Google Cloud Run
• Google Firebase Function (?)
• Azure Functions

should also be well-supported by them (except if someone knows that the market share of one of them insignificant?), or they should be moved to an aws (sub-)namespace.

Some issues:

• The faas.id attribute is very nice but it is not clear to me how it applies to other providers. The current note on what to use for Azure (FunctionDirectory) seems wrong, we probably want something like https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules#microsoftweb. For Google Cloud, there seems to be https://cloud.google.com/iam/docs/full-resource-names though I couldn't find how function IDs in particular would look like.
• Even just looking at AWS, the relationship between faas.id, faas.version and faas.invoked_id is not very clear, if you consider that you can call an AWS Lambda by invoking arn:aws:lambda:us-east-1:12345:function:somefunction:somealias which may invoke the function version arn:aws:lambda:us-east-1:12345:function:somefunction:12. Probably faas.invoked_id at the client side should contain the ARN ending in :somefunction:somealias, but what should faas.id contain? And wouldn't it be nice to have the faas.invoked_arn also on the server side? Note that the function name including alias cannot be used as faas.id since the same running instance could be invoked with multiple aliases and faas.id is a resource attribute, so there can only be one.
• faas.version seems to exist in AWS Lambda and Google Cloud Run (revision), but not Google Cloud Functions or Azure Functions (deployment slots are something different, looks like the combination of an alias and a mutable version when compared to AWS Lambda)
• faas.instance, faas.execution: Unclear. These would need per-provider specification on what it is. For example, I could imagine using the request ID on AWS Lambda for faas.execution would make sense.

CC:

• @thisthat (as the original creator of the FaaS conventions)
• @anuraaga (as AWS engineer)
• @reyang (for Azure)
• Is there someone from Google or knowledgeable about the Google products active in the project? If not, we might need to de-prioritize the Google stuff.

[kenfinnigan]

@skonto might have some input too

[anuraaga]

I think faas attributes are generally meant to be supportive - faas is an execution model not anything quite semantic in itself. So it means almost all spans generated by faas will be primarily covered by http, rpc, or messaging conventions. Even for those that don't there is overlap with the code namespace.

Looking at use cases, the big one that comes to mind is measuring cold vs warm start time. I think that is the intent of the instance / execution attributes. That being said, perhaps host or process conventions can actually help cover this without needing additional conventions may simplify things.

If anything seems too cloud specific we should definitely consider moving to cloud provider namespaces, and if nothing happens to be left the faas namespace may not be that necessary.For example, faas.id I actually had some trouble with

https:/open-telemetry/opentelemetry-java/blob/main/sdk-extensions/aws/src/main/java/io/opentelemetry/sdk/extension/aws/trace/SamplingRuleApplier.java#L122

arn is like a holy grail in AWS, every resource has it and knowing the arn can get you there for further debugging all the time. It's obtuse to compute it from other attributes instead of defining aws.arn given its importance. But then faas.id would not be needed for Lambda.

[Oberon00]

Looking at use cases, the big one that comes to mind is measuring cold vs warm start time. I think that is the intent of the instance / execution attributes.

There is also the faas.coldstart span attribute: https:/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/faas.md#incoming-invocations

[Oberon00]

I think faas attributes are generally meant to be supportive - faas is an execution model not anything quite semantic in itself.

The goal of FaaS aka "serverless" is to hide away the server, so it should not semantically matter which host the function runs on. On the other hand, new semantic concepts like that of the "function" (with a name, possibly revisions, ...) is introduced. So I would say, it has to be something semantic otherwise we are not able meaningfully group monitored function invocations, e.g. by "function".

[skonto]

The faas.id attribute is very nice but it is not clear to me how it applies to other providers.

Providing some more context, regarding Google Cloud Functions I see that there are at least four attributes when deploying (same for Cloud run):

• function name
• project id
• region
• versionId

Maybe a combination of the above attributes could be used as the id here, it seems that these define a func uniquely (same for Azure). Execution ids are a separate thing as expected.

faas.version seems to exist in AWS Lambda and Google Cloud Run (revision), but not Google Cloud Functions or Azure Functions

Check this answer for Azure (the api version could be linked to faas there) and the link above for Cloud functions.

Regarding the faas.id mapping issue, this has been raised before here. Not sure if it was answered but my understanding is that the goal was to have aliases as part of the faas.id attribute. That is why there is an effort to move it outside from the resource definition and make in general resource attributes also span attributes.
However this has been marked for post-GA so probably we will have to wait to adjust the context of this discussion anyway.

I think what is missing here to move the work to GA and post-GA, is a doc mapping the faas specification to each provider's implementation (Azure, AWS, Google Cloud). Could be also put directly into the spec as examples.If a vendor does not provide some attribute it is fine as long as spans and metrics make sense and are unambiguous. Also, there are non cloud offerings that run functions on-premise to be considered eg. OCP functions.

[Oberon00]

I created PR #1781 that should address some of the points.

[tigrannajaryan]

@Oberon00 does #1781 fully resolve this issue or there is still work to do?

[Oberon00]

Probably this issue should be closed and a follow-up could be opened to have somebody with actual knowledge of Google Cloud Platform or Azure take another look.