作者：李煌東
大家好，我是阿里雲的李煌東。今天我為大家分享 Kubernetes 監測公開課第四節，如何使用 Kubernetes 監測定位慢呼叫。今天的課程主要分為三大部分，首先我會介紹一下慢呼叫的危害以及常見的原因；其次我會介紹慢呼叫的分析方法以及最佳實踐；最後通過幾個案例來去演示一下慢呼叫的分析過程。
慢呼叫危害及常見原因
在開發軟體過程中，慢呼叫是非常常見的異常。慢呼叫可能帶來的危害包括：
- 前端業務維度： 首先慢呼叫可能會引起前端載入慢的問題，前端載入慢可能會進一步導致應用解除安裝率高，進而影響品牌的口碑。
- 專案交付的維度： 由於介面慢導致達不到 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 在方法論裡面提到的“我們不能只見樹木，不見森林”。諸葛亮也說過“不謀全域性者，不足以謀一域”。我們應該把系統架構畫出來，從全域性去看效能問題，而不只是看某個資源、某個服務。把所有東西進行綜合考慮，識別出瓶頸所在，通過設計方法系統性解決問題，這也是一種更優的方法。所以，我們需要黃金訊號、資源指標以及全域性架構這種組合。
慢呼叫最佳實踐
接下來我會講三個案例，第一個是節點 CPU 打滿問題，這也是典型的資源問題導致的服務慢的問題，即服務自身的資源導致的問題。第二個是依賴的服務中介軟體慢呼叫的問題。第三個是網路效能差。第一個案例是判斷服務自身有沒有問題；第二個案例是判斷下游服務的問題；第三個就是判斷自身跟服務之間的網路效能問題。
我們以一個電商應用舉例。首先流量入口是阿里雲 SLB，然後流量進入到微服務體系中，微服務裡面我們通過閘道器去接收所有流量，然後閘道器會把流量打到對應的內部服務裡面，比如說 ProductService、CartService、 PaymentService 這些。下面我們依賴了一些中介軟體，比如說 Redis 、MySQL 等等，這整個架構我們會使用阿里雲的 ARMS 的 Kubernetes 監測產品來去監測整個架構。故障注入方面，我們會通過 chaosblade 去注入諸如 CPU 打滿、網路異常等不同型別的異常。
案例一：節點 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%。那麼，它就會自動擴出一些副本去分擔這些流量，我們可以看到慢呼叫數逐步下降直到消失，說明我們的那個彈性伸縮起到作用了。
案例二：依賴的服務中介軟體慢呼叫的問題
接下來我們看第二個案例。首先介紹一下準備工作，左邊這邊圖我們可以看到閘道器進來掉了兩個下游服務，一個是 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 產生的一個問題了。
總結一下我們整個流程，首先我們會通過架構感知去識別關鍵的路徑，然後在這個關鍵路徑上去配置告警去主動發現異常。發現異常之後，我們通過應用自身的資源指標黃金訊號等來去定位問題。如果自身沒有問題，那我們就可往下追蹤下游，我們去看下游的資源指標，用這麼一種方法去定位慢呼叫的一個依賴的問題，中介軟體呼叫的問題。
案例三：網路效能差
接下來我們講最後一個例子就是網路效能差，Kubernetes 的網路架構是比較複雜的，容器之間的通訊、Pod 之間的通訊、Pod 與服務之間通訊、外部與服務之間的通訊等等。所以複雜度是比較高的，學習的曲線也比較陡峭，這給定位問題帶來一定困難。那麼，我們怎麼去應對這種情況呢？如果採用關鍵網路環境指標去發現網路異常，有哪些關鍵環境指標呢？首先一個是速率跟頻寬，第二個是吞吐量，第三個是延時，第四個是 RTT。
首先我會這邊配置一個告警，注入 MySQL 所在節點丟包率高這個故障，等待幾分鐘之後，我們會收到慢呼叫告警，閘道器跟 Product 的響應時間都發生了大於一秒的告警。接下來我們看一下根因定位，我們看到閘道器，發生了慢呼叫 P99 的響應時間暴增，然後看 Product 也發生了平均響應時間突增的問題，那就是剛才的服務慢呼叫了，然後我們進一步看 Product 的下游，依賴了 Nacos、Redis 、MySQL 這三個服務，可以發現慢呼叫是比較明顯的，然後我們檢視它的下游時就發現了 Product 調 MySQL 的時候發生了比較嚴重的慢呼叫，同時它的 RTT 跟重傳現象也很明顯。
正常情況下 RTT 是很平穩的。它反映的是上下游之間的往返的時間，如果它都上漲非常快，基本上可以認定為它是網路問題，所以說可以看到就是這裡面有三條，從閘道器、Product、MySQL，從這裡我們可以總結到就是通過這種識別關鍵路徑，然後在拓撲上面去配置告警的這種方法可以非常快的去定位問題，不需要去查證很多散落在各個地方的資訊。我們只需要去在這條拓撲上面去樹藤摸瓜的去檢視對應的效能指標，網路指標等等，快速定位到問題所在。所以，這就是我們黃金訊號 + 資源指標 + 資源拓撲定位像慢呼叫這種異常的最佳實踐。
最後總結下本次最佳實踐：
1、通過預設告警主動發現異常，預設告警模板涵蓋 RED，常見資源型別指標。除了預設下發的告警規則，使用者還可以基於模板定製化配置。
2、通過黃金訊號和資源指標發現、定位異常，同時 Trace 配合下鑽定位根因。
3、通過拓撲圖做上下游分析、依賴分析、架構感知，有利於從全域性視角審視架構，從而得到最優解，做到持續改善，構建更穩定的系統。
點選此處，檢視更多可觀測相關乾貨內容與產品實踐～
本節課的內容到這裡就結束了，歡迎大家前往釘釘掃碼或搜尋釘釘群（31588365）加入答疑交流群進行交流。
近期熱門
#HOT TOPIC #雲原生加速器，為你而來#
就等你了！趕快點選此處參與報名吧～
