Istio可觀察性--Tracing篇

Istio爲網格內的全部服務通訊生成詳細的遙測。這種遙測功能提供了服務行爲的可觀察性,使運維同窗能夠對應用程序進行故障排除,維護和優化,而不會給服務開發人員帶來任何額外負擔。經過Istio,能夠全面瞭解受監控的服務如何與其餘服務以及與Istio組件自己進行交互。後端

Istio生成如下遙測類型,以提供總體服務網格可觀察性:網絡

  • Metrics. Istio根據監控的四個「黃金信號」(延遲,流量,錯誤和飽和度)生成一組服務指標。 Istio還提供了網格控制平面的詳細指標。還提供了基於這些指標構建的一組默認的網格監控儀表板。
  • Distributed Traces. Istio爲每種服務生成分佈式跟蹤範圍,從而使咱們能夠詳細瞭解網格中的調用流程和服務依賴性。
  • Access Logs. 當流量流入網格內的服務時,Istio能夠生成每一個請求的完整記錄,包括源和目標元數據。該信息使咱們可以審覈服務行爲,能夠到單個工做負載實例級別。

本文咱們主要講述Tracing。架構

Tracing 簡介

爲何須要tracing?app

在微服務架構中,當多個服務相互調用時,故障排查變得再也不容易。故障的根因是什麼,爲何請求的性能不佳,哪一個服務是調用堆棧中的瓶頸,請求之間的網絡延遲是多少?運維

有了分佈式跟蹤,就能夠可視化完整的調用堆棧,查看哪一個服務調用了哪一個服務,每一個調用花費了多長時間以及它們之間的網絡等待時間是多少。能夠知道請求失敗的位置或哪一個服務花費太多時間來響應。分佈式

Istio對tracing的支持和配置

Istio利用Envoy的分佈式跟蹤功能提供開箱即用的跟蹤集成。具體來講,Istio提供了安裝各類跟蹤後端並配置代理以自動向其發送跟蹤範圍的選項。ide

默認狀況下,禁用Istio跟蹤。您能夠經過傳遞tracing.enabled安裝選項來啓用它。 Istio還支持多種跟蹤平臺,例如Jaeger,Zipkin和LightStep [x] PM。要配置適當的平臺,能夠使用tracing.provider安裝選項。
須要注意的重要一點是Jaeger僅使用1%的流量進行採樣。若是要增長該數量,則還應該配置pilot.traceSampling微服務

Trace 上下文傳播性能

查找多個HTTP請求之間的相關性的一種方法是使用相關性ID。該ID應該傳遞給全部請求,以便跟蹤平臺知道哪些請求屬於同一請求。測試

儘管Istio利用Envoy的分佈式跟蹤功能提供開箱即用的跟蹤集成,可是其實這是一個誤解,咱們的應用程序須要作一些工做。應用程序須要傳播如下header:

  • x-request-id
  • x-b3-traceid
  • x-b3-spanid
  • x-b3-parentspanid
  • x-b3-sampled
  • x-b3-flags
  • x-ot-span-context

Istio Sidecar內的Envoy代理接收這些標頭,並將它們傳遞給配置的tracing系統。

實戰

爲何選擇Jaeger?

實際生產環境中,咱們選擇Jaeger。受到Dapper和OpenZipkin啓發的Jaeger是由Uber Technologies做爲開源發佈的分佈式跟蹤系統。它用於監視和診斷基於微服務的分佈式系統,包括:

  • 分佈式上下文傳播
  • 分佈式事務監控
  • 根本緣由分析
  • 服務依賴分析
  • 性能/延遲優化

此外Jaeger 是一個CNCF基金會項目,而且已經畢業。相對其餘追蹤系統,社區活躍,沒有鎖定風險。

Jaeger部署架構

Jaeger能夠做爲多合一二進制(其中全部Jaeger後端組件都在單個進程中運行)進行部署,該部署主要用於測試環境。

生產環境使用可擴展的分佈式系統進行部署,以下所述。有兩個主要的部署選項:

  1. Collectors 直接寫數據到存儲
  2. Collectors 寫數據到kafka,而後由ingester組件轉儲數據

咱們生產環境使用的是第一種部署架構。而且選用的存儲後端是Cassandra。

展現效果

Jaeger提供了UI去展現trace結果。具體效果以下:

咱們在使用istio過程當中,當咱們的服務調用沒有那麼複雜的時候,能夠選擇不啓用tracing。整個tracing系統的成本不低,固然咱們能夠經過下降抽樣率來下降成本。 此外,正如前面提到的,並非真正意義上的無侵入。咱們須要業務代碼作一些工做。
相關文章
相關標籤/搜索