分散式追蹤常見問題

Istio 使用基於 Envoy 的追蹤與分散式追蹤系統整合。透過基於 Envoy 的追蹤整合，應用程式負責轉發後續外送請求的追蹤標頭。

您可以在 Istio 分散式追蹤（Jaeger、Lightstep、Zipkin）任務和 Envoy 追蹤文件中找到更多資訊。

Istio 能夠報告網格內工作負載之間通訊的追蹤範圍。然而，為了將各種追蹤範圍拼接在一起以獲得流量流的完整視圖，應用程式必須在傳入和傳出請求之間傳播追蹤上下文。

特別是，Istio 依賴應用程式傳播 B3 追蹤標頭，以及 Envoy 產生的請求 ID。這些標頭包括

• x-request-id
• x-b3-traceid
• x-b3-spanid
• x-b3-parentspanid
• x-b3-sampled
• x-b3-flags
• b3

如果您使用的是 Lightstep，您還需要轉發以下標頭

• x-ot-span-context

如果您使用的是 OpenTelemetry 或 Stackdriver，您還需要轉發以下標頭

• traceparent
• tracestate

標頭傳播可以透過客戶端程式庫（例如Zipkin或Jaeger）來完成。也可以按照分散式追蹤任務中的說明手動完成。

對於基於 Envoy 的追蹤整合，Envoy（Sidecar 代理）代表被代理的應用程式直接將追蹤資訊發送到追蹤後端。

Envoy

• 在請求流經代理時，為請求產生請求 ID 和追蹤標頭（即 X-B3-TraceId）
• 根據請求和回應元資料（即回應時間）為每個請求產生追蹤範圍
• 將產生的追蹤範圍發送到追蹤後端
• 將追蹤標頭轉發到被代理的應用程式

Istio 支援 Lightstep 和 Zipkin 的基於 Envoy 的整合，以及所有與 Zipkin API 相容的後端，包括Jaeger。

啟用追蹤的最小 Istio 設定檔是 Istio 與 Zipkin 相容後端整合所需的全部內容。

如果請求未提供，Istio Sidecar 代理 (Envoy) 會產生初始的標頭。

儘管 Istio Sidecar 會處理相關應用程式執行個體的傳入和傳出請求，但它沒有隱含的方法將傳出請求與導致它們的傳入請求關聯起來。只有當應用程式將相關資訊（即標頭）從傳入請求傳播到傳出請求時，才能實現這種關聯。標頭傳播可以透過客戶端程式庫或手動完成。在在 Istio 中使用分散式追蹤需要什麼？中提供了進一步的討論。

自 Istio 1.0.3 起，追蹤的採樣率已在 default 配置設定檔中降低至 1%。這表示 Istio 捕獲的 100 個追蹤實例中只有 1 個會報告給追蹤後端。demo 設定檔中的採樣率仍設定為 100%。請參閱此部分以取得有關如何設定採樣率的更多資訊。

如果您仍然沒有看到任何追蹤資料，請確認您的連接埠符合 Istio 連接埠命名慣例，並且已公開適當的容器連接埠（例如，透過 pod spec），以允許 Sidecar 代理 (Envoy) 捕獲流量。

如果您只看到與出口代理相關的追蹤資料，而不是入口代理，則可能仍與 Istio 連接埠命名慣例有關。從 Istio 1.3 開始，會自動偵測傳出流量的協定。

Istio（透過 Envoy）目前支援基於百分比的追蹤產生採樣策略。請參閱此部分以取得有關如何設定此採樣率的更多資訊。

如果您已安裝啟用追蹤的 Istio，您可以透過以下方式停用它

# Fill <istio namespace> with the namespace of your istio mesh.Ex: istio-system
TRACING_POD=`kubectl get po -n <istio namespace> | grep istio-tracing | awk '{print $1}'`
$ kubectl delete pod $TRACING_POD -n <istio namespace>
$ kubectl delete services tracing zipkin   -n <istio namespace>
# Now, manually remove instances of trace_zipkin_url from the file and save it.

然後按照分散式追蹤任務的清理部分中的步驟執行。

如果您完全不需要追蹤功能，則在安裝 Istio 時停用追蹤。

為此，您必須使用 Zipkin 相容實例的完整網域名稱。例如：zipkin.mynamespace.svc.cluster.local。

Istio 目前不支援發布/訂閱和事件匯流排協定。對這些技術的任何使用都是盡力而為，並且可能會發生中斷。