254 lines
13 KiB
HTML
254 lines
13 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="UTF-8">
|
|
<title>Trace Context - W3C Recommendation 23 November 2021</title>
|
|
</head>
|
|
<body>
|
|
<!-- Source: https://www.w3.org/TR/2021/REC-trace-context-1-20211123/ -->
|
|
<!-- Downloaded: 2026-06-07 -->
|
|
|
|
<h1>Trace Context</h1>
|
|
<p>W3C Recommendation 23 November 2021</p>
|
|
|
|
<p>This version: https://www.w3.org/TR/2021/REC-trace-context-1-20211123/<br>
|
|
Latest published version: https://www.w3.org/TR/trace-context-1/<br>
|
|
Latest editor's draft: https://w3c.github.io/trace-context/</p>
|
|
|
|
<p><strong>Editors:</strong><br>
|
|
Sergey Kanzhelev (Microsoft)<br>
|
|
Morgan McLean (Google)<br>
|
|
Alois Reitbauer (Dynatrace)<br>
|
|
Bogdan Drutu (Google)<br>
|
|
Nik Molnar (Microsoft)<br>
|
|
Yuri Shkuro (Invited Expert)</p>
|
|
|
|
<hr>
|
|
|
|
<h2>Abstract</h2>
|
|
<p>This specification defines standard HTTP headers and a value format to propagate context information that enables distributed tracing scenarios. The specification standardizes how context information is sent and modified between services. Context information uniquely identifies individual requests in a distributed system and also defines a means to add and propagate provider-specific context information.</p>
|
|
|
|
<h2>Table of Contents</h2>
|
|
<ol>
|
|
<li>Abstract</li>
|
|
<li>Status of This Document</li>
|
|
<li>1. Conformance</li>
|
|
<li>2. Overview
|
|
<ol>
|
|
<li>2.1 Problem Statement</li>
|
|
<li>2.2 Solution</li>
|
|
<li>2.3 Design Overview</li>
|
|
</ol>
|
|
</li>
|
|
<li>3. Trace Context HTTP Headers Format
|
|
<ol>
|
|
<li>3.1 Relationship Between the Headers</li>
|
|
<li>3.2 Traceparent Header</li>
|
|
<li>3.3 Tracestate Header</li>
|
|
<li>3.4 Mutating the traceparent Field</li>
|
|
<li>3.5 Mutating the tracestate Field</li>
|
|
</ol>
|
|
</li>
|
|
<li>4. Processing Model</li>
|
|
<li>5. Other Communication Protocols</li>
|
|
<li>6. Privacy Considerations</li>
|
|
<li>7. Security Considerations</li>
|
|
<li>8. Considerations for trace-id field generation</li>
|
|
<li>A. Acknowledgments</li>
|
|
<li>B. Glossary</li>
|
|
<li>C. References</li>
|
|
</ol>
|
|
|
|
<h2>1. Conformance</h2>
|
|
<p>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.</p>
|
|
<p>The key words MAY, MUST, MUST NOT, SHOULD, and SHOULD NOT 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.</p>
|
|
|
|
<h2>2. Overview</h2>
|
|
|
|
<h3>2.1 Problem Statement</h3>
|
|
<p>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:</p>
|
|
<ul>
|
|
<li>Traces that are collected by different tracing vendors cannot be correlated as there is no shared unique identifier.</li>
|
|
<li>Traces that cross boundaries between different tracing vendors can not be propagated as there is no uniformly agreed set of identification that is forwarded.</li>
|
|
<li>Vendor specific metadata might be dropped by intermediaries.</li>
|
|
<li>Cloud platform vendors, intermediaries and service providers, cannot guarantee to support trace context propagation as there is no standard to follow.</li>
|
|
</ul>
|
|
|
|
<h3>2.2 Solution</h3>
|
|
<p>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</p>
|
|
<ul>
|
|
<li>providing an unique identifier for individual traces and requests, allowing trace data of multiple providers to be linked together.</li>
|
|
<li>providing an agreed-upon mechanism to forward vendor-specific trace data and avoid broken traces when multiple tracing tools participate in a single transaction.</li>
|
|
<li>providing an industry standard that intermediaries, platforms, and hardware providers can support.</li>
|
|
</ul>
|
|
|
|
<h3>2.3 Design Overview</h3>
|
|
<p>Trace context is split into two individual propagation fields supporting interoperability and vendor-specific extensibility:</p>
|
|
<ul>
|
|
<li><code>traceparent</code> 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 tracestate</li>
|
|
<li><code>tracestate</code> extends traceparent with vendor-specific data represented by a set of name/value pairs. Storing information in tracestate is optional.</li>
|
|
</ul>
|
|
|
|
<h2>3. Trace Context HTTP Headers Format</h2>
|
|
|
|
<h3>3.1 Relationship Between the Headers</h3>
|
|
<p>The traceparent header represents the incoming request in a tracing system in a common format, understood by all vendors. Here's an example of a traceparent header.</p>
|
|
<pre><code>traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01</code></pre>
|
|
<p>The tracestate header includes the parent in a potentially vendor-specific format:</p>
|
|
<pre><code>tracestate: congo=t61rcWkgMzE</code></pre>
|
|
|
|
<h3>3.2 Traceparent Header</h3>
|
|
<p>The traceparent HTTP header field identifies the incoming request in a tracing system. It has four fields:</p>
|
|
<ul>
|
|
<li>version</li>
|
|
<li>trace-id</li>
|
|
<li>parent-id</li>
|
|
<li>trace-flags</li>
|
|
</ul>
|
|
|
|
<h4>3.2.1 Header Name</h4>
|
|
<p>Header name: traceparent</p>
|
|
<p>Vendors MUST expect the header name in any case (upper, lower, mixed), and SHOULD send the header name in lowercase.</p>
|
|
|
|
<h4>3.2.2 traceparent Header Field Values</h4>
|
|
<pre><code>
|
|
HEXDIGLC = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" ; lowercase hex character
|
|
value = version "-" version-format
|
|
</code></pre>
|
|
|
|
<h5>3.2.2.1 version</h5>
|
|
<pre><code>version = 2HEXDIGLC ; this document assumes version 00. Version ff is forbidden</code></pre>
|
|
|
|
<h5>3.2.2.2 version-format</h5>
|
|
<pre><code>
|
|
version-format = trace-id "-" parent-id "-" trace-flags
|
|
trace-id = 32HEXDIGLC ; 16 bytes array identifier. All zeroes forbidden
|
|
parent-id = 16HEXDIGLC ; 8 bytes array identifier. All zeroes forbidden
|
|
trace-flags = 2HEXDIGLC ; 8 bit flags. Currently, only one bit is used.
|
|
</code></pre>
|
|
|
|
<h5>3.2.2.3 trace-id</h5>
|
|
<p>This is the ID of the whole trace forest and is used to uniquely identify a distributed trace through a system. It is represented as a 16-byte array, for example, 4bf92f3577b34da6a3ce929d0e0e4736. All bytes as zero (00000000000000000000000000000000) is considered an invalid value.</p>
|
|
|
|
<h5>3.2.2.4 parent-id</h5>
|
|
<p>This is the ID of this request as known by the caller (in some tracing systems, this is known as the span-id, where a span is the execution of a client request). It is represented as an 8-byte array, for example, 00f067aa0ba902b7. All bytes as zero (0000000000000000) is considered an invalid value.</p>
|
|
|
|
<h5>3.2.2.5 trace-flags</h5>
|
|
<p>An 8-bit field that controls tracing flags such as sampling, trace level, etc. These flags are recommendations given by the caller rather than strict rules to follow.</p>
|
|
|
|
<h4>3.2.3 Examples of HTTP traceparent Headers</h4>
|
|
<pre><code>
|
|
Value = 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
|
|
base16(version) = 00
|
|
base16(trace-id) = 4bf92f3577b34da6a3ce929d0e0e4736
|
|
base16(parent-id) = 00f067aa0ba902b7
|
|
base16(trace-flags) = 01 // sampled
|
|
</code></pre>
|
|
|
|
<h3>3.3 Tracestate Header</h3>
|
|
<p>Header name: tracestate</p>
|
|
<p>The main purpose of the tracestate HTTP header is to provide additional vendor-specific trace identification information across different distributed tracing systems and is a companion header for the traceparent field.</p>
|
|
|
|
<h4>3.3.1.2 list</h4>
|
|
<pre><code>
|
|
list = list-member 0*31( OWS "," OWS list-member )
|
|
list-member = (key "=" value) / OWS
|
|
</code></pre>
|
|
|
|
<h4>3.3.1.3.1 Key</h4>
|
|
<pre><code>
|
|
key = simple-key / multi-tenant-key
|
|
simple-key = lcalpha 0*255( lcalpha / DIGIT / "_" / "-"/ "*" / "/" )
|
|
multi-tenant-key = tenant-id "@" system-id
|
|
tenant-id = ( lcalpha / DIGIT ) 0*240( lcalpha / DIGIT / "_" / "-"/ "*" / "/" )
|
|
system-id = lcalpha 0*13( lcalpha / DIGIT / "_" / "-"/ "*" / "/" )
|
|
lcalpha = %x61-7A ; a-z
|
|
</code></pre>
|
|
|
|
<h4>3.3.1.3.2 Value</h4>
|
|
<pre><code>
|
|
value = 0*255(chr) nblk-chr
|
|
nblk-chr = %x21-2B / %x2D-3C / %x3E-7E
|
|
chr = %x20 / nblk-chr
|
|
</code></pre>
|
|
|
|
<h3>3.4 Mutating the traceparent Field</h3>
|
|
<p>A vendor receiving a traceparent request header MUST send it to outgoing requests. It MAY mutate the value of this header before passing it to outgoing requests.</p>
|
|
<p>Allowed mutations:</p>
|
|
<ul>
|
|
<li><strong>Update parent-id</strong>: The value of the parent-id field can be set to the new value representing the ID of the current operation.</li>
|
|
<li><strong>Update sampled</strong>: The value of the sampled field reflects the caller's recording behavior.</li>
|
|
<li><strong>Restart trace</strong>: All properties (trace-id, parent-id, trace-flags) are regenerated.</li>
|
|
<li><strong>Downgrade the version</strong>: Downgrade the version of the header.</li>
|
|
</ul>
|
|
|
|
<h3>3.5 Mutating the tracestate Field</h3>
|
|
<p>Allowed mutations:</p>
|
|
<ul>
|
|
<li><strong>Add a new key/value pair</strong>. The new key/value pair SHOULD be added to the beginning of the list.</li>
|
|
<li><strong>Update an existing value</strong>. Modified keys SHOULD be moved to the beginning (left) of the list.</li>
|
|
<li><strong>Delete a key/value pair</strong>. Any key/value pair MAY be deleted.</li>
|
|
</ul>
|
|
|
|
<h2>4. Processing Model</h2>
|
|
|
|
<h3>4.2 No traceparent Received</h3>
|
|
<p>If no traceparent header is received:</p>
|
|
<ol>
|
|
<li>The vendor checks an incoming request for a traceparent and a tracestate header.</li>
|
|
<li>Because the traceparent header is not received, the vendor creates a new trace-id and parent-id that represents the current request.</li>
|
|
<li>If a tracestate header is received without an accompanying traceparent header, it is invalid and MUST be discarded.</li>
|
|
<li>The vendor SHOULD create a new tracestate header and add a new key/value pair.</li>
|
|
<li>The vendor sets the traceparent and tracestate header for the outgoing request.</li>
|
|
</ol>
|
|
|
|
<h3>4.3 A traceparent is Received</h3>
|
|
<p>If a traceparent header is received:</p>
|
|
<ol>
|
|
<li>The vendor checks an incoming request for a traceparent and a tracestate header.</li>
|
|
<li>Because the traceparent header is present, the vendor tries to parse the version of the traceparent header.</li>
|
|
<li>The vendor MAY validate the tracestate header.</li>
|
|
<li>For each outgoing request the vendor performs the following steps: update parent-id, optionally update sampled flag, optionally modify tracestate.</li>
|
|
</ol>
|
|
|
|
<h2>5. Other Communication Protocols</h2>
|
|
<p>While trace context is defined for HTTP, the authors acknowledge it is also relevant for other communication protocols. Extensions of this specification define the format of trace context serialization and deserialization for other protocols.</p>
|
|
|
|
<h2>6. Privacy Considerations</h2>
|
|
<p>Tracing vendors MUST NOT use traceparent and tracestate fields for any personally identifiable or otherwise sensitive information. The only purpose of these fields is to enable trace correlation.</p>
|
|
|
|
<h2>7. Security Considerations</h2>
|
|
<p>There are two types of potential security risks: information exposure and denial-of-service attacks against the vendor.</p>
|
|
|
|
<h3>7.1 Information Exposure</h3>
|
|
<p>Information in the traceparent and tracestate headers may carry information that can be considered sensitive. Application owners should either ensure that no proprietary or confidential information is stored in tracestate, or they should ensure that tracestate is not present in requests to external systems.</p>
|
|
|
|
<h3>7.2 Denial of Service</h3>
|
|
<p>When distributed tracing is enabled on a service with a public API and naively continues any trace with the sampled flag set, a malicious attacker could overwhelm an application with tracing overhead, forge trace-id collisions that make monitoring data unusable, or run up your tracing bill with your SaaS tracing vendor.</p>
|
|
|
|
<h2>8. Considerations for trace-id field generation</h2>
|
|
|
|
<h3>8.1 Uniqueness of trace-id</h3>
|
|
<p>The value of trace-id SHOULD be globally unique.</p>
|
|
|
|
<h3>8.2 Randomness of trace-id</h3>
|
|
<p>Randomly generated value of trace-id SHOULD be preferred over other algorithms of generating a globally unique identifiers.</p>
|
|
|
|
<h2>B. Glossary</h2>
|
|
<dl>
|
|
<dt>Distributed trace</dt>
|
|
<dd>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.</dd>
|
|
</dl>
|
|
|
|
<h2>C. References</h2>
|
|
<h3>C.1 Normative references</h3>
|
|
<ul>
|
|
<li>[RFC2119] Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. https://www.rfc-editor.org/rfc/rfc2119</li>
|
|
<li>[RFC5234] Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed.; P. Overell. IETF. January 2008. https://www.rfc-editor.org/rfc/rfc5234</li>
|
|
<li>[RFC7230] Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. https://httpwg.org/specs/rfc7230.html</li>
|
|
<li>[RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. https://www.rfc-editor.org/rfc/rfc8174</li>
|
|
</ul>
|
|
|
|
</body>
|
|
</html>
|