Clarify possible incompatibilities with CloudEvents Distributed Tracing extension

[pyohannes]

CloudEvents is a specification for describing event data in common formats to provide interoperability across services, platforms and systems. It is a CNCF project which is very popular with messaging systems.

CloudEvents provides an extension for Distributed Tracing. This extension specifies an additional channel for context propagation (in addition to context propagation via e. g. HTTP or AMQP). It is not clear whether and how this extension should be used when instrumenting with OpenTelemetry and when utilizing OpenTelemetry semantic conventions.

When stabilizing OpenTelemetry semantic conventions for messaging and HTTP, it needs to be worked out how this CloudEvents extension can be utilized in OpenTelemetry scenarios, and whether it's needed at all.

[joaopgrassi]

Another discussion point that emerged in open-telemetry/opentelemetry-specification#1978 and probably should be captured here or in another issue is: when or whether it makes sense to create a dedicated Span for CloudEvents. The link to the discussion: open-telemetry/opentelemetry-specification#1978 (comment)

[lmolkova]

Would it be fair to say that (int the context or messaging) CloudEvents semconv should be treated as a set of additional attributes that can be applied to existing producer and consumer spans (or links) in addition to messaging attributes.

I.e., if cloud events are used as a carrier in messaging scenarios, messaging producer and consumer spans should have both - messaging and cloud events attributes.

If it's the case, we can probably remove it from the messaging blockers. It'd also make sense to clarify the CloudEvents spec by saying that when the corresponding producer/consumer (or even client/server) spans already exist and can be enriched with CloudEvents attributes, it's recommended to stamp attributes on them.

[pyohannes]

If it's the case, we can probably remove it from the messaging blockers. It'd also make sense to clarify the CloudEvents spec by saying that when the corresponding producer/consumer (or even client/server) spans already exist and can be enriched with CloudEvents attributes, it's recommended to stamp attributes on them.

We should rework the semantic conventions for CloudEvents. Lots of its contents is now covered by the span structure part of messaging semantic conventions ("create" and "process" spans, and links between them). We should remove this duplicate content, and, as @lmolkova suggested, instead just prescribe adding CloudEvents attributes to messaging "create" and "process" spans.

This should make the CloudEvents semantic conventions significantly slimmer.

[lmolkova]

It sounds like we can remove this issue from messaging stability blockers, wdyt @pyohannes @joaopgrassi ?