Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with Azure ServiceBus distributed trace #5326

Open
brunohdossantos opened this issue Mar 20, 2024 · 9 comments
Open

Problem with Azure ServiceBus distributed trace #5326

brunohdossantos opened this issue Mar 20, 2024 · 9 comments

Comments

@brunohdossantos
Copy link

I am unable to use the distributed trace to communicate between services using Azure Service Bus, the trace is only working when a service A communicates with a service B through a web api. I'm using the latest version of dd-trace-dotnet and the Azure ServiceBus SDK. From what I understand after this update https://github.com/DataDog/dd-trace-dotnet/pull/4575/files#diff-426121b5cc1e2b68a3fb5aef68641547dd3488c59332d4a79adf23be9460545d the propagation of the necessary contexts would be done automatically. Has anyone had success in this scenario?

@zacharycmontoya
Copy link
Collaborator

Hi @brunohdossantos, can you confirm the following information so I can help understand the setup you have:

  1. Are Service A (message sender) and Service B (message receiver) both using the Datadog .NET Tracer v2.38.0 or above, and do they both have environment variable DD_TRACE_OTEL_ENABLED=true? These are the pre-requisites for our Azure Service Bus instrumentation.
  2. Can you also confirm what version of the Azure.Messaging.ServiceBus SDK package you are using?

@brunohdossantos
Copy link
Author

Hi @zacharycmontoya , yes I have the variable DD_TRACE_OTEL_ENABLED=true, i am using the Azure.Messaging.ServiceBus version - 7.17.14 and Datadog.Trace in version 2.49, the apm version is also 2.49.

When consuming the message, my service performs a _tracer.StartActive, could this be a problem?

@brunohdossantos
Copy link
Author

Anyone with the same error? Or with the same scenario and working without problems ?

@brunohdossantos
Copy link
Author

Has anyone experienced this problem, had a solution?

@brunohdossantos
Copy link
Author

Do we have a solution for this problem?

@rnarayana
Copy link

I believe this also requires you to also set AZURE_EXPERIMENTAL_ENABLE_ACTIVITY_SOURCE to true, which injects traceparent into the message properties. This worked for me.

https://docs.datadoghq.com/tracing/trace_collection/compatibility/dotnet-core/#opentelemetry-based-integrations

@AlvaroRCAbreu
Copy link

Here I need to set this environment variable too: AZURE_EXPERIMENTAL_ENABLE_ACTIVITY_SOURCE

@frankhaugen
Copy link

I believe this also requires you to also set AZURE_EXPERIMENTAL_ENABLE_ACTIVITY_SOURCE to true, which injects traceparent into the message properties. This worked for me.

https://docs.datadoghq.com/tracing/trace_collection/compatibility/dotnet-core/#opentelemetry-based-integrations

Docs don't have this information anymore:
image

@bouwkast
Copy link
Contributor

@frankhaugen Apologies, it looks like this callout was moved to here: https://docs.datadoghq.com/opentelemetry/interoperability/instrumentation_libraries/?tab=net#verified-opentelemetry-instrumentation-libraries

AZURE_EXPERIMENTAL_ENABLE_ACTIVITY_SOURCE will still need to be set to true to work (or via Azure.Experimental.EnableActivitySource)

@brunohdossantos was this by any chance the issue that you were running into?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants