Feature request: Support for the W3C Trace Context standard

[tylerohlsen]

Related to this article, I'd like this library to use the same W3C Trace Context standard for propagating the ScopeContext on downstream http client requests (via the headers defined in the standard).

I think one way to do this would be to hook up ScopeContext to pull the TraceId (and other trace / span) values on the root scope from the Activity.Current and defer to that library as well to generate child TraceId, SpanId, and other values. This approach would inherently support custom scopes for other forms for downstream propagation using standard .NET libraries (using System.Diagnostics.Activity) instead of needing to reference a Datadog library.

[macrogreg]

Hi @tylerohlsen ,

We are currently working on support of Open Telemetry and .NET activities. As a part of this of this effort we plan to also address W3C context compatibility.

For context, see: https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/issues/13 and https://github.com/dotnet/runtime/issues/42786#issuecomment-700370497

Right now I cannot share an ETA, but stay tuned!

[macrogreg]

Internal tracker: https://datadoghq.atlassian.net/browse/DOTNET-21

[julealgon]

@macrogreg do you have any updates on adding support for working with native System.Diagnostics.Activity? We would also like to leverage this so we can use standard constructs in our custom instrumentations and not need to reference and use Datadog classes directly in library code.

EDIT: I just noticed this was updated fairly recently (what a coincidence):

lucaspimentel removed the status:work-in-progress label 22 hours ago

Is the feature not in active development anymore? Or perhaps it means it has finished development?

[ozziepeeps]

Would love an update on this @macrogreg if you have the time? I lot of us in the community would love to use the .NET Activity abstractions combined with DataDog. Thank you in advance.

[andrewlock]

Hi all, thanks for your patience. We recently added support for propagation of B3 and W3C headers in #2536 which was a prerequisite for supporting Activity.

We are now doing initial proof-of-concept work for adding compatibility with Activity in #2446, so following that PR would be a good option. If you have any comments about whether the proposed solution in that PR would/would not work for you, or examples of how you'd like it to work (if our proposal doesn't suit you) that would be great!

Thanks!

[mrtristan]

@andrewlock maybe i need to open a new issue for this but maybe you can comment as it's pretty related. Is there a concept along these lines in the dotnet side?

https://github.com/DataDog/dd-trace-js/issues/1601

I believe this is a breaking change in that we're running the new tracer version and we're having downstream (external) http services that are blowing up due to the unexpected DD headers.

as part of this effort to support downstream http header propagation, there needs to be a way to exclude certain domains from that process

[lucaspimentel]

there needs to be a way to exclude certain domains from that process

@mrtristan: Agreed! I will close this issue as the OP's request for W3C Trace Context support is now implemented. You can open a new feature request for excluding specified domains from downstream propagation headers.

I believe this is a breaking change in that we're running the new tracer version and we're having downstream (external) http services that are blowing up due to the unexpected DD headers.

In your new feature request, can you include more details about this? We have always injected several http headers for trace propagation. Did you notice any recent change in those headers that would cause this issue? Thanks!

[mrtristan]

all good @lucaspimentel, thanks - covered in #3000 / #3001