Copyright © 2024 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Cannot GET /uploads/qTHRgx/spec/01-abstract.md
This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
Cannot GET /uploads/qTHRgx/spec/02-sotd.md
This document was published by the Distributed Tracing Working Group as an Editor's Draft.
Publication as an Editor's Draft does not imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 03 November 2023 W3C Process Document.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY and MUST in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Distributed tracing is a methodology implemented by tracing tools to follow, analyze and debug a transaction across multiple software components. Typically, a distributed trace traverses more than one component which requires it to be uniquely identifiable across all participating systems. Trace context propagation passes along this unique identification. Today, trace context propagation is implemented individually by each tracing vendor. In multi-vendor environments, this causes interoperability problems, like:
In the past, these problems did not have a significant impact as most applications were monitored by a single tracing vendor and stayed within the boundaries of a single platform provider. Today, an increasing number of applications are highly distributed and leverage multiple middleware services and cloud platforms.
This transformation of modern applications calls for a distributed tracing context propagation standard.
The trace context specification defines a universally agreed-upon format for the exchange of trace context propagation data - referred to as trace context. Trace context solves the problems described above by
A unified approach for propagating trace data improves visibility into the behavior of distributed applications, facilitating problem and performance analysis. The interoperability provided by trace context is a prerequisite to manage modern micro-service based applications.
The current version of the Trace Context specification is targeted for implementations by applications and services, including web applications running within a browser. Web Browsers or User Agents are not currently in scope as a target implementation.
Trace context is split into two individual propagation fields supporting interoperability and vendor-specific extensibility:
traceparent describes the position of the incoming request in its trace graph in a portable, fixed-length format. Its design focuses on fast parsing. Every tracing tool MUST properly set traceparent even when it only relies on vendor-specific information in tracestatetracestate extends traceparent with vendor-specific data represented by a set of name/value pairs. Storing information in tracestate is optional.Tracing tools can provide two levels of compliant behavior interacting with trace context:
traceparent and tracestate headers and guarantee traces are not broken. This behavior is also referred to as forwarding a trace.traceparent header and relevant parts of the tracestate header containing their proprietary information. This is also referred to as participating in a trace.A tracing tool can choose to change this behavior for each individual request to a component it is monitoring.
Cannot GET /uploads/qTHRgx/spec/20-http_request_header_format.md
Cannot GET /uploads/qTHRgx/spec/21-http_response_header_format.md
Cannot GET /uploads/qTHRgx/spec/30-processing-model.md
Cannot GET /uploads/qTHRgx/spec/40-other-protocols.md
Cannot GET /uploads/qTHRgx/spec/50-privacy.md
Cannot GET /uploads/qTHRgx/spec/51-security.md
Cannot GET /uploads/qTHRgx/spec/60-trace-id-format.md
Cannot GET /uploads/qTHRgx/spec/61-span-id-format.md
Cannot GET /uploads/qTHRgx/spec/60-acknowledgments.md
This section is non-normative.