-
Notifications
You must be signed in to change notification settings - Fork 441
feat(azure_servicebus): add azure servicebus integration and function trigger distributed tracing #13691
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
base: main
Are you sure you want to change the base?
Conversation
…ced directly from the context
… related to service bus
…ctions and azure_servicebus
|
Bootstrap import analysisComparison of import times between this PR and base. SummaryThe average import time from this PR is: 276 ± 2 ms. The average import time from base is: 278 ± 2 ms. The import time difference between this PR and base is: -1.63 ± 0.1 ms. Import time breakdownThe following import paths have appeared:
|
BenchmarksBenchmark execution time: 2025-06-18 02:20:24 Comparing candidate commit 82e0204 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 561 metrics, 3 unstable metrics. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice use of ddtrace.internal.core
!
__get_version__ = get_version | ||
|
||
def assert_module_patched(self, azure_servicebus): | ||
pass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replacing this with an assertion verifying that the azure.servicebus
module has been patched would strengthen this test case and protect against regressions. Same for the other two functions here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great suggestion! I added some assertions to the patch tests.
Also because this integration also patches azure.servicebus.aio
, a submodule of azure.servicebus
, I added an additional case for test_supported_versions_function_exists
. I tried changing the else to use rpartition
as well but it broke the tests for pynamodb.connection.base
since that submodule should resolve to pynamodb
. Let me know if you have any ideas for a more general solution.
dd-trace-py/tests/contrib/patch.py
Lines 818 to 824 in 82e0204
elif module_name in {"azure.servicebus.aio"}: | |
# handle specific submodules where the top level module name includes a dot | |
module_name = module_name.rpartition(".")[0] | |
else: | |
# this may be a submodule we are importing, so get the top level module name | |
# ie: snowflake.connector -> snowflake | |
module_name = module_name.split(".")[0] |
def get_version(): | ||
# type: () -> str |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
def get_version(): | |
# type: () -> str | |
def get_version() -> str: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion applied for both Azure Service Bus and Azure Functions
dd-trace-py/ddtrace/contrib/internal/azure_servicebus/patch.py
Lines 29 to 30 in 82e0204
def get_version() -> str: | |
return getattr(azure_servicebus, "__version__", "") |
dd-trace-py/ddtrace/contrib/internal/azure_functions/patch.py
Lines 27 to 28 in 82e0204
def get_version() -> str: | |
return getattr(azure_functions, "__version__", "") |
…'t reuse service bus messages
This PR adds an integration for tracing the producer of the azure-servicebus package and adds support for distributed tracing for Azure Functions consuming the service bus messages.
Instrumentation details:
azure.servicebus
andazure.servicebus.aio
(async package) are patchedServiceBusSender.send_messages
ServiceBusSender.schedule_messages
application_properties
of each service bus message passed to above methodsServiceBusMessage
orAmqpAnnotatedMessage
in addition to a list ofServiceBusMessage
orAmqpAnnotatedMessage
ServiceBusMessageBatch
in a future PRapplication_properties
in Azure Function service bus consumerazure.servicebus.produce
component: azure_servicebus
span.kind: producer
messaging.destination.system: servicebus
messaging.destination.name: <queue/topic name>
azure.servicebus.fully_qualified_namespace: <host name for the Service Bus namespace>
peer.service
if enabledAdditional Notes:
azureservicebusemulator
andazuresqledge
services to run Azure Service Bus locally and in CI for testsazure_functions
integration to usectx.span
instead of addingreq_span
andtrigger_span
properties to the contextChecklist
Reviewer Checklist