如何使用 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