### 跟蹤 #### 概述 分布式跟蹤使開發人員可以在大型面向服務的體系結構中獲得調用流的可視化。在理解序列化，并行性和延遲來源方面，這是非常寶貴的。Envoy支持系統范圍與跟蹤相關的三個功能： - **請求ID生成**：Envoy將在需要時生成UUID并填充`x-request-id` HTTP頭。 應用程序可以轉發`x-request-id`頭以進行統一日志記錄以及跟蹤。 - **外部跟蹤服務集成**：Envoy支持可插入的外部跟蹤可視化提供程序。 目前，Envoy支持[LightStep](http://lightstep.com/)，[Zipkin](http://zipkin.io/)或Zipkin兼容后端（例如[Jaeger](https://github.com/jaegertracing/)）。但是，并不支持其他調用跟蹤機制。 - **客戶端跟蹤ID加入**：用于將不可信`x-client-trace-id`請求ID頭連接到可信的內部`x-request-id`。 #### 如何啟動跟蹤 處理請求的HTTP連接管理器必須設置跟蹤對象。有幾種方法可以啟動跟蹤： - 外部客戶端通過`x-client-trace-id`頭域字段請求。 - 通過`x-envoy-force-trace`頭域字段請求內部服務。 - 通過設置隨機采樣進行采樣。 路由過濾器還可以通過`start_child_span`選項為出站調用發起跟蹤。 Envoy提供報告有關網格中服務之間通信的跟蹤信息的功能。但是，為了能夠關聯調用流中各個代理生成的跟蹤信息，服務必須在入站和出站請求之間傳播特定的跟蹤上下文。 無論使用哪個跟蹤機制，該服務都應該傳播`x-request-id`，以便使得在被調用服務日志中記錄相關信息。 跟蹤機制還需要支持額外的上下文記錄，以便開發者更加容易理解（如：邏輯工作單元）之間的父/子關系。這可以通過在服務本身內直接使用LightStep（通過OpenTracing API）或Zipkin tracer來實現，以從入站請求中提取跟蹤上下文，并將其注入到任何后續的出站請求中。這種方法還可以使服務創建額外的spans，描述在服務內部完成的工作，這在檢查端到端跟蹤時可能是有用的。 跟蹤上下文可以由服務手動傳播： - 當使用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-ot-span-context` HTTP頭。 注意：分布式跟蹤社區中正在進行工作以定義跟蹤上下文傳播的標準。 一旦采用了合適的方法，用于傳播Zipkin跟蹤上下文的非標準單頭`x-ot-span-context`的使用將被替換。 #### 每個跟蹤包含哪些數據 端到端跟蹤由一個或多個spans組成。spans表示具有開始時間和持續時間的邏輯工作單元，并且可以包含與其關聯的元數據。 Envoy生成的每個spans包含以下數據： - 通過`--service-cluster`設置始發服務集群。 - 開始時間和請求的持續時間。 - 始發主機通過`--service-node`設置。 - 通過`x-envoy-downstream-service-cluster`頭設置下游集群。 - HTTP網址。 - HTTP方法。 - HTTP響應代碼。 - 跟蹤系統中的特定元數據。 范圍還包括一個名稱（或操作），默認情況下被定義為被調用的服務的主機。但是，這可以使用路線上的裝飾器來定制。該名稱也可以使用`x-envoy-decorator-operation`頭域字段替代。 Envoy自動發送spans跟蹤收集。根據跟蹤收集器的不同，使用通用信息（如全局唯一請求標識`x-request-id`（LightStep）或跟蹤標識配置（Zipkin））將多個spans拼接在一起。 關于如何在Envoy中設置跟蹤詳細信息，請參考手冊。 - [v1 API參考](../../v1APIreference/Tracing.md) - [v2 API參考](../../v2APIreference/Bootstrap.md) ### 返回 - [架構介紹](../Architectureoverview.md) - [簡介](../../Introduction.md) - [首頁目錄](../../README.md)