追蹤
概觀
分散式追蹤允許開發人員取得大型服務導向架構中呼叫流程的可視化呈現。它對於理解序列化、並行性和延遲來源非常寶貴。Envoy 支援與系統範圍追蹤相關的三個功能
請求 ID 產生：Envoy 會在需要時產生 UUID，並填入 x-request-id HTTP 標頭。應用程式可以轉發 x-request-id 標頭，以進行統一記錄以及追蹤。可以使用擴充功能在每個 HTTP 連線管理員 的基礎上設定此行為。
用戶端追蹤 ID 加入：x-client-trace-id 標頭可用於將不受信任的請求 ID 加入到受信任的內部 x-request-id。
外部追蹤服務整合：Envoy 支援可外掛的外部追蹤可視化提供者，分為兩個子群組
如何啟動追蹤
處理請求的 HTTP 連線管理員必須設定 tracing 物件。有多種方法可以啟動追蹤
由外部用戶端透過 x-client-trace-id 標頭。
由內部服務透過 x-envoy-force-trace 標頭。
透過 random_sampling 執行階段設定隨機取樣。
追蹤內容傳播
Envoy 提供報告網格中服務之間通訊的追蹤資訊的功能。但是，為了能夠關聯呼叫流程中各個代理產生的追蹤資訊，服務必須在傳入和傳出請求之間傳播某些追蹤內容。
無論使用哪個追蹤提供者，服務都應傳播 x-request-id，以便關聯所叫用服務的記錄。
注意
Envoy 的請求 ID 實作是可擴展的，預設為 UuidRequestIdConfig 實作。可以在 HTTP 連線管理員 欄位中提供此擴充功能的設定（請參閱該欄位的說明文件以取得範例）。預設實作將修改請求 ID UUID4，以將最終追蹤原因封裝到 UUID 中。此功能允許在 Envoy 車隊中進行穩定取樣，如 x-request-id 標頭說明文件中所述。但是，追蹤原因封裝可能會破壞必須維護的外部產生請求 ID。pack_trace_reason 欄位可用於停用此行為，但代價是也會停用部署中的穩定追蹤原因傳播和相關功能。
注意
Envoy 的取樣原則預設由 x-request-id 的值決定。但是，此類取樣原則僅對 Envoy 車隊有效。如果車隊中存在非 Envoy 的服務代理，則會執行取樣，而不考慮該代理的原則。對於包含多個服務代理的網格（例如此網格），更有效的方法是繞過 Envoy 的取樣原則，並根據追蹤提供者的取樣原則進行取樣。可以透過將 use_request_id_for_trace_sampling 設定為 false 來達成此目的。
追蹤提供者還需要額外的內容，才能了解跨度（工作邏輯單元）之間的父/子關係。這可以透過在服務本身內直接使用 LightStep（透過 OpenTelemetry API）或 Zipkin 追蹤器來達成，以從傳入請求中提取追蹤內容並將其插入任何後續的傳出請求中。這種方法還可以讓服務建立額外的跨度，描述在服務內部完成的工作，這在檢查端對端追蹤時可能很有用。
或者，追蹤內容可以由服務手動傳播
使用 LightStep 追蹤器時，Envoy 依賴服務來傳播 x-ot-span-context HTTP 標頭，同時將 HTTP 請求傳送到其他服務。
使用 Zipkin 追蹤器時，Envoy 依賴服務來傳播 B3 HTTP 標頭（x-b3-traceid、x-b3-spanid、x-b3-parentspanid、x-b3-sampled 和 x-b3-flags）。x-b3-sampled 標頭也可以由外部用戶端提供，以啟用或停用特定請求的追蹤。此外，還支援單一 b3 標頭傳播格式，這是一種更壓縮的格式。
使用 Datadog 追蹤器時，Envoy 依賴服務來傳播 Datadog 特有的 HTTP 標頭（x-datadog-trace-id、x-datadog-parent-id、x-datadog-sampling-priority）。
使用 SkyWalking 追蹤器時，Envoy 依賴服務來傳播 SkyWalking 特有的 HTTP 標頭（sw8）。
使用 AWS X-Ray 追蹤器時，Envoy 依賴服務來傳播 X-Ray 特有的 HTTP 標頭（x-amzn-trace-id）。
每個追蹤包含哪些資料
端對端追蹤由一個或多個跨度組成。跨度表示具有開始時間和持續時間的工作邏輯單元，並且可以包含與之相關聯的中繼資料。Envoy 產生的每個跨度都包含以下資料
透過
--service-cluster設定的原始服務叢集。請求的開始時間和持續時間。
透過
--service-node設定的原始主機。透過 x-envoy-downstream-service-cluster 標頭設定的下游叢集。
HTTP 請求 URL、方法、協定和使用者代理。
透過 custom_tags 設定的其他自訂標籤。
上游叢集名稱、可觀測性名稱和位址。
HTTP 回應狀態碼。
GRPC 回應狀態和訊息（如果有的話）。
當 HTTP 狀態為 5xx 或 GRPC 狀態不是「OK」且表示伺服器端錯誤時的錯誤標籤。有關 GRPC 狀態碼的詳細資訊，請參閱 GRPC 的說明文件。
追蹤系統特定的中繼資料。
這個 span 也包含一個名稱（或操作），預設情況下定義為被調用服務的主機。但是，可以使用路由上的 config.route.v3.Decorator 來自訂此名稱。也可以使用 x-envoy-decorator-operation 標頭覆寫此名稱。
Envoy 會自動將 span 發送到追蹤收集器。根據追蹤收集器的不同，多個 span 會使用通用資訊（例如，全域唯一請求 ID x-request-id（LightStep）或追蹤 ID 設定（Zipkin 和 Datadog））串連在一起。有關如何在 Envoy 中設定追蹤的更多資訊，請參閱 v3 API 參考資料。
Baggage
Baggage 提供一種機制，使資料在整個追蹤過程中都可用。雖然標籤等中繼資料通常會以頻外方式傳達給收集器，但 baggage 資料會被注入到實際的請求上下文中，並在請求期間可供應用程式使用。這使得中繼資料可以透明地從請求的開始傳輸到整個網格，而無需依賴應用程式特定的修改來進行傳播。有關 baggage 的更多資訊，請參閱 OpenTelemetry 的文件。
追蹤供應商對取得和設定 baggage 的支援程度各不相同
Lightstep（以及任何符合 OpenTelemetry 標準的追蹤器）可以讀取/寫入 baggage
Zipkin 的支援尚未實作
X-Ray 和 OpenCensus 不支援 baggage
不同類型的 span
如前一段所述，一個追蹤由一個或多個 span 組成，這些 span 可能具有不同的類型。SkyWalking、ZipKin 和 OpenTelemetry 等追蹤系統提供相同或相似的 span 類型。最常見的類型是 CLIENT 和 SERVER。CLIENT 類型 span 由客戶端為發送到伺服器的請求產生，而 SERVER 類型 span 由伺服器為從客戶端接收的請求產生。
一個基本的追蹤鏈如下面的程式碼片段所示。通常，伺服器 span 的父 span 應該是客戶端 span。鏈中的每個跳躍都必須確保 span 類型的正確性。
-> [SERVER -> CLIENT] -> [SERVER -> CLIENT] -> ...
App A App B
Envoy 的不同模式
由於 Envoy 在服務網格中被廣泛用作 sidecar，因此了解 Envoy 的不同追蹤模式非常重要。
在第一種模式中，Envoy 被用作 sidecar。sidecar 及其相關的應用程式被視為追蹤鏈中的單個跳躍。如果使用具有類型 span 的追蹤系統，理想的追蹤鏈可能如下面的程式碼片段所示。
-> [[SERVER (inbound sidecar) -> App -> CLIENT (outbound sidecar)]] -> ...
App
如您所見，在第一種模式下，入站 sidecar 將始終產生 SERVER span，而出站 sidecar 將始終產生 CLIENT span。應用程式不會產生任何 span，但只會傳播追蹤上下文。
在第二種模式中，Envoy 被用作閘道。或者，Envoy 可以用作 sidecar，但在這種情況下，sidecar 及其應用程式被視為追蹤鏈中的單獨跳躍。如果使用具有類型 span 的追蹤系統，理想的追蹤鏈可能如下面的程式碼片段所示。
-> [SERVER -> CLIENT] -> [SERVER -> CLIENT] -> [SERVER -> CLIENT] -> [SERVER -> CLIENT] -> ...
Gateway Inbound Sidecar App Outbound Sidecar
如您所見，在第二種模式下，Envoy 將為下游請求產生 SERVER span，並為上游請求產生 CLIENT span。應用程式也可以為其自身的工作產生 span。
要啟用此模式，請將 spawn_upstream_span 明確設定為 true。這會告訴追蹤供應商為上游請求產生 CLIENT span，並將 Envoy 視為追蹤鏈中的獨立跳躍。