jbogard
August 29, 2019, 1:45pm
1
Has anyone here done much work or investigation in supporting the W3C trace context standard? ASP.NET Core 3 and .NET Core 3.0 will automatically flow these values in ASP.NET Core middleware and HttpClient extensions.
Azure Service Bus is also instrumented in this standard.
Could you please provide a reference? I’m aware of the Application Insights integration that the new Service Bus client has built-in, but not the W3C trace context.
jbogard
August 29, 2019, 8:23pm
3
and
# Note
Starting with System.Diagnostics.DiagnosticSource 4.6.0 (that ships with .Net Core 3.0), we are moving towards [W3C Trace-Context](https://www.w3.org/TR/trace-context/) standard. We still support Request-Id ([hierarchical](HierarchicalRequestId.md) version) and it is still the default format for `System.Diagnostics.Activity`.
[Flat Request-Id](FlatRequestId.md) is **deprecated**.
# Overview
One of the common problems in microservices development is ability to trace request flow from client (application, browser) through all the services involved in processing.
Typical scenarios include:
1. Tracing error received by user
2. Performance analysis and optimization: whole stack of request needs to be analyzed to find where performance issues come from
3. A/B testing: metrics for requests with experimental features should be distinguished and compared to 'production' data.
These scenarios require every request to carry additional context and services to enrich their telemetry events with this context, so it would possible to correlate telemetry from all services involved in operation processing.
Tracing an operation involves an overhead on application performance and should always be considered as optional, so application may not trace anything, trace only particular operations or some percent of all operations.
Tracing should be consistent: operation should be either fully traced, or not traced at all.
show original
There’s some open GH issues that are documenting progress in the ASP.NET Core side