Day2 - GPT 陪我讀 W3C Trace Context Ch1
Day3- GPT 陪我讀 W3C Trace Context Ch2
Day4- GPT陪我讀 W3C Trace Context Ch3 追蹤上下文 HTTP 標頭格式 第一部份
Day5- GPT陪我讀 W3C Trace Context Ch3 追蹤上下文 HTTP 標頭格式 第二部份
Day6- GPT陪我讀 W3C Trace Context Ch3 追蹤上下文 HTTP 標頭格式 第三部份
Day7- GPT 陪我讀 W3C Trace Context Ch4
Day8- GPT 陪我讀 W3C Trace Context Ch5-6

繼續看Ch3.3

3.3 Tracestate Header

總結與翻譯：

"tracestate" HTTP header的主要目的是在不同分散式跟踪系統中提供額外的供應商特定跟踪識別資訊，並作為 "traceparent" 欄位的伴隨header。它還描述了請求在多個分散式跟踪圖中的位置。

如果供應商無法解析 "traceparent"，則MUST NOT嘗試解析 "tracestate"。注意，反之則不然：解析 "tracestate" 的失敗MUST NOT影響 "traceparent" 的解析。

3.3.1 Header Name

總結與翻譯：

header名稱：tracestate

為了增加在多個協議之間的互操作性並鼓勵成功整合，您SHOULD保持header名稱的小寫。header名稱是單個單詞，不帶任何分隔符，例如連字符（-）。

供應商MUST在任何情況下（大寫，小寫，混合）預期header名稱，並SHOULD以小寫發送header名稱。

3.3.1.1 tracestate Header Field Values（tracestate header欄位值）

總結與翻譯：

"tracestate" 欄位可能包含鍵中的任何不透明值。"tracestate" MAY作為多個header欄位發送或接收。多個 "tracestate" header欄位MUST按照 RFC7230 第 3.2.2 節的欄位順序進行處理。"tracestate" headerSHOULD在可能的情況下作為單個欄位發送，但MAY分為多個header欄位。當將 "tracestate" 發送為多個header欄位時，MUST根據 RFC7230 進行拆分。接收多個 "tracestate" header欄位時，MUST將其組合成單個header。

此部分使用了 [RFC5234] 的增強 Backus-Naur 表達式（ABNF）表示法，包括 RFC5234 附錄 B.1 中的 DIGIT 規則。它還包括了 RFC7230 第 3.2.3 節的 OWS（可選的空白字符）規則。

DIGIT 規則定義了數字 0-9。

OWS 規則定義了一個可選的空白字符。為了提高可讀性，它用於可能出現零個或多個空白字符的地方。

呼叫者SHOULDSHOLUD將可選的空白生成為單個空格；否則，呼叫者SHOULD NOT生成可選的空白。有關細節，請參閱相應的 RFC。

"tracestate" 欄位值是由逗號（,）分隔的列表成員的列表。列表成員是由等號（=）分隔的鍵 / 值對。忽略列表成員周圍的空格和水平制表符。列表中最多可以有 32 個列表成員。

允許空的和僅空白列表成員。供應商必須接受空的 "tracestate" header，但SHOULD避免發送它們。允許在 "tracestate" 中有空列表成員，因為供應商在發送多個 "tracestate" header時很難識別空值。由於一些供應商在逗號分隔符後自動注入空白，即使在空header的情況下也允許空白字符，出於類似的原因，這是被允許的。

解釋：

這一部分描述了 "tracestate" header的結構和格式。這個header用於在分散式跟踪系統中携帶供應商特定的跟踪資訊。

"tracestate" 可能分為多個欄位或作為單個欄位發送，取決於需要，並且必須遵循 RFC7230 的特定規則。
它使用了特定的符號規則來表示數字和可選的空白字符。
"tracestate" 的值由鍵 / 值對組成，可以有多達 32 個，並且可以包括空的或只包含空白的列表成員。
這些規則允許在解析和處理 "tracestate" 時的柔韌性，特別是在處理不同供應商和系統時。
這些細節為如何在分散式系統中準確解析和處理跟踪資訊提供了指導，並有助於確保跨不同實現和供應商的一致性和互操作性。

3.3.1.2 列表

一個包含兩個列表成員的列表，簡單例子可能看起來像：

vendorname1=opaqueValue1,vendorname2=opaqueValue2.

list  = list-member 0*31( OWS "," OWS list-member )
list-member = (key "=" value) / OWS

列表的標識符是簡短的（最多256個字符）文本標識符。

3.3.1.3 list-members（列表成員）

列表成員包含一個鍵/值對。

3.3.1.3.1 Key鍵

Key用於識別tracestate項目。

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

注意：標識符MUST以小寫字母或數字開header，並且只能包含小寫字母（a-z）、數字（0-9）、下劃線（_）、破折號（-）、星號（*）和正斜杠（/）。

有兩種不同類型的 tracestate 鍵。第一種類型的鍵是由不具有多個租戶的追踪系統使用的簡單鍵。簡單鍵只包含小寫字母、數字、下劃線、破折號、星號和正斜杠。例如：my-tracing-system。

第二種類型的鍵用於多租戶追踪系統，其中每個租戶都需要唯一的 tracestate 項目。多租戶鍵由租戶 ID 後跟 @字符後跟系統 ID 組成。這允許快速和強健的解析。例如，追踪系統 xyz 可以通過搜索所有 @xyz = 的實例輕鬆找到其所有的 tracestate 項目。

解釋說明：

這段文本描述了在分布式追踪中使用的 tracestate header的列表和鍵/值結構。

列表（3.3.1.2）: 描述了如何組織 tracestate 的鍵值對。這裡的列表最多可以有 32 個成員，並且使用 OWS（可選空格）和逗號來分隔。

列表成員（3.3.1.3）: 每個成員都包含一個鍵和一個值，其中鍵用於唯一識別追踪項目。

鍵（3.3.1.3.1）: 鍵可以是簡單鍵，適用於單租戶系統；也可以是多租戶鍵，適用於每個租戶需要唯一tracestate項目的系統。其中，多租戶鍵具有特殊的格式，包括租戶ID和系統ID。

這個結構允許在不同的分布式追踪系統中跨多個廠商共享特定的追踪資訊，有助於增強跨系統的相容性和可操作性。

3.3.1.3.2 Value值

值是一個不透明字符串，包含最多256個可列印的ASCII [RFC0020]字符（即範圍0x20到0x7E），除了逗號（，）和等號（=）。請注意，這也排除了制表符、換行符、回車等。

value    = 0*255(chr) nblk-chr
nblk-chr = %x21-2B / %x2D-3C / %x3E-7E
chr      = %x20 / nblk-chr

3.3.1.4 Combined Header Value（組合header值）

tracestate值是trace圖鍵/值對的連接。

範例：vendorname1=opaqueValue1,vendorname2=opaqueValue2

因為條目代表 trace 中的最後位置，所以每個鍵只允許一個條目。因此，廠商在重新進入其追踪系統時必須覆寫其條目。

例如，如果廠商名稱為 Congo，並且 trace 在他們的系統中開始，然後經過名為 Rojo 的系統，後來返回到 Congo，tracestate 值不會是：

congo=congosFirstPosition,rojo=rojosFirstPosition,congo=congosSecondPosition

相反，條目將被重寫以僅包括最近的位置：

congo=congosSecondPosition,rojo=rojosFirstPosition

3.3.1.5 tracestate 限制：

廠商SHOULD至少傳播合併header部的512個字符。此長度包括分隔列表項目所需的逗號和可選的空白字符（OWS）。

在傳播 512 個字符的 tracestate 可能昂貴的系統中，SHOLUD記錄並解釋傳播的 tracestate header部的最大大小。傳播 tracestate 的成本SHOLUD與為最終用戶啟用的監控方案的價值相衡量。

在由於大小限制而需要截斷 tracestate 的情況下，廠商MUST截斷整個條目。首先SHOLUD刪除長於 128 個字符的條目。然後SHOLUD從 tracestate 的末尾開始刪除條目。請注意，MAY使用其他截斷策略，例如安全列表條目、封鎖列表條目或基於大小的截斷，但是強烈不鼓勵。這些策略降低了各種追踪廠商的互操作性。

解釋說明：

值（3.3.1.3.2）: 描述了值的格式，它是一個包含特定 ASCII 字符範圍的不透明字符串，不包括逗號和等號。

合併header部值（3.3.1.4）: 描述了tracestate的值如何由鍵/值對組合而成，以及如何處理重複的鍵。

tracestate 限制（3.3.1.5）: 描述了 tracestate 的大小限制，包括應該傳播的最小字符數，以及如何處理大小限制引起的截斷。強調了截斷策略的選擇對於不同追踪廠商之間的互操作性可能有重要影響。

這一部分主要涉及追踪header的結構和大小限制，有助於確保不同的追踪系統之間的兼容性和一致性。

3.3.2 HTTP header的示例

單一追踪系統（通用格式）：

tracestate: rojo=00f067aa0ba902b7

多個追踪系統（具有不同格式）：

tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE

3.3.3 tracestate 的版本控制

tracestate的版本由traceparent header的版本前綴定義。如果檢測到更高版本，廠商需要盡其所能嘗試解析tracestate。廠商可以自行決定是否使用部分解析的tracestate鍵/值對。

解釋說明：

tracestate HTTP header部的示例（3.3.2）:

單一追踪系統：只有一個追踪系統的示例，格式很簡單，只有一個鍵值對。
多個追踪系統：具有不同格式的多個追踪系統的示例。在這個示例中，兩個不同的追踪系統用逗號分隔，每個系統都有自己的鍵值對。
tracestate 的版本控制（3.3.3）:

描述了 tracestate 版本的定義，這與 traceparent header部的版本前綴有關。
如果檢測到更高的版本，廠商應嘗試解析 tracestate。
廠商可以自行決定是否使用部分解析的鍵值對，這可能涉及到如何處理不完全符合當前版本的數據。
這一部分通過示例和版本控制指導，提供了如何實施和理解 tracestate 的實際指導，有助於確保跨不同追踪系統的一致性和兼容性。

小總結

到目前為止第 3 章對分散式追踪的核心概念進行了全面的介紹和解釋。

3.1 節強調了遵循一致性和互操作性原則的重要性。
3.2 節描述了 “traceparent” header部，這是定義和理解追踪的基礎。它提供了分散式追踪所需的基本資訊，如追踪 ID 和父 ID。
3.3 節則專注於 “tracestate” header部，解釋了如何存儲和處理有關特定追踪系統的附加資訊。
整個章節通過定義規範和提供實施指南，為分散式追踪提供了一個清晰的框架。這有助於確保不同的追踪系統之間的兼容性和一致性，促進了分散式系統中數據的透明性和可觀察性。