Define FaaS exception event

[trask]

Similar to

• Define HTTP exception events #3414
• Define database and RPC exception events #3426
• Define messaging exception events #3435
• Define gen_ai exception event for client operations #3436

Note: while FaaS does have a client span defined, I'm not convinced it should exist, and the metrics seem to be only about server side, and so I'm aligning the exception event with the metrics and server span.

[github-actions]

This PR contains changes to area(s) that do not have an active SIG/project and will be auto-closed:

• faas

Such changes may be rejected or put on hold until a new SIG/project is established.

Please refer to the Semantic Convention Areas
document to see the current active SIGs and also to learn how to kick start a new one.

[kamphaus]

while FaaS does have a client span defined, I'm not convinced it should exist, and the metrics seem to be only about server side, and so I'm aligning the exception event with the metrics and server span

Isn't a Function as a Service invocation nothing else than a HTTP request or RPC invocation?
Would it make sense to align it with the HTTP and RPC conventions and distinguish client/server events/spans/metrics?

Why would you only track the server-side portion?

[trask]

Why would you only track the server-side portion?

I'm not sure how client instrumentation would know it's calling a FaaS. I looked but couldn't find any examples of FaaS client instrumentation in OpenTelemetry repos.

[thompson-tomo]

Isn't a Function as a Service invocation nothing else than a HTTP request or RPC invocation?
Would it make sense to align it with the HTTP and RPC conventions and distinguish client/server events/spans/metrics?

I agree, the shape/state of the faas telemetry especially tracing has bothered me for a while. I think that tracing of faas should rely on the definitions from the domain of the trigger ie rpc, messaging but adds a group of attributes to describe the function.

Based on that I don't think we need a dedicated faas exception but instead use messaging/rpc exception where appropriate.

I'm not sure how client instrumentation would know it's calling a FaaS. I looked but couldn't find any examples of FaaS client instrumentation in OpenTelemetry repos.

The scenario which comes to mind is https://opentelemetry.io/docs/specs/semconv/faas/aws-lambda/#api-gateway-request-proxy-lambda-tracing-active. With the most likely repo being https://github.com/open-telemetry/opentelemetry-lambda

[trask]

cc @open-telemetry/lambda-extension-approvers

[trask]

Example of client side "invoke": https://docs.aws.amazon.com/lambda/latest/dg/example_lambda_Invoke_section.html

We think this is the only example of client-side knowledge of FaaS client call, and generally FaaS are just treated as HTTP/mesaging/etc endpoints.

So may be ok to say "invocation" = server, and prefix with client. for the rare case, e.g.

• faas.invocation.duration
• faas.client.invocation.duration

Instead of:

• faas.server.invocation.duration
• faas.client.invocation.duration

And if we needed to model the AWS thing, it could be aws.*.

[tylerbenson]

Seems reasonable to me... I agree that excluding server from the name makes sense.

[github-actions]

This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 7 days.