Tracing for messaging systems: add API to extract context

[lmolkova]

When app receives a message, messaging SDKs extract context from each message and create a processing span/activity from it.

In many cases users may want to do it explicitly

• when they use advanced/non-default concurrency such as in-memory queues, background long-running tasks, reactive programming, manually created threads, etc. E.g. [QUERY] What is the replacement for ServiceBus' ExtractActivity? azure-sdk-for-net#23729
• when they receive in batches and want to trace individual messages
• they don't use handlers and use receive API

Track1 EventHubs and ServiceBus .NET SDKs provided ExtractActivity API to deal with it, but there is no such method in Track2 (any language).

This should be available in .NET and return ActivityContext, in other languages it should be provided through the OpenTelemetry plugin and return SpanContext. As a result, it should work (on par or better than Track1) with existing tracing solutions: Application Insights .NET SDK or OpenTelemetry across all languages.

[andrejpk]

I'm thinking about from recent work using the Java EH client SDK. In that case we were using Akka Streams to process each event using EventProcessorClient/processEvent for individual messages. But since we were spanning threads, in the processEvent callback we called Span.current() and pulling the context from that Span to rehydrate that context on the right thread later.

Keeping the current behavior of creating and activating a Processing span around the processEvent callback makes sense for the (I believe) more common use cases where the user does work on the current thread in the callback.

But for the scenario above, a more efficient approach may be to instead use the more advanced processEventBatch and a method like ExtractActivity to have more control over the start and activation of each processing span.

In my scenario, there was another layer of complexity because we were processing EH messages containing an array of CloudEvents from an EventGrid->EH Subscription, so we had a loop and another layer of CloudEvent Spans that we wanted to link (not parent) to the EH message processing Span, so this is another case where we had to override the more typical processEvent tracing behavior.

[github-actions]

Hi @lmolkova, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.