Add FaaS metrics semantic conventions

[skonto]

Fixes #1013

Changes

Adds metrics and metric labels for functions

I am proposing also changing the faas prefix to func as not all environments are of that kind.
Do I need to discuss that change in a WG meeting?

/cc @kolanos @kenfinnigan @jmacd

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Michael Lavers (2be5b10)
• ✅ Stavros Kontopoulos (8eb62db)

[arminru]

@skonto The namespace/prefix is shared with the trace and resource semantic conventions:
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/faas.md
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/faas.md

If you think changing it would make sense for all three of them, please open a separate issue to discuss this.

[skonto]

@arminru

If you think changing it would make sense for all three of them, please open a separate issue to discuss this.

Yes that is why I set this PR to wip, wanted see if I can do it here, but I agree better to start a discussion first.

[kenfinnigan]

Question for maintainers. What are the expectations around duplication of data, or preferences for where it resides?

Taking a specific example, the faas.invoked_name, etc labels can be found if a Resource with that information is set, correct? Should the specification be preferring the information being set in a Resource and that resource is then attached to the metric, vs labels with identical information being added?

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[skonto]

@arminru gentle ping for review.

[arminru]

Question for maintainers. What are the expectations around duplication of data, or preferences for where it resides?

Taking a specific example, the faas.invoked_name, etc labels can be found if a Resource with that information is set, correct? Should the specification be preferring the information being set in a Resource and that resource is then attached to the metric, vs labels with identical information being added?

@kenfinnigan
Only the following FaaS attributes are defined for the resource: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/faas.md
There is no overlap with the metrics attributes added by this PR as far as I can see.

[arminru]

@open-telemetry/specs-metrics-approvers @reyang @jmacd Could you please take a look?

[kenfinnigan]

Question for maintainers. What are the expectations around duplication of data, or preferences for where it resides?
Taking a specific example, the faas.invoked_name, etc labels can be found if a Resource with that information is set, correct? Should the specification be preferring the information being set in a Resource and that resource is then attached to the metric, vs labels with identical information being added?

@kenfinnigan
Only the following FaaS attributes are defined for the resource: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/faas.md
There is no overlap with the metrics attributes added by this PR as far as I can see.

Would faas.invoked_name here be the same as faas.name on the Resource?

I also wasn't sure whether there would be overlap between faas.invoked_provider here, and cloud.provider on the cloud resource: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/cloud.md

[arminru]

Would faas.invoked_name here be the same as faas.name on the Resource?

I also wasn't sure whether there would be overlap between faas.invoked_provider here, and cloud.provider on the cloud resource: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/cloud.md

@kenfinnigan In the trace semantic conventions things are quite clear since incoming and outgoing invocations are distinguished clearly. In tracing, faas.invoked_name on the client span which is invoking the function would be the same as the faas.name resource attribute on the function being invoked.
I would think that this convention here would follow the same semantics, so a faas.invoked_name label and faas.name resource attribute would only be present on the same process if it is a function itself (faas.name) making an outgoing call to yet another function (faas.invoked_name). It would, however, only have the same value if it would call itself recursively.
Likewise for faas.invoked_provider and cloud.provider. A process running in Google cloud would have cloud.provider=gcp set on its resource and if it had a metric tracking outgoing invocations towards a Lambda function would the label faas.invoked_provider=aws set, for example.

@skonto I think it would make sense to use the same structure as in the trace semantic conventions (https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/faas.md) here as well to make this clearer.

[kenfinnigan]

@arminru Thanks for the detail. The piece I was missing is that metrics could have an equivalent "in process" and "outgoing" as traces, as I'd presumed metrics would only be dealing with the current process only

[skonto]

@arminru Yes I can do that

@kenfinnigan

as I'd presumed metrics would only be dealing with the current process only

I thought the same but then it might be the case that we have a metric that counts invocations from within a process
and may tag the metric with that label explicitly (at least to count all invocations including the failed ones as you cant count anything if the outgoing function fails). I am not stating this is the only way to do this but since this is a spec we probably want to allow such scenarios. Glad we clarified that.

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Michael Lavers (59f6472)
• ✅ Stavros Kontopoulos (9a7b64a, 1382518, 403f848, 5a73102)

[skonto]

@arminru I updated the spec, I dont want to repeat the info at the trace side (added a link), however I changed the structure according to other metrics specs.

[skonto]

Ok I will update this.

[skonto]

@arminru I updated the instrument types, regarding the other update you mention, I suspect the resource labels can be mixed in with the ones in this PR if they have to, I am not sure if I need to reference them though at all.
For example there is no need to reference here: function.name unless I misunderstood something.

[arminru]

@skonto Thanks! Seems like the PR I referred to only added to the FaaS trace semconv but did not touch the attributes which you took over, so no need for updating then. The resource attributes don't have to recited here, yes.

@open-telemetry/specs-metrics-approvers Please take a look.

[arminru]

Thanks, @skonto!

[carlosalberto]

@open-telemetry/specs-metrics-approvers Please take a look and review/approve.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[skonto]

@jmacd gentle ping, can I get merge pls?