Consider allowing to set remote span as parent instead of link when propagating context via RabbitMQ

[josh-romanowski]

Is your feature request related to a problem? Please describe.

In the past we had our own implementation where we implemented distributed tracing with OpenTelemetry over RabbitMQ. So we were really excited to see native support of distributed tracing in the library.

We modeled our spans in a way where the span in the publisher is the parent of the spans created in consumers of a message. And we would like to continue modeling our messages in that way.

While the instrumentation library code here suggests that a parent child relationship is intended in the library, and the implementation here also suggests that at least the possibility to set the extracted remote context as parent, the actual implementation sets the extracted context as link. Also, the current public interface for the ContextExtractor also does not allow to overwrite or configure the OpenTelemetryContextExtractor in a way that would allow setting the extracted context as parent.

Describe the solution you'd like

Instead of adding the remote span as a link to the span in a consumer, add the span as a parent.

Describe alternatives you've considered

If it is not wanted to always set the remote span as a parent by default (see semantic conventions), at least give the possibility to overwrite the ContentExtractor in a way that allows setting either/or both parent and link based on the implementation. This would at least allow us to write our own extractor that sets the span as a parent.

Additional context

Semantic conventions for messaging systems

[lukebakken]

@josh-romanowski a PR would be welcome. Please note that I am releasing version 7 this week.

cc @stebet @lmolkova @martinjt @@lailabougria @cijothomas - thoughts? You all understand OTEL far better than I do.

[lmolkova]

Instead of adding the remote span as a link to the span in a consumer, add the span as a parent.

OTel semantic conventions RECOMMEND link, but it's totally valid to use the same context as a parent and a link

[lukebakken]

I will assume that any changes needed will not affect the public API for RabbitMQ.Client. I've put this in the 7.1.0 milestone for that reason.

[Tornhoof]

Yeah making it configurable would be nice, our own implementation also used a parent-child relation and at least for Grafana it's a break in the flow If you follow the traces. I'd then switch back to parent-child too.

[josh-romanowski]

As it appears the idea of allowing also to use the context as parent resonates, I can have look at making a PR for that.

@lukebakken I would assume making that configurable would at least require a small addition to the API of RabbitMQActivitySource. Would that be okay with you?

And the other question would be how you envision the configuration for that? Thinking about it probably adding a flag for what to use the extracted context for is more appropriate than actually extending ContentExtractor. I would assume that you would always use the same extracted context for both relations. And then rather decide what to use it for. What is your opinion?

Edit: clarifying the third section

[lailabougria]

I tend to agree with @Tornhoof, I would link by default, adhering to the conventions as @lmolkova pointed out, but making it configurable could help users who prefer having the parent-child relationship.

[lmolkova]

setting parent by default (in addition to link) is fine too - that's what we're going to do (or do already) in Azure ServiceBus EventHubs SDKs.

I believe @martinjt has the case for turning parent-child off, but (sorry Martin) he's the only one I heard from who wants links only. At the same time we've got overwhelming feedback to set parent and have one trace.

[lukebakken]

@josh-romanowski a PR would be welcome and yes, now is the time for API changes.