Trace Context Level 3

W3C Editor's Draft

More details about this document
This version:
https://w3c.github.io/trace-context/
Latest published version:
https://www.w3.org/TR/trace-context-3/
Latest editor's draft:
https://w3c.github.io/trace-context/
History:
Commit history
Implementation report:
https://w3c.github.io/trace-context/implementations
Editors:
Sergey Kanzhelev (Google)
Daniel Dyla (Dynatrace)
Yuri Shkuro (Meta)
J. Kalyana Sundaram (Microsoft)
Bastian Krol (Dash0)
Former editors:
Nik Molnar
Alois Reitbauer
Morgan McLean
Bogdan Drutu
Daniel Khan
Feedback:
GitHub w3c/trace-context (pull requests, new issue, open issues)
public-trace-context@w3.org with subject line trace-context (archives)
Discussions
We are on Slack.

Abstract

Error
Cannot GET /uploads/qTHRgx/spec/01-abstract.md

Status of This Document

This is a preview

Do not attempt to implement this version of the specification. Do not reference this version as authoritative in any way. Instead, see https://w3c.github.io/trace-context/ for the Editor's draft.

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/.

Error
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.

1. Conformance

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.

2. Overview

2.1 Problem Statement

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.

2.2 Solution

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.

2.3 Design Overview

Trace context is split into two individual propagation fields supporting interoperability and vendor-specific extensibility:

Tracing tools can provide two levels of compliant behavior interacting with trace context:

A tracing tool can choose to change this behavior for each individual request to a component it is monitoring.

Error
Cannot GET /uploads/qTHRgx/spec/20-http_request_header_format.md
Error
Cannot GET /uploads/qTHRgx/spec/21-http_response_header_format.md
Error
Cannot GET /uploads/qTHRgx/spec/30-processing-model.md
Error
Cannot GET /uploads/qTHRgx/spec/40-other-protocols.md
Error
Cannot GET /uploads/qTHRgx/spec/50-privacy.md
Error
Cannot GET /uploads/qTHRgx/spec/51-security.md
Error
Cannot GET /uploads/qTHRgx/spec/60-trace-id-format.md
Error
Cannot GET /uploads/qTHRgx/spec/61-span-id-format.md
Error
Cannot GET /uploads/qTHRgx/spec/60-acknowledgments.md

3. Glossary

This section is non-normative.

Distributed trace
A distributed trace is a set of events, triggered as a result of a single logical operation, consolidated across various components of an application. A distributed trace contains events that cross process, network and security boundaries. A distributed trace may be initiated when someone presses a button to start an action on a website - in this example, the trace will represent calls made between the downstream services that handled the chain of requests initiated by this button being pressed.
Opaque value
An opaque value refers to a value that can only be understood or processed in any way by the distributed trace participant that generated this value. Any other participant must treat it as a blob of bytes.

A. References

A.1 Normative references

[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174