Ambient distributed tracing context

[SergeyKanzhelev]

Same as https://github.com/aspnet/Hosting/issues/1458 for ASP.NET Core

Motivation

Propagate W3C headers to dependant components and make distributed tracing context available even when monitoring is not enabled.

Propagation of headers will ensure that distributed trace will correlate services even when unmonitored ASP.NET app is deployed in-the-middle. Let's take service A that injects distributed tracing context and calls ASP.NET app B. Service B calls service C that expects distributed tracing context in incoming request.

If B is not being monitored for distributed traces - it should propagate distributed tracing context unmodified. When analysing telemetry from services A and C it will look like A calls C directly. Once distributed tracing monitoring will be enabled for B - B have to start modifying context according to W3C specification. So telemetry analysis will show A calls B which calls C.

In both scenarios any other telemetry like ILogger traces or stack dumps can be attributed with the distributed tracing context. This will allow to correlate failures of service B with the distributed trace those failures affected.

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