Showing results for 
Show  only  | Search instead for 
Did you mean: 

W3C tracestate and X-Dynatrace

DynaMight Champion
DynaMight Champion


I have noticed that the tracestate is not used by dynaytrace, is this a deliberate design choice or will the X-dynatrace header be placed there in the future?

Also when both traceparent and x-Dynatrace are available, what is the preference to stitch pp? And what happens if both contradict?

KR Henk


DynaMight Legend
DynaMight Legend

At the moment it's used for stitching transactions on the boundaries of services monitored by Dynatrace OneAgents. The X-Dynatrace header is used within a Dynatrace environment only. If you need to follow PurePaths from one Dynatrace environment to another one, the W3C tracing headers are used.

So within an environment, the X-Dynatrace does have a higher priority at the moment.

Certified Dynatrace Master | Alanata a.s., Slovakia, Dynatrace Master Partner


Hi @Julius_Loman , I hope you're doing well. I've a question.

The W3C Trace Context defines the traceparent and tracestate headers. In the traceparent header there are the trace-id and the parent-id. The parent-id is the span-id of the sender (the previous service), right?

So, how can we get the current span-id (I mean, the span-id of the current service)?

With the trace-id, the current span-id and the parent-id we can correlate all the logs (for example). But only with the trace-id and the parent-id, we can't.


Additional info: some tracing SDK, like OpenTelemetry, allows accessing to the Span Context, where the new span-id is. But I don't know how to extract that span-id when the services is traced by the One Agent.


Thanks a lot!

@luis_mpa , can you please describe what problem are you trying to solve?

Certified Dynatrace Master | Alanata a.s., Slovakia, Dynatrace Master Partner

Yes, of course.


The use case is the following: suppose you have a sequence like the attached picture 1. The W3C Trace Context indicates that the span-id of the current service should be sent as parent-id. So, when the other service receives the request, it generates its own span-id -which is put in a span context- and all the log traces that the service generates for that span can be correlated (picture number 2), because you have the trace-id, the parent-id (which is the span id of the caller) and the span-id of the current microservice.


In the following entry the use case is explained with full detail -->  (the key point is the "Log messages title". You can find it by scrolling the page).


The key is that the requested service is which generates it owns span-id. In our case, since the One Agent is monitoring and tracing that service, is the One Agent -I suppose, please confirm- which generates the spanId. But I don't know how to extract that spanId, in order to use for logging output (like the picture 2 indicates).



Featured Posts