I’m using the latest version of NSB, enabled OpenTelemetry and configured it for logging and tracing with AppInsights Exporter.
When logging within a handler (e.g. logging an information), when querying AppInsights Logs with kusto query, I see the logs. The logs contain a TraceId, ParentId and SpanId as expected. But how does it correlate to the message? I expected to have a TraceId on the message header of the NServiceBus message, but that does not exist.
How does the correlation work, do I need to do something more to have the traceIds on the message header, in order to correlate?
Thanks for your help
update: I see a header information traceparent which I can correlate to my own log in case of a successfully processed message. But in case of an error message, that header information is missing and I can still not correlate.
@Fabian_Trottmann
We are looking into this and investigating it. I will reach back with my findings in a couple of days.
Hi @Fabian_Trottmann
We are unable to recreate the issue you had stated on our end. We are able to see the traceparent header in both the successful and error scenarios in the respective configured queues. If possible, can you send in a sample or even steps to reproduce and we can retry on our side?
1 Like
Hi @Jayanthi_Sourirajan
I just tried it again and surprisingly it is there for both sucessful and error messages. I have no clue, why it didn’t work before.
Thank you
@Fabian_Trottmann could it be that the processed message originated from an endpoint that did not yet have OpenTelemetry enabled?
@ramonsmits the message is coming from an endpoint which does not have OpenTelemetry enabled. But does that matter? we don’t have influence on the originating endpoint in a lot of cases.
It now works on my machine (for both sucessful and error messages) but the exact same setup does not work for co-workers. So the original problem described in the first post, does occur for my co-worker (traceparentid exists on sucessful message, but does not appear on error message). We have no idea, what makes it work and what doesn’t.
Btw: it does not work for my co-worker, eventhough we enable OpenTelemetetry on originating endpoint.
The behavior gets even stranger: currently I got rid of EnableOpenTelemetry and I dont even configure OpenTelemetry at all. But for that endpoint it still adds traceparent as well as Diagnostic-Id on message header (error and successful). I removed all packages and downgraded to NSB 8.0.3. It seems that is highly dependent on the machine.
We are stuck, do you have any idea what is going on?
@Fabian_Trottmann : As we need to investigate further and may also need to share some code samples in order to try reproducing the scenario, I suggest that you submit a support ticket to support@particular.net with all the relevant details. Once we are able to find the root cause and resolve, we can post the final findings back here as well.
just submitted a support ticket
Yes it does, as when the incoming message does not have an ID those headers are read-only. Any processing attemps will create a new trace parent. For the best experience the sender needs to add a traceparent for any message that it sends.