Support W3C format for distributed trace context propagation

[SergeyKanzhelev]

Motivation

Support extraction and injection of distributed tracing context in a format of W3C headers.

Support for new headers in ASP.NET depend on support for tracestate collection in Activity class of DiagnosticsSource.

CC: @seth-capistron, @vancem, @jacpull, @lmolkova, @glennc, @davidfowl

[muratg]

cc @shirhatti @davidfowl @Tratcher

[discostu105]

Please consider the case of "multiple" tracecontext users/providers in one process. This will be the use-case for the Dynatrace .NET Agent.

Challenge:

• Currently, the Dynatrace .NET Agent would auto-instrument itself into various methods (asp.net core middleware for incoming HTTP, HttpClient for outgoing HTTP). At these places, it would
  • read HTTP headers (traceparent & tracestate), keep it's state, propagate that state in-process. If no traceparent was present, it would create it's own traceId.
  • For an outgoing HTTP call, the Agent would add HTTP headers (traceparent & tracestate) itself. It would take care of properly changing tracestate (keep other entries, satisfy the spec).
• Now, if .NET Core / ASP.NET Core / DiagnosticSource would support TraceContext natively, a few things would change (IMHO, please correct if wrong):
  • DiagnosticSource would also read traceparent & tracestate. It would remember them (via DiagnosticSource Activity).
  • In case no traceparent was present, would it create it's own traceId?
  • In case of an outgoing HTTP call, DiagnosticSource would take care of placing traceparent and tracestate HTTP headers.

I see these problems:

• traceId generation. Both DiagnosticSource and Dynatrace Agent would create one.
• traceparent generation. Who will decide upon new SpanId, TraceOptions flags?
• tracestate handling. For this case, I guess the Dynatrace Agent just needs to become aware of DiagnosticSource and re-use it's TraceState collection, rather than writing the whole tracestate HTTP header itself. That's doable.

Add OpenCensus, OpenTracing into the mix. Who controls id's and who ultimately writes HTTP headers?

[analogrelay]

Epic #8924

[lmolkova]

Fixed with #8495, dotnet/corefx#35882, dotnet/corefx#33207

[analogrelay]

@SergeyKanzhelev as far as you know, is there further work needed in ASP.NET Core here? (Catching up on stuff, sorry if this has been discussed before :))

(cc @glennc)

[SergeyKanzhelev]

@anurse there are other issues for different aspects of distributed tracing. This issue is OK to close.

[analogrelay]

Thanks @SergeyKanzhelev !

[mmayr-at]

Please consider the case of "multiple" tracecontext users/providers in one process. This will be the use-case for the Dynatrace .NET Agent.

Challenge:

• Currently, the Dynatrace .NET Agent would auto-instrument itself into various methods (asp.net core middleware for incoming HTTP, HttpClient for outgoing HTTP). At these places, it would

  • read HTTP headers (traceparent & tracestate), keep it's state, propagate that state in-process. If no traceparent was present, it would create it's own traceId.
  • For an outgoing HTTP call, the Agent would add HTTP headers (traceparent & tracestate) itself. It would take care of properly changing tracestate (keep other entries, satisfy the spec).

• Now, if .NET Core / ASP.NET Core / DiagnosticSource would support TraceContext natively, a few things would change (IMHO, please correct if wrong):

  • DiagnosticSource would also read traceparent & tracestate. It would remember them (via DiagnosticSource Activity).
  • In case no traceparent was present, would it create it's own traceId?
  • In case of an outgoing HTTP call, DiagnosticSource would take care of placing traceparent and tracestate HTTP headers.

I see these problems:

• traceId generation. Both DiagnosticSource and Dynatrace Agent would create one.
• traceparent generation. Who will decide upon new SpanId, TraceOptions flags?
• tracestate handling. For this case, I guess the Dynatrace Agent just needs to become aware of DiagnosticSource and re-use it's TraceState collection, rather than writing the whole tracestate HTTP header itself. That's doable.

Add OpenCensus, OpenTracing into the mix. Who controls id's and who ultimately writes HTTP headers?

@davidfowl Here the issue with the question from @discostu105 I was mentioning today during our conversation in the NDC workshop.