[問題發現]
使用zabbix軟件監控服務器時發現cpu忽然異常,在業務主機上使用top命令查看系統的總體運行狀況,使用top命令後發現mysqld佔用CPU特別高,初步判斷多是mysqld出現問題,須要排查:mysql
[排查步驟]
Step1:
登陸oneapm ai平臺後能夠看到應用列表的總覽視圖,在總覽視圖中能夠看到全部應用的名稱以及相關指標信息,同時咱們還能夠根據應用顏色變化來判斷每一個應用的指標變化狀況。本例中在Acmeair應用的「用戶體驗一覽」選項卡下能夠看到它的業務在最近一段時間內出現了71次失敗,咱們須要點擊此應用查看詳情,如圖一:sql
圖一數據庫
Step2:
利用top命令已經基本排查出是數據庫致使CPU佔用太高,咱們能夠經過查看調用數據庫的節點發現問題。
在AI平臺上點擊某個應用進入到該應用的主頁,進入以後能夠看到該應用的整體拓撲圖,總覽拓撲圖會把應用中全部Tier、數據庫、遠程服務與其餘應用之間的調用關係描繪出來,而且顯示他們的性能狀況。當某個節點的顏色爲黃色或紅色時,表明該Tier的健康狀態是告警或嚴重。
點擊拓撲圖右上側的「數據庫-展開」選項,能夠看到調用mysql數據庫的節點,點擊該節點(例以下圖中的Webapp11節點),出現的彈框中有總覽、節點、Web事務入口、Web事務、主機和容器幾個選項卡。「Web事務入口」能夠看到某個應用在應用環境中請求的起始點;而「Web事務」展現了一些用戶最關心的的指標,從而讓用戶對當前查看Web事務的健康情況產生整體的瞭解。
點擊「Web事務入口」選項能夠看到對應接口的響應時間正常,表明對應接口表現正常,如圖二;咱們須要繼續排查「Web事務」部分。後端
圖二服務器
點擊「Web事務」選項,能夠給出該節點中全部Web事務的響應時間及調用次數,點擊「響應時間」能夠將響應時間從高往低排序,從而確認緩慢的「Web事務」,如圖三。本例中,點擊響應時間最長的Web事務查看詳情。app
圖三性能
Step3:
點擊響應時間最長的一個Web事務後,左上角「總覽」下「Web事務」的標籤會顯示出該Web事務的平均響應時間,點擊某一響應時間較長的時間點,能夠向下鑽取到所選時間段,精準定位到問題時間點。同時在Web事務的下方能夠看到該時間段內的最慢組件,如圖四。
在本例中下鑽到具體時間點後,能夠在「總覽」界面的「最慢組件」下看到是一個select語句比較耗時,再次佐證了咱們的想法。優化
圖四spa
Step4:
Trace是對這段時間內該用戶緩慢或錯誤請求的詳細追蹤。
鑽取到問題時間段後,咱們查看該時間範圍內的Trace列表,如圖五。由於同一個Web事務調取到的後端信息都是相同的,因此咱們只須要選取其中的一條或幾條最優表明性(例如響應時間較長)的Trace進行問題定位便可。
在本例中咱們按響應時間進行排序降序排列後,選擇第一條進行Trace詳情查看。3d
圖五
點擊所選Trace以後,在Trace概要中能夠看到該Trace中的最慢組件,如圖六。例如圖六中咱們能夠在Trace的總覽頁面發現customer/select語句耗時較長。
圖六
彈框中一樣還能夠查看該Trace中的堆棧調用詳情。點擊「詳情」選項卡,如圖七,能夠看到該sql語句對接口的影響,從而進行代碼的優化。在本例中,咱們能夠看到SQL語句的耗時百分比較高,能夠看出該SQL語句對接口影響較大。
圖七
點擊該SQL語句 附加信息欄中的圖標,能夠查看到耗時較長的的sql語句詳情。咱們也能夠彈框左上角中的「SQL」選型卡,在彈框中也能夠看到語句詳情、該語句的響應時間及調用次數,如圖8、圖九:
圖八
圖九
至此,發現問題緣由以及影響接口已所有排查出來!