Generate FaaS metrics semconv from YAML

[joaopgrassi]

Closes #77, #86

CC @skonto @tylerbenson as previous authors

[joaopgrassi]

This PR still suffers from the issues I described in #86. It's not clear which attributes are to be added to which metrics. There's seems to be a distinction between incoming and outgoing metrics/attributes but the current conventions don't distinguish them. Any people familiar/experienced with this topic that can help?

[trask]

@open-telemetry/lambda-extension-approvers can you review?

[tylerbenson]

Assuming this doesn't introduce anything new and is just moving existing metric semconv to YAML. (That seems to be the case, but difficult to tell.)

[joaopgrassi]

@tylerbenson yes, that was the goal - just move them to yaml.

But these conventions I think are unclear. I opened a separate issue where I described the problems I see #86. Could you please take a look and share your thoughts?

[joaopgrassi]

We discussed in slack together with the initial author, @skonto (than you!) and others about the unclear state of the current FaaS metrics. Here's the summary:

We reached the conclusion that the existing metrics are all "incoming", meaning they are to be recorded by the FaaS instance itself. The problem is that some of the metrics can also be reported by whoever is invoking the FaaS. These are:

• faas.invoke_duration
• faas.errors
• faas.invocations
• faas.timeouts

From @skonto on initial intentions:

the idea afaik was back then to cover scenarios where one function may invoke another (I am coming from the Knative community and we have a serverless framework that targets on premise not that similar to Lambda etc). So when a functions calls another is a client entity anyway.

For the sake of moving forward with this PR, we then agreed to remove the notion of "client-related" metrics and focus only on FaaS metrics. I will create follow up issues to track the rest of the work:

1. Discuss/Add new attributes to the FaaS metrics faas.name, cloud.provider and cloud.region
2. Introduce the "client" metrics under a new namespace faas.client.*. These will have the previously confusing attributes faas.invoked_name, faas.invoked_provider and faas.invoked_region
3. Discuss the necessity of introducing a faas.total_duration metric (which essentially is faas.init_duration + faas.invoke_duration)
4. Discuss the need of the faas.invocations metric. As @lmolkova mentioned in FaaS metrics - Not clear which attributes should be added to each metric #86 (comment) it can be derived from faas.invoke_duration as it's a Histogram metric.

Please upvote/leave comments if you agree with this or not. I will then do the follow ups once we have an agreement.

CC @jsuereth @AlexanderWert @lmolkova @Oberon00 @tylerbenson

[Oberon00]

You may also want to consider dropping the faas.client concept altogether (also from tracing). It seems to only make sense on AWS, and maybe would be better incorporated at https://github.com/open-telemetry/semantic-conventions/blob/main/docs/cloud-providers/aws-sdk.md#aws-service-specific-attributes

[joaopgrassi]

For the "TODO" above, I created separated issues:

• FaaS metrics - Introduce extra attributes to metrics  #233
• FaaS metrics - Should we remove the faas.invocations metric? #234
• FaaS metrics - Should we capture metrics for clients invoking functions? #235