[問題發現]
使用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”選型卡，在彈框中也可以看到語句詳情、該語句的響應時間及調用次數，如圖八、圖九：
圖八
圖九
至此，發現問題原因以及影響接口已全部排查出來！