idou老師教你學istio2:監控能力介紹
如拓撲圖所示,當某個服務被請求時,首先會請求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就像一座金礦,而金子只屬於勤奮的淘金工人。
idou老師教你學istio2:監控能力介紹