w3c trace best practices

[Benjamin_Carlyl]

G'day all,

I'm trying to understand some of what I have read about using dynatrace and w3c trace[1]. Say I add my own w3c trace headers to requests between my services, is this the kind of thing that would conflict with how dynatrace would understand these headers? In the future could I use these headers instead of integrating with the oneagent SDK to tell dynatrace about asynchronous operations within my services? What does the future state look like for combining w3c trace and dynatrace?

A second question on this: What does best practice look like when looking at logging correlation identifiers and trace identifiers? Does it make sense to use the same ID for both trace and log message correlation? What potential pitfalls would we expect to find in that approach?

Thanks to Julius for the answer below. This leads me to a third question. w3c trace contains a trace-flags field that supports a "sampled" flag. What would my best practice be for setting this flag? Should a service enabled for w3c trace still access the OneAgent SDK in order to set this flag appropriately?

[1] https://www.dynatrace.com/news/blog/distributed-tracing-with-w3c-trace-context-for-improved-end-to-e...

[Julius_Loman · Accepted solution]

If you follow the w3c specification for tracing headers, Dynatrace will honour them. It particularly makes sense if you have part of your applications not covered by Dynatrace OneAgents. However W3C headers are for HTTP communication only, thus OneAgent SDK will still be required in some areas and the SDK covers much more use cases. Opentelemetry support in Dynatrace will probably replace much more functionality of OneAgent SDK. Right now W3C and Dynatrace headers can co-exist without any issues.

Regarding the second question - I personally don't have much experience here, but as the W3C tracing headers are a (future) standard, I'd recommend to put them into your log entries to be able to trace the log messages back to individual calls. The header values can be quite long, be sure your logs can handle such long identifiers.

[luis_mpa]

Thanks @Július L. for your answer and @Benjamin_Carlyl  for your question. I have a related question.

In other standards, like the B3 (and x-b3), there are three fields for tracing: the traceId, the spanId and the parentSpanId. By propagating and updating each field, and adding them to the log output, we are able to establish a hierachy of requests (because the parentSpanId of the called service is the spanId of the caller).

But in this standard, we have only two fields: the traceId and the parentId. How do we build a log correlation with only the traceId and parentSpanId? We are able only to grouping logs that belong to the same transaction -by the traceId- and the operation of each service -by the parentId-, but we are not able to establish an order that identify caller-callee because we don't know the spanId of the previous service.

Is there any way to correlate logs with this standard? Is there any way to know what is the spanId of the caller?

Thanks a lot.

[luis_mpa]

Hi @Benjamin_Carlyl . I've opened an idea related to one of your post points. Specifically, related to the "log correlation" point:

Improving the W3C tracecontext for log correlation

In case you are interested.

Regards,

Luis Miguel