adding distributed tracing capabilities to my endpoints
Could you explain what you mean by this? I’m asking, because we might already be doing this for you. I’m not sure how familiar you are with our entire platform.
We allow auditing of messages. This means every successfully processed message will end up in some queue. Usually we advise to have them end up in the same queue for all endpoints and capture those message.
We do this ourselves by using ServiceControl. It stores every single message inside a database, with a retention of several days.
After that you can use this data to even visualize it, like we do with our ServiceInsight tool. It accesses ServiceControl via an API.
We do the same for messages that cannot be processed. We send them to a central queue, ServiceControl processes them and we visualize this using ServicePulse. It can even provide much more information about monitoring your endpoints.
To get back to your questions, I’m not sure what it is you’re trying to achieve. We already put a fair amount of information in headers though, like
ConversationId. More info can be found here. We even put the exception and stacktrace inside message headers on messages that fail. But we don’t do it with every retry, we just do it after it keeps failing. More information on how to extend NServiceBus to deal with this can be found here and here.
But I’m wondering if we’re already doing what you’re trying to achieve. But I’m not 100% sure what it is you’re trying to achieve, from a functional perspective?