[FEATURE REQ] ServiceBus receiver is not traced

[vyhid]

Query/Question
I use Service Bus in my project and when tried to instrument my code with OpenTelemetry noticed that context is not propagated when an async client is used. So I tried to look at the code and noticed that ServiceBusReceiverAsyncClient has TracerProvider but it's unused. Is this intentional for some reason or a bug?

Why is this not a Bug or a feature Request?
It might be a bug but it's easier to reference it from the code perspective

Setup (please complete the following information if applicable):

• OS: Windows
• IDE: e.g. IntelliJ
• Library/Libraries: com.azure:azure-messaging-servicebus:7.5.0

[joshfree]

@lmolkova could you please follow up?

[lmolkova]

@vyhid thanks for reporting it!

Did you follow https://docs.microsoft.com/en-us/azure/developer/java/sdk/tracing to enable Azure SDK tracing ?

Can you please provide a small repro app? I'm specifically interested in

• whether you use opentelemetry agent or Azure Monitor agent?
• otherwise:
  • how did you configure OpenTelemetry?
  • do you pass context explicitly?

[vyhid]

@lmolkova

here is the simple app: https://github.com/vyhid/sb-otel-instrumentation
I use the OpenTelemetry agent with Tracing Azure SDK https://docs.microsoft.com/en-us/azure/developer/java/sdk/tracing#tracing-azure-sdk-calls-with-opentelemetry-agent-of-sdk-preview
and I don't pass context directly

[lmolkova]

@vyhid I'm sorry it took me so long to get back to you. Thanks for providing the repro app!

So the problem is that we don't yet instrument receive call - we only instrument ServiceBus Processor, hence you never see anything from receiver and context is not propagated.

Do I understand correctly you don't use processor?

If so, can I suggest some manual steps that can help to instrument receive operation?
Here's the code:

1. set up tracer and context extractor

private final static Tracer TRACER = GlobalOpenTelemetry.getTracer("app");

private static final Iterable<String> KEYS = List.of(com.azure.core.util.tracing.Tracer.DIAGNOSTIC_ID_KEY);
private static final TextMapGetter<ServiceBusReceivedMessage> SERVICE_BUS_CONTEXT_GETTER =
        new TextMapGetter<ServiceBusReceivedMessage>() {
            @Override
            public Iterable<String> keys(ServiceBusReceivedMessage carrier) {
                return KEYS;
            }

            @Override
            public String get(ServiceBusReceivedMessage carrier, String key) {
                if ("traceparent".equals(key)) {
                    Object value = carrier.getApplicationProperties().get(com.azure.core.util.tracing.Tracer.DIAGNOSTIC_ID_KEY);
                    return value == null ? null : value.toString();
                }

                return null;
            }
        };

2. and then in your accept method, start a span using remote context from sender

   private static void accept(ServiceBusReceivedMessage msg) {
        Context remoteContext = W3CTraceContextPropagator.getInstance().extract(Context.current(), msg, SERVICE_BUS_CONTEXT_GETTER);

        Span span = TRACER.spanBuilder("ServiceBus.process").setParent(remoteContext).setSpanKind(SpanKind.CONSUMER).startSpan();
        try (Scope scope = Context.current().with(span).makeCurrent()) {
            System.out.println("msg.body : " + msg.getBody());
            System.out.println("msg.properties : " + msg.getApplicationProperties());
            doSomeJob();
            System.out.println("trace-id: " + span.getSpanContext().getTraceId());
            span.setStatus(StatusCode.OK);
        } catch (Throwable t) {
            span.recordException(t);
            span.setStatus(StatusCode.ERROR);
        } finally {
            span.end();
        }
    }

Here's what I see. And of course, you can add any attributes to the new span as you see fit.

I also sent PR to your repro app with suggested changes vyhid/sb-otel-instrumentation#1

I'll keep this bug open as a feature request to instrument receive calls (which we'll do once otel conventions around it will stabilize)