如何使用 Kubernetes 監測定位慢調用

語言: CN / TW / HK

作者:李煌東

大家好,我是阿里雲的李煌東。今天我為大家分享 Kubernetes 監測公開課第四節,如何使用 Kubernetes 監測定位慢調用。今天的課程主要分為三大部分,首先我會介紹一下慢調用的危害以及常見的原因;其次我會介紹慢調用的分析方法以及最佳實踐;最後通過幾個案例來去演示一下慢調用的分析過程。

慢調用危害及常見原因

圖片 1.png

在開發軟件過程中,慢調用是非常常見的異常。慢調用可能帶來的危害包括:

  • 前端業務維度: 首先慢調用可能會引起前端加載慢的問題,前端加載慢可能會進一步導致應用卸載率高,進而影響品牌的口碑。

  • 項目交付的維度: 由於接口慢導致達不到 SLO,進而導致項目延期。

  • 業務架構穩定性: 當接口調用慢時,非常容易引起超時,當其他業務服務都依賴這個接口,那麼就會引發大量重試,進而導致資源耗盡,最終導致部分服務或者整個服務不可用的雪崩的現象。

所以,看似一個無關痛癢的慢調用可能隱藏着巨大風險,我們應該引起警惕。對慢調用最好都不要去忽視它,應該儘可能去分析其背後的原因,從而進行風險控制。

圖片 2.png

產生慢調用的原因有哪些?產生慢調用的原因是千千萬萬的,歸結起來有五個常見原因。

  • 第一個是資源使用率過高問題,比如説 CPU 內存、磁盤、網卡等等。當這些使用率過高的時候,非常容易引起服務慢。

  • 第二個是代碼設計的問題,通常來説如果 SQL 它關聯了很多表,做了很多表,那麼會非常影響 SQL 執行的性能。

  • 第三個是依賴問題,服務自身沒有問題,但調用下游服務時下游返回慢,自身服務處於等待狀態,也會導致服務慢調用的情況。

  • 第四個是設計問題,比如説海量數據的表非常大,億級別數據查詢沒有分庫分表,那麼就會非常容易引起慢查詢。類似的情況還有耗時的操作沒有做緩存。

  • 第五個是網絡方面問題,比如説跨洲調用,跨洲調用是物理距離太大了,導致往返時間比較長,進而導致慢調用。或者兩點之間的網絡性能可能比較差。比如説有丟包重傳率,重傳率高的問題。

今天我們的例子圍繞這五個方面,我們一起來看一下。

定位慢調用一般來説有什麼樣的步驟,或者説有什麼樣的最佳實踐呢?我這裏總結的為三個方面:黃金信號 + 資源指標 + 全局架構。 

圖片 3.png

我們先來看一下黃金信號。首先,黃金信號是出自谷歌 SRE 聖經裏面的 Site Reliability Engineering 一書。用來表徵系統是否健康的最小指標的集合,這其中包括:

  • 延時--用來描述系統執行請求花費的時間。常見指標包括平均響應時間,P90/P95/P99 這些分位數,這些指標能夠很好的表徵這個系統對外響應的快還是慢,是比較直觀的。

  • 流量--用來表徵服務繁忙程度,典型的指標有 QPS、TPS。

  • 錯誤--也就是我們常見的類似於協議裏 HTTP 協議裏面的 500、400 這些,通常如果錯誤很多的話,説明可能已經出現問題了。

  • 飽和度--就是資源水位,通常來説接近飽和的服務比較容易出現問題,比如説磁盤滿了,導致日誌沒辦法寫入,進而導致服務響應。典型的那些資源有 CPU、 內存、磁盤、隊列長度、連接數等等。

除了黃金信號,我們還需要關注一個資源指標。著名的性能分析大神 Brandan Gregg ,在他的性能分析方法論文章中提到一個 USE 方法。USE 方法是從資源角度進行分析,它是對於每一個資源去檢查 utilization(使用率),saturation (飽和度),error(錯誤) ,合起來就是 USE 了,檢查這三項基本上能夠解決 80% 的服務問題,而你只需要花費 5% 的時間。 

圖片 4.png

前面有了黃金信號、資源指標之後,我們還需要關注什麼?正如 Branda 在方法論裏面提到的“我們不能只見樹木,不見森林”。諸葛亮也説過“不謀全局者,不足以謀一域”。我們應該把系統架構畫出來,從全局去看性能問題,而不只是看某個資源、某個服務。把所有東西進行綜合考慮,識別出瓶頸所在,通過設計方法系統性解決問題,這也是一種更優的方法。所以,我們需要黃金信號、資源指標以及全局架構這種組合。 

慢調用最佳實踐

接下來我會講三個案例,第一個是節點 CPU 打滿問題,這也是典型的資源問題導致的服務慢的問題,即服務自身的資源導致的問題。第二個是依賴的服務中間件慢調用的問題。第三個是網絡性能差。第一個案例是判斷服務自身有沒有問題;第二個案例是判斷下游服務的問題;第三個就是判斷自身跟服務之間的網絡性能問題。

我們以一個電商應用舉例。首先流量入口是阿里雲 SLB,然後流量進入到微服務體系中,微服務裏面我們通過網關去接收所有流量,然後網關會把流量打到對應的內部服務裏面,比如説 ProductService、CartService、 PaymentService 這些。下面我們依賴了一些中間件,比如説 Redis 、MySQL 等等,這整個架構我們會使用阿里雲的 ARMS 的 Kubernetes 監測產品來去監測整個架構。故障注入方面,我們會通過 chaosblade 去注入諸如 CPU 打滿、網絡異常等不同類型的異常。

圖片 5.png

案例一:節點 CPU 打滿問題

節點 CPU 打滿會帶來什麼樣的問題呢?節點 CPU 打滿之後,上面的 Pod 可能沒辦法申請到更多 CPU,導致裏面的線程都處於等待調度的狀態,進而導致慢調用。除了節點上面,我們這除了 CPU 之外,還有一些像磁盤、Memory 等等資源。

圖片 6.png

接下來我們看一下 CPU 在 Kubernetes 的集羣裏面的一些特點。首先,CPU 是可壓縮的資源,在 Kubernetes 裏面我們右邊看這些配置,有幾個常見配置,比如説 Requests,Requests 是主要是用來做調度的。Limits 是用來去做運行時的一個限制,超過這個 Limits,它就會被限流。所以,我們的實驗原理是説對節點這個 CPU 進行打滿注入,導致 Pod 沒辦法申請到更多的內存,進而導致服務變慢。

在正式開始前,我們通過拓撲圖對關鍵鏈路進行識別,在上面配置一些吿警。比如説網關及支付鏈路,我們會配置平均響應時間 P90 以及慢調用等吿警。然後配置完之後,我這邊會注入一個節點 CPU 打滿這麼一個故障。那這個節點選的是網關的節點,大概等待五分鐘之後,我們就可以收到吿警,就是第二步裏面的那個驗證吿警的有效性。

圖片 7.png

接下來我們進入根因定位。首先,我們進入到查看到網關的應用詳情裏面。第一步是查看相關黃金信號,黃金信號就是響應時間,我們看到響應時間非常直觀顯示了突增,下面是慢調用數,慢調用數是有一千多個,慢調用數突然增多了,P90/P95 出現了明顯上升,並超過一秒,説明整個服務也變慢了。 

圖片 8.png

接下來,我們需要分析資源指標,在 Pod CPU 使用量圖表中可以看到這段時間 Pod 使用量上升很快,這個過程説明需要向宿主機或者節點申請更多內存。我們進一步看一下節點或者宿主機的 CPU 使用率是怎麼樣的,我們看到這段時間使用率接近百分之百,Pod 申請不了更多 CPU,進一步導致服務慢了,進而導致平均響應時間大量增長。 

圖片 9.png

定位到問題之後,我們可以想想具體解決方案。通過 CPU 使用率配置彈性伸縮。因為我們不知道相關流量或者資源,不知道什麼時候突然就不夠。那麼應對這種場景最好的辦法就是給資源配置彈性伸縮,為節點配置彈性伸縮,主要是為了確保在負載上升時,資源能夠動態擴容。為了給應用配置彈性伸縮,我們可以給比如 CPU 指標,配置一個增加副本數的一個擴容動作來去分擔流量,這裏面我們可以配置成最大副本數為十,最小副本數為三等等。 

效果如下:注入 CPU 慢故障時,慢調用會上升,上升完成之後會觸發到彈性伸縮,那就是 CPU 的使用率超過閾值了,如 70%。那麼,它就會自動擴出一些副本去分擔這些流量,我們可以看到慢調用數逐步下降直到消失,説明我們的那個彈性伸縮起到作用了。

圖片 10.png

案例二:依賴的服務中間件慢調用的問題

接下來我們看第二個案例。首先介紹一下準備工作,左邊這邊圖我們可以看到網關進來掉了兩個下游服務,一個是 MySQL ,一個是 ProductService,所以在網關上直接配置一個大於一秒的吿警,平均響應時間 P99 大於一秒的吿警。第二步我們看這個 Product 也是在關鍵鏈路上面,我給它配一個 P99 大於一秒的吿警,第三個是 MySQL ,也配一個大於一秒的吿警,配完之後,我會在 Product 這個服務上面去注入一個 MySQL 慢查詢的故障,大概等到兩分鐘之後,我們就可以看到陸續吿警就觸發出來了,網關跟 Product 上面都有一個紅點跟一個灰色的點,這一點其實就是報出來的故障,報出的吿警事件,Kubernetes 監測會把這個吿警事件通過命名空間應用自動的 match 到這個節點上面,所以能夠一眼的看出哪些服務、哪些應用是異常的,這樣能夠快速定位出問題所在。我們現在收到吿警了之後,下一步去進行一個根因定位。

圖片 11.png

首先説一下這個更新定位的流程,吿警驅動因為預防總比補救要好,所以我們是採用先配置吿警,再去更新定位這麼一個過程。然後我們會用拓撲來去進行一個可視化分析,因為拓撲是能夠去進行架構感知、分析上下游,可以進行可視化分析。當收到吿警後,可以針對吿警看對應的一個應用發生了什麼情況。第一個我們看那個網關,我們看到網關的那個 P99 上升到 1800 毫秒以上,所以觸發了一個大於 1 秒閾值的這麼一個吿警。我們可以也可以看到幾個分位數都是上漲的,然後我們進一步看另外一個發生吿警的服務,也就是 Product,點開這個節點之後,我們可以從那個 panel 上面看到這個 Product 也發生了一個慢調用,P99、P95 都已經不同程度的發生慢調用大都是大於一秒的,然後這時候我們是可以去看一下 Product 的資源使用情況的,因為可能 Product 本身有問題。我們查看 Product 的下游,一個是 Nacos,一個是 MySQL,我們看 MySQL 的這個交互的時候就發現這裏面有大量的一個慢調用,然後看到這些慢調用之後,點擊這些明細,去下鑽看一下它調用的時候發生了什麼事情,我們進一步看這些數據之後,就會發現 SQL 裏面 Product 調用 Mysql 的時候執行了一條很複雜,Join 了多張表的一個 SQL 的語句。從調用 Trace 看到耗時非常大,這樣的話我們就能夠定位到基本上是這條 SQL 產生的一個問題了。

圖片 12.png

總結一下我們整個流程,首先我們會通過架構感知去識別關鍵的路徑,然後在這個關鍵路徑上去配置吿警去主動發現異常。發現異常之後,我們通過應用自身的資源指標黃金信號等來去定位問題。如果自身沒有問題,那我們就可往下追蹤下游,我們去看下游的資源指標,用這麼一種方法去定位慢調用的一個依賴的問題,中間件調用的問題。

圖片 13.png

案例三:網絡性能差

接下來我們講最後一個例子就是網絡性能差,Kubernetes 的網絡架構是比較複雜的,容器之間的通信、Pod 之間的通信、Pod 與服務之間通信、外部與服務之間的通信等等。所以複雜度是比較高的,學習的曲線也比較陡峭,這給定位問題帶來一定困難。那麼,我們怎麼去應對這種情況呢?如果採用關鍵網絡環境指標去發現網絡異常,有哪些關鍵環境指標呢?首先一個是速率跟帶寬,第二個是吞吐量,第三個是延時,第四個是 RTT。 

圖片 14.png

首先我會這邊配置一個吿警,注入 MySQL 所在節點丟包率高這個故障,等待幾分鐘之後,我們會收到慢調用吿警,網關跟 Product 的響應時間都發生了大於一秒的吿警。接下來我們看一下根因定位,我們看到網關,發生了慢調用 P99 的響應時間暴增,然後看 Product 也發生了平均響應時間突增的問題,那就是剛才的服務慢調用了,然後我們進一步看 Product 的下游,依賴了 Nacos、Redis 、MySQL  這三個服務,可以發現慢調用是比較明顯的,然後我們查看它的下游時就發現了 Product 調 MySQL 的時候發生了比較嚴重的慢調用,同時它的 RTT 跟重傳現象也很明顯。 

圖片 15.png

正常情況下 RTT 是很平穩的。它反映的是上下游之間的往返的時間,如果它都上漲非常快,基本上可以認定為它是網絡問題,所以説可以看到就是這裏面有三條,從網關、Product、MySQL,從這裏我們可以總結到就是通過這種識別關鍵路徑,然後在拓撲上面去配置吿警的這種方法可以非常快的去定位問題,不需要去查證很多散落在各個地方的信息。我們只需要去在這條拓撲上面去樹藤摸瓜的去查看對應的性能指標,網絡指標等等,快速定位到問題所在。所以,這就是我們黃金信號 + 資源指標 + 資源拓撲定位像慢調用這種異常的最佳實踐。 

圖片 16.png

最後總結下本次最佳實踐:

1、通過默認吿警主動發現異常,默認吿警模板涵蓋 RED,常見資源類型指標。除了默認下發的吿警規則,用户還可以基於模板定製化配置。

2、通過黃金信號和資源指標發現、定位異常,同時 Trace 配合下鑽定位根因。

3、通過拓撲圖做上下游分析、依賴分析、架構感知,有利於從全局視角審視架構,從而得到最優解,做到持續改善,構建更穩定的系統。 

點擊此處,查看更多可觀測相關乾貨內容與產品實踐~

本節課的內容到這裏就結束了,歡迎大家前往釘釘掃碼或搜索釘釘羣(31588365)加入答疑交流羣進行交流。

二維碼.png

近期熱門

#HOT TOPIC #雲原生加速器,為你而來#

就等你了!趕快點擊此處參與報名吧~

c.JPG