Review Distributed Tracing features in the new Service Bus library

[ramya-rao-a]

When we were working on the latest Event Hubs package, we had a definite set of requirements of how each send request and the different modes of receiving events did tracing. Service Bus is in a similar boat as Event Hubs in terms of tracing needs with the addition of a whole new set of methods for peek, receiving deferred messages, sending scheduled messages etc.

This issue is to review how much of what we did in Event Hubs can be ported over to Service Bus and figure out the gap

[jmealo]

@ramya-rao-a: this would be super helpful. We're on the preview of the service-bus library and have an issue where our queues stop processing after a number of hours regardless of volume. Since the refactoring of logging to be compatible with IE11, debug no longer works as expected with pino-debug which causes all the Azure logging to side-step our logging facilities and go to std-err as multi-line errors. It's very hard to troubleshoot as the instrumentation seems focused more towards internal/Azure use versus what an end user/customer would actually need to troubleshoot issues.

[richardpark-msft]

@jmealo - the logging that we internally produce is intended for troubleshooting so it can be quite detailed. The feature above would be a better fit for overall health/monitoring in that it'll give you an idea of how long messages take to go through your processing, etc...

However, a dead receiver is different - this should have triggered an error or message that would have shown up as an exception, or delivered via your processError callback.

Please feel free to file an issue and we can take a look.

Things we'll need to start:

• Any logs you can collect - obviously the window of time when it's no longer working and the period before to see if there were issues with the connection to the service bus broker, etc..
• Any information about your service bus that you can collect that might be related to service disruption
• Which method do you use to receive messages? Is it subscribe, receiveMessages or getMessageIterator?

The bug report template in the issue tracker for this repo should guide you on some other details when you're ready.