blog: W3C Trace Context specification enters proposed recommendation status and what it means

[[


The W3C Distributed Tracing working group has moved the Trace Context 
specification to the next maturity level. The specification is already 
being adopted and implemented by many platforms and SDKs. This article 
describes the Trace Context specification and how it improves 
troubleshooting and monitoring of modern distributed apps.

W3C Trace Context specification defines the format for propagating 
distributed tracing context between services. Distributed tracing makes 
it easy for developers to find the causes of issues in 
highly-distributed microservices applications by tracking how a single 
interaction was processed across multiple services. Each step of a trace 
is correlated through an ID that is passed between services, and W3C 
Trace Context now defines a standard for these context propagation headers.

Until now, different tracing systems have defined their own headers. 
Examples include Zipkin’s B3 format and X-Google-Cloud-Trace. Adopting a 
common context propagation format has been long desired by developers, 
APM vendors, and cloud platform hosts, as compatibility provides 
numerous benefits:

     Web and RPC frameworks that use this standard to provide context 
propagation out of the box will also offer cross-service log 
correlation, even for developers who haven’t set up distributed tracing.
     API producers can record the trace IDs of requests from API 
consumers and provide additional spans or metadata to their customers 
for a given traced request. Producers can also correlate customer trace 
IDs to internal traces when debugging technical issues raised by consumers.
     Networking infrastructure (proxies, load balancers, routers, etc.) 
can both ensure that context propagation headers are not removed from 
requests passing through them, and can record spans or logs for a given 
trace, without having to support multiple vendor-specific formats. 
Potential examples of these include router appliances, cloud load 
balancers, and sidecar proxies like Envoy.
     Instrumentation can be further decoupled from a developer’s choice 
of APM vendor. For example, using both OpenTelemetry and a given 
vendor’s agents, a developer can instrument different services in an 
application, and traces will flow through the system and be processed 
correctly by the vendor’s backend.
     Web browsers and other clients can use these identifiers to 
correlate their telemetry with traces collected from backend services. 
This functionality is currently being defined.

To address this effort, a group of cloud providers, open source 
contributors, and APM vendors started defining a standard HTTP context 
propagation header that would replace their homegrown formats. This 
specification has been discussed and iterated on over the past two 
years, and the group working on it has grown significantly over that 
time. Sponsors include Google, Microsoft, Dynatrace, and New Relic (W3C 
members), and the group was officially moved into the W3C in 2018 for 
the work to proceed under the guidance of an official standards body and 
to spur even greater adoption.

TraceContext has since been adopted by OpenTelemetry (which enables it 
by default and also serves as the reference implementation), Azure 
services, Dynatrace, Elastic, Google Cloud Platform, Lightstep, and New 
Relic. We are tracking adoption in this list.

This first phase of work has focused on HTTP, as it is commonly used and 
has no built-in affordances for trace context propagation (gRPC and some 
newer RPC systems do). The same group of committee members are also 
working to define trace context propagation in other formats, starting 
with AMQP and MQTT for IoT; other upcoming topics include context 
propagation from clients and web browsers.

(post by the Distributed Tracing Working Group)

]]
https://www.w3.org/blog/2019/12/trace-context-enters-proposed-recommendation/

Received on Wednesday, 11 December 2019 15:00:13 UTC