idou老師教你學istio2：監控能力介紹

我們知道每個pod內都會有一個Envoy容器，其具備對流入和流出pod的流量進行管理，認證，控制的能力。Mixer則主要負責訪問控制和遙測資訊收集。

如拓撲圖所示，當某個服務被請求時，首先會請求istio-policy服務，來判定是否具備訪問資格，若具備資格則放行反之則請求不會被下發到服務。這一切的訪問資訊，都會被記錄在Envoy中，之後會上報給mixer作為原始資料。遙測資料的收集及其他功能完全是靈活可控的，你既可以配置新的收集指標和日誌，也可以完全禁用這些功能。

1.Prometheus的應用和指標介紹

Prometheus是一款開源的監控和告警系統，2016年加入CNCF，以其靈活的檢索語言，高效的資料儲存方式以及多維度的資料模型使得越來越多的人使用。Istio自0.8開始就預設的將Prometheus包含在內，我們可以通過查詢service或者pod看到普羅的執行狀態和地址。點開Prometheus介面，UI十分簡潔明瞭。

使用者在Expression內輸入想要查詢資料的表示式，並且再輸入的過程中，普羅還會在已有的指標中做出提示方便使用者查詢。我們輸入一個簡單的查詢表示式istio_requests_total,點選Execute，在圖形介面中，將滑鼠放到圖中的折線可以看到請求的詳細資訊。

詳細資訊中的每一項都可以作為選定參考指標的特性，例如我們需要查詢返回值為200的productpage請求總數，就可以在之前的表示式中新增大括號和限定條件。

Istio支援和允許使用者自己定義新的遙測資料，並且在官網->任務->遙測->收集指標和日誌中有詳細的描述。使用者可以自定義需要的監控指標進而可以再普羅檢視監控資料結果。

2.Jaeger UI的使用和介紹

Istio配合jaeger可以解決端到端的分散式追蹤問題。Jaeger於2017年9月成為CNCF的成員。Jaeger是一款開源的分散式追蹤系統，由Google Dapper和OpenZipkin社群聯合推動。

Jager主要可以使用在微服務的架構上來完成分散式上下文廣播，分散式事務監控，根因分析，服務依賴關係分析，效能/延遲優化等功能。

Jaeger的介面極其簡潔，在首頁面選擇你想了解的服務（productpage）以及選擇你想觀測的時間範圍（過去兩天），而後點選find trace按鈕，頁面就會顯示過去兩天內訪問productpage的所有trace。點選trace的名字，則會跳轉到詳情介面。

這個介面中你可以看到每個請求可能會分為不止一個的子請求，以及這個請求的處理時間。例如我們訪問productpage，productpage會請求details和reviews這兩個服務，那麼初始的請求就會分為兩個子請求，一個請求details的內容另一個請求reviews的內容。Details部分的請求總耗時4.99ms，reviews部分的請求耗時5.61ms。內容返回並處理後，整個productpage的請求耗時21.32ms。這個詳情介面不僅會體現每個請求的耗時也反映服務之間的呼叫關係。根據istio官方給出的解釋，我們知道istio proxy根據http部分headers來歸納和合並請求的。

對於一個結構複雜，流量龐大的服務網格，追蹤所有的呼叫不但不利於收集有效資料，還會造成冗餘，浪費資源等問題，所以在制定監控服務的時候也需要去設定其取樣頻率。對於Bookinfo這種示例型應用，我們的取樣率可以設的高一點，對於大型應用就要進行適當的降低。

調整取樣率一共有兩種方式。

•在建立服務網格之前，我們可以提前設定好取樣頻率，在Helm模板的values.yaml檔案中，pilot內的traceSampling屬性可以對取樣頻率進行修改。

開啟istio/chart/pilot/templates/deployment.yaml可以看到一個簡單的賦值過程。

•正在執行的服務網格，對deployment istio-pilot進行編輯。首先檢視所有的deployment：

然後對其進行編輯，搜尋PILOT_TRACE_SAMPLING這個屬性，並對其值進行修改：

我們先開啟jaeger UI確定過去一個小時沒有任何對productpage的訪問。

而後將PILOT_TRACE_SAMPLING的值從原有的100改為50。修改並儲存後會有提示資訊顯示istio-pilot已經被修改。

稍等片刻後，我們使用指令碼curl productpage10次。再次在jaeger UI上選擇productpage選擇過去一小時，點選Find Trace，會發現這次只檢測到4個trace。我們在用相同的指令碼再執行一次，發現檢測到10個trace。至此我們一共curl product page 20次總共獲得10次 trace，符合總次數的50%。

現在我們用相同的方法，將PILOT_TRACE_SAMPLING改為100%並且稍等片刻。使用相同的指令碼curl10次product page，再點選Find trace，現在總共有20個Trace，也就是先前的10個trace加上後來curl的10次，證明 PILOT_TRACE_SAMPLING修改完畢會採集所有的請求。

3.華為雲istio服務中簡明監控介紹

在元件詳情介面中除去CPU使用率，記憶體使用這種基本的監控外，華為雲提供了另外兩項簡明流量監控，分別是RPS(平均處理請求次數)和RT（平均響應時延）。RPS以分鐘基本時間單位，縱軸則以處理請求次數為單位，使用者可以直觀的看到自己的應用單位時間內需要處理的請求數量。若RPS過高，則使用者可以適當的採用相應措施，報障請求的高效處理。

RT也是以分鐘為單位，但是縱軸則是該時間段內平均的請求響應時間。如果個別時間段請求時延過高，使用者則需要對自己服務進行分析。

元件詳情這個介面更多的還是提供一個粗粒度的流量監控，將應用的工作關鍵資訊最直接，最明確的呈現給使用者。方便使用者對自己的應用，資源，服務規劃進行調整和改進。在今後，華為雲會提供維度更多的監控，分析等服務。

Istio提供很多即插即用的服務，使用者不需要修改自己的程式碼，也不需要重新構建自己的應用便可以直接享用istio帶來的“紅利”。視覺化的監控服務，可修改的監控內容，可以更好地讓使用者瞭解自己應用的工作狀態。本文只介紹了入門級的istio監控內容，除上文內容外，監控服務還有更多的功能等待使用者去研究和使用。Istio就像一座金礦，而金子只屬於勤奮的淘金工人。