Simplify usage of distributed tracing on by default in ASP.NET Core and HttpClient

[davidfowl]

Epic: #8924

Today ASP.NET Core and HttpClient can be configured to flow a hierarchical request id throughout the stack (incoming and outgoing). Doing this properly is fragile and not very approachable. The goal of this issue is to make that turn key and on by default.

[riha]

As I understand it HttpClient will today always create a new Request-Id and not take account any existing values in the Request-Id header. Correct?

You however mention that HttpClient can be configured to flow a Request-Id. Is there any examples of how this can be done? Hard to get good end-to-end dependency logging in Applicantion Insights without it.

[davidfowl]

As I understand it HttpClient will today always create a new Request-Id and not take account any existing values in the Request-Id header. Correct?

Not quite. Nothing flows by default for performance reasons. There are several pieces that need to be turned on today to get the end to end experience we're trying to build.

You however mention that HttpClient can be configured to flow a Request-Id. Is there any examples of how this can be done? Hard to get good end-to-end dependency logging in Applicantion Insights without it.

Yes the code is buried in application insights but this issue is about designing an end to end that works without it.

[RemiBou]

Could this work also include connection with non http dependencies ? (SQL, Redis ...)

[davidfowl]

Moving this to preview4

[analogrelay]

Triage decision: This is part of the distributed tracing work we're looking at.

[vpaulino]

What is the best way to share ideias regarding the design ? If I have some UML diagrams i could share it here ? some documents supporting the ideias ?

[davidfowl]

The HttpClient work will be moved to corefx. The epic will be used to track the remaining work.