Feature/otel span kind support

[alessandrobologna]

📬 *Issue #945

✍️ *Add OpenTelemetry span kind support to Lambda invocation tracing. This enhancement allows users to specify the span kind (e.g., SERVER, CLIENT) in their Lambda handlers, improving how functions are represented in distributed traces.
In this way:

• Users can set the span kind in their handlers using span.record("otel.kind", "SERVER") or `span.record("otel.kind", "CONSUMER") etc.
• Allows to follow OpenTelemetry semantic conventions for span kind while maintaining backward compatibility (the field can be left empty)

Changes:

• Added otel.kind field to the Lambda invocation span, initialized as field::Empty as per the tracing_opentelemetry docs
• Updated the example in examples/opentelemetry-tracing/main.rsto demonstrate setting the span kind

Please note that since tracing_opentelemetry 0.28.0, they have provided a method to set the status on a span, therefore setting otel.status_code and otel.status_message in advance on the span is not required anymore.

🔏 By submitting this pull request

• I confirm that I've ran cargo +nightly fmt.
• I confirm that I've ran cargo clippy --fix.
• I confirm that I've made a best effort attempt to update all relevant documentation.
• I confirm that my contribution is made under the terms of the Apache 2.0 license.

[maxday]

Thanks for your contribution!
What do you think about using the enum from https://docs.rs/opentelemetry/0.27.0/opentelemetry/trace/enum.SpanKind.html instead of passing an hardcoded string like server?

[alessandrobologna]

@maxday that's really depending on how the tracing_opentelemetry crate handles it. As it is today, it handles string to SpanKind conversion internally: see https://github.com/tokio-rs/tracing-opentelemetry/blob/v0.1.x/src/layer.rs#L443 and https://github.com/tokio-rs/tracing-opentelemetry/blob/v0.1.x/src/layer.rs#L102-L111.

[maxday]

While testing it seems that the "kind" is passed as a integer (enum id I guess)
for instance 4 forproducer "parentSpanId":"0000000000000000","name":"helloooo","kind":4,"startTimeUnixNano":1733334175621925826
It seems that's not what we really want, I think it would be better to see the full name of the kind? (see: https://opentelemetry.io/docs/specs/otel/trace/api/#spankind)

Also not providing any otel.kind in a span results in having kind:1 in the trace which is also not a wanted side effect?WDYT?

[alessandrobologna]

Yes, it's a little bit confusing, but the serialization of SpanKind (an enum) is an int for the specs.
And the 1 value is actually meant to imply "internal", which is the default behavior when it's not specified (see the comment onSPAN_KIND_INTERNAL). So the rust sdk is actually following the standard, by representing it as a number.

[alessandrobologna]

(oh, and the o11y platforms will typically, or at least all those that i tried, convert it back to a string for visualization)

[maxday]

It seems that our CI is red, I've just pushed a PR to fix it, I'll let you know once it gets reviewed/merged so you can rebase from that. Thanks!

[alessandrobologna]

Yes, I saw, no worries

[maxday]

#948 has just been merged and CI is now green, could you please merge main into your branch, this should resolve the failing checks? Thanks!

[alessandrobologna]

Ok, thank you. I think i have done it.

[maxday]

LGTM! Thanks 👍