如何使用 Kubernetes 監測定位慢呼叫

語言: CN / TW / HK

作者:李煌東

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

01

慢呼叫危害及常見原因

Cloud Native

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

  • 前端業務維度: 首先慢呼叫可能會引起前端載入慢的問題,前端載入慢可能會進一步導致應用解除安裝率高,進而影響品牌的口碑。

  • 專案交付的維度: 由於介面慢導致達不到 SLO,進而導致專案延期。

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

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

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

  • 第一個是資源使用率過高問題,比如說 CPU 記憶體、磁碟、網絡卡等等。當這些使用率過高的時候,非常容易引起服務慢。

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

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

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

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

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

定位慢呼叫一般來說有什麼樣的步驟,或者說有什麼樣的最佳實踐呢?我這裡總結的為三個方面:黃金訊號 + 資源指標 + 全域性架構。

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

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

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

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

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

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

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

02

慢呼叫最佳實踐

Cloud Native

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

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

1

案例一:節點 CPU 打滿問題

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

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

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

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

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

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

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

2

案例二: 賴的服務中介軟體慢呼叫 的問題

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

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

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

3

案例三:網路效能差

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

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

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

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

1、  通過預設告警主動發現異常,預設告警模板涵蓋 RED,常見資源型別指標。除了預設下發的告警規則,使用者還可以基於模板定製化配置。

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

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

點選 閱讀原文 ,檢視更多可觀測相關乾貨內容與產品實踐~

近期熱門

HOT TOPIC

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

就等你了!趕快點選下圖瞭解詳情吧~