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
Day9- GPT 陪我讀 W3C Trace Context Ch7

CH8 生成 trace-id 欄位的考量

此部分為非規範性內容。

此部分建議當平台或追踪供應商實施 trace-id 生成和傳播演算法時，應考慮的一些建議最佳實踐。這些做法將確保不同系統更好的互操作性。

8.1 trace-id 的唯一性

trace-id的值SHOULD具有全局唯一性。這個字段通常用於獨特地識別分散式追踪。分散式追踪經常跨越各種組件，例如雲服務。雲服務往往為各種客戶提供服務，並具有非常高的請求吞吐量。所以，即使在本地唯一性看起來像是一個好的解決方案時，trace-id的全球唯一性也是很重要的。

8.2 trace-id 的隨機性

相對於生成全球唯一識別符的其他算法，SHOULD優先考慮隨機生成的 trace-id 值。trace-id 的隨機性解決了暴露不希望的信息的一些安全和隱私問題。隨機性還允許追踪供應商基於 trace-id 字段值來做取樣決策，並避免傳播額外的取樣上下文。

如下一節所示，對於 trace-id，將 "唯一性uniqueness" 和 "隨機性randomness" 攜帶在 trace-id 的正確部分對於與某些現有系統更好的互操作性是很重要的。

總結：
為了保障安全和隱私，並增強系統之間的互操作性，trace-id 應該具有隨機性。這不僅有助於避免不必要的信息暴露，還使追踪供應商能夠更有效地進行取樣決策。

8.3 處理內部標識符較短的兼容平台的 trace-id

有些追踪系統使用的trace-id 短於 16 個bytes，但仍希望採用這一規範。

如果這樣的系統能夠傳播一個完全符合規範的 trace-id，即使它內部仍需要一個較短的、不符合規範的標識符，那麼建議該系統使用 tracestate header來傳播額外的內部標識符。然而，如果一個系統更傾向於使用內部標識符作為一個完全符合規範的 trace-id 的基礎，那麼它SHOULD將其納入到 trace-id 的最右部分。例如，追踪系統可能接收到 234a5bcd543ef3fa53ce929d0e0e4736 作為一個 trace-id，但它內部會使用 53ce929d0e0e4736 作為標識符。

總結：
對於那些使用較短 trace-id 的追踪系統，建議它們要麼使用 tracestate 標頭傳播其內部標識符，要麼將其納入到符合規範的 trace-id 的右部。這確保了兼容性和追踪的一致性。

8.4 與使用較短標識符的現有系統互操作

有一些追踪系統無法傳播整個16bytes的 trace-id。為了更好地在完全兼容的系統和這些現有系統之間互操作，建議採用以下做法：

1. 當系統創建出站消息並需要從較短的標識符生成完全兼容的 16 bytes trace-id 時，它SHOULD在原始標識符的左側填充零。例如，標識符 53ce929d0e0e4736 應被轉換為 trace-id 值 000000000000000053ce929d0e0e4736。
2. 當系統接收入站消息並需要將 16 bytes的 trace-id 轉換為較短的標識符時，SHOULD使用 trace-id的最右邊部分作為此標識符。例如，如果收到的請求中的 trace-id 值為 234a5bcd543ef3fa53ce929d0e0e4736，追踪系統SHOULD使用值為 53ce929d0e0e4736 的標識符。

當追踪系統將其他分佈式追踪上下文傳播格式轉換為 W3C Trace Context 時，預期會進行類似的轉換。在轉換為 16 bytes的 trace-id 時，較短的標識符SHOULD在左側填充零，且 trace-id 的最右邊部分SHOULD作為較短的標識符使用。

需要注意的是，許多現有系統無法傳播整個trace-id，也不會傳播 tracestate header。但是，這樣的系統仍然可以使用 tracestate header來傳播此系統所知道的額外數據。例如，有些系統使用兩個標誌來指示是否需要記錄分佈式追踪。在這種情況下，可以將一個標誌作為 traceparent 標頭的採樣標誌發送，並使用 tracestate 來發送和接收額外的標誌。兼容的系統會沿著所有其他鍵 / 值對傳播這個標誌。不支持 tracestate 傳播的現有系統將從 tracestate 中截斷所有額外的值，並只傳遞那個標誌。

總結：
與使用較短 trace-id 的系統進行互操作是一個重要的考慮因素。透過特定的方法，如左側填充零和使用 trace-id 的右側，可以確保跟完全兼容的系統之間有良好的互操作性。此外，tracestate 標頭提供了一種在不同系統間傳播額外數據的方式，即使某些系統可能不支援完整的 trace-id 或 tracestate 傳播。

摘要回顧

考慮 trace-id 欄位生成：本節提供了建議，幫助平台或追踪供應商實施 trace-id 的生成和傳播算法，以確保不同系統之間的更好互操作性。

trace-id 的唯一性：trace-id 應該是全局唯一的，以確保在分佈式追踪中進行獨特的識別，尤其是當追踪跨多個組件，如雲服務時。

trace-id 的隨機性：建議隨機生成的 trace-id 值，因為它可以解決暴露不必要資訊的安全和隱私問題。此外，這種隨機性也允許追踪供應商基於 trace-id 字段值做取樣決策，而不需要傳播額外的取樣上下文。

為有較短內部標識符的兼容平台處理 trace-id：某些追踪系統使用的 trace-id 比16字節短。這些系統可以在 tracestate 標頭中傳播額外的內部標識符，或者將其整合到 trace-id 的最右側。

與使用較短標識符的現有系統互操作：為了與使用較短標識符的系統進行互操作，建議的做法是在生成或接收 trace-id 時填充零或取其右側部分。tracestate header也可以在這些系統中用於傳播其他數據。

總結：

ch8 主要關於 trace-id 的生成和傳播的建議和最佳實踐。核心主題是確保 trace-id 的全球唯一性和隨機性，以確保安全性和效率。同時，本章還考慮到了如何在有較短內部標識符的追踪系統中使用和傳播 trace-id，以及如何確保這些系統與完全符合 W3C Trace Context 的系統之間的互操作性。