[問題發現]

使用zabbix軟體監控伺服器時發現cpu突然異常，在業務主機上使用top命令檢視系統的整體執行情況，使用top命令後發現mysqld佔用CPU特別高，初步判斷可能是mysqld出現問題，需要排查：

[排查步驟]

Step1:

登入oneapm ai平臺後可以看到應用列表的總覽檢視，在總覽檢視中可以看到所有應用的名稱以及相關指標資訊，同時我們還可以根據應用顏色變化來判斷每個應用的指標變化情況。本例中在Acmeair應用的“使用者體驗一覽”選項卡下可以看到它的業務在最近一段時間內出現了71次失敗，我們需要點選此應用檢視詳情，如圖一：

圖一

Step2：

利用top命令已經基本排查出是資料庫導致CPU佔用過高，我們可以通過檢視呼叫資料庫的節點發現問題。

在AI平臺上點選某個應用進入到該應用的主頁，進入之後可以看到該應用的總體拓撲圖，總覽拓撲圖會把應用中所有Tier、資料庫、遠端服務與其他應用之間的呼叫關係描繪出來，並且顯示他們的效能情況。當某個節點的顏色為黃色或紅色時，代表該Tier的健康狀態是告警或嚴重。

點選拓撲圖右上側的“資料庫-展開”選項，可以看到呼叫mysql資料庫的節點，點選該節點（例如下圖中的Webapp11節點），出現的彈框中有總覽、節點、Web事務入口、Web事務、主機和容器幾個選項卡。“Web事務入口”可以看到某個應用在應用環境中請求的起始點；而“Web事務”展示了一些使用者最關心的的指標，從而讓使用者對當前檢視Web事務的健康狀況產生總體的瞭解。

點選“Web事務入口”選項可以看到對應介面的響應時間正常，代表對應介面表現正常，如圖二；我們需要繼續排查“Web事務”部分。

圖二

點選“Web事務”選項，可以給出該節點中所有Web事務的響應時間及呼叫次數，點選“響應時間”可以將響應時間從高往低排序，從而確認緩慢的“Web事務”，如圖三。本例中，點選響應時間最長的Web事務檢視詳情。

圖三

Step3：

點選響應時間最長的一個Web事務後，左上角“總覽”下“Web事務”的標籤會顯示出該Web事務的平均響應時間，點選某一響應時間較長的時間點，可以向下鑽取到所選時間段，精準定位到問題時間點。同時在Web事務的下方可以看到該時間段內的最慢元件，如圖四。

在本例中下鑽到具體時間點後，可以在“總覽”介面的“最慢元件”下看到是一個select語句比較耗時，再次佐證了我們的想法。

圖四

Step4：

Trace是對這段時間內該使用者緩慢或錯誤請求的詳細追蹤。

鑽取到問題時間段後，我們檢視該時間範圍內的Trace列表，如圖五。因為同一個Web事務調取到的後端資訊都是相同的，所以我們只需要選取其中的一條或幾條最優代表性（例如響應時間較長）的Trace進行問題定位即可。

在本例中我們按響應時間進行排序降序排列後，選擇第一條進行Trace詳情檢視。

圖五

點選所選Trace之後，在Trace概要中可以看到該Trace中的最慢元件，如圖六。例如圖六中我們可以在Trace的總覽頁面發現customer/select語句耗時較長。

圖六

彈框中同樣還可以檢視該Trace中的堆疊呼叫詳情。點選“詳情”選項卡，如圖七，可以看到該sql語句對介面的影響，從而進行程式碼的優化。在本例中，我們可以看到SQL語句的耗時百分比較高，可以看出該SQL語句對介面影響較大。

圖七

點選該SQL語句 附加資訊欄中的圖示，可以檢視到耗時較長的的sql語句詳情。我們也可以彈框左上角中的“SQL”選型卡，在彈框中也可以看到語句詳情、該語句的響應時間及呼叫次數，如圖八、圖九：

圖八

圖九

至此，發現問題原因以及影響介面已全部排查出