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
繼續看3.4 ~ 3.5
接收到 traceparent
請求header的供應商MUST將其發送到傳出請求。在將其傳遞到傳出請求之前,它MAY改變此頭部的值。
如果在傳播之前沒有更改 traceparent
字段的值,那麼 tracestate
也MUST NOT修改。通過代理等通過型服務通常實現未修改的header傳播。這種行為也可以在當前不收集分佈式追踪信息的服務中實現。
以下是允許的變更:
parent-id
: 可以將 parent-id 欄位的值設置為代表當前操作的新值。這是最典型的變更,應被視為默認。sampled
: sampled 欄位的值反映了調用方的記錄行為:追蹤資料被丟棄或可能已脫機記錄。可以通過切換標誌來指示這一點。這個變更讓下游供應商了解其父信息被記錄的可能性。在更新 sampled
標誌時,必須將 parent-id
欄位設置為新值。trace-id
、parent-id
、trace-flags
)都重新生成。這個變更用於被定義為安全網絡前門的服務,並消除了潛在的拒絕服務攻擊表面。供應商SHOULD在重新啟動 traceparent 時清理 tracestate 集合。在少數情況下,重新啟動後必須保留原始的 tracestate 條目。這通常發生在跟踪流程的某個時刻追踪 ID 被恢復,例如當它離開安全網絡時。然而,這SHOULD是一個明確的決定,而不是默認行為。00
)定義了供應商接收到更高版本的 traceparent
header時的行為。在這種情況下,第一個變更是降級header的版本。允許與此變更結合的其他變更。供應商MUST NOT對 traceparent
header進行任何其他變更。
接收 tracestate
請求header的供應商MUST將其發送到傳出請求。在傳遞到傳出請求之前,MAY改變此header的值。在變更 tracestate
時,MUST保留未修改的鍵 / 值對的順序。SHOULD將修改的鍵移至列表的開頭(左側)。
以下是允許的變更:
tracestate
鍵以應對隱私和安全問題。第二個場景是對長 tracestate
的截斷。3.1 追蹤header欄位
這一節解釋了追蹤header欄位的結構和細節,它由版本、追踪 ID、父 ID 和追踪標志組成。這些欄位用於在分散式追踪中確定特定操作的位置和狀態。
3.2 追蹤狀態header欄位
追蹤狀態header欄位用於儲存供應商特定的信息,以支持分散式追蹤。這一節定義了這些欄位的細節,包括如何處理多個追蹤狀態header欄位的情況。
3.3 追蹤狀態的結構
這部分描述了追蹤狀態的結構,包括如何使用列表和列表成員來表示追蹤狀態。它也解釋了簡單鍵和多租戶鍵的用法,以及值的結構和限制。總體而言,這部分為追蹤狀態提供了詳細的結構規範。
3.4 改變追蹤parent header欄位
這一節詳細描述了供應商如何在收到trace parent header欄位後處理和可能修改它。列出了允許的變更,例如更新父 ID、更新取樣值、重新開始追蹤、降級版本等。重要的是,供應商不得對追蹤父頭字段進行任何其他變更。
3.5 改變追蹤狀態header欄位
最後一節闡述了供應商如何處理和可能改變trace state header欄位。它解釋了允許的變更,如添加新的鍵 / 值對、更新現有值、刪除鍵 / 值對等。
第 3 章集中闡述了trace parent header欄位和trace state header欄位的結構和操作。透過詳細解釋如何組織、解析和可能改變這些欄位,這一章為分散式追蹤提供了關鍵的規範。這有助於確保分散式系統中的操作能夠被準確地識別和追蹤,促進了不同供應商和系統之間的協同工作和互操作性。