如何利用快照（ snapshot ）功能快速定位性能問題

時間 2019-11-26

原文原文鏈接

咱們經常會遇到這樣的困惑，收到用戶或者客服的反饋，平臺使用有問題，可是測試人員搭建環境後又沒辦法復現故障，最後致使問題無法解決，眼睜睜地看着用戶流失。html

這是由於線上生產環境很是複雜、不少時候是偶發性 bug ，但卻很難捕捉。特別是隨着微服務盛行，系統複雜度增長，線上故障的快速定位和及時分析解決面臨着巨大挑戰，之前只能靠人來解決。可是人的問題解決能力與速度依賴於經驗，有時候甚至須要跨部門的配合，這樣的成本很是高，一旦關鍵人員流失、部門配合不融洽，整個故障的解決速度就會極速降低。java

這時候我要給你們帶來一款好用的性能分析工具- Application Insight （應用性能管理平臺，如下簡稱 Ai ），至於它能幹什麼呢？往下看你就知道了～web

trace & snapshot 功能介紹

01業務運行中有哪些錯誤呢？

在代碼運行中，經常會遇到這幾類型問題：sql

●JVM數據庫

常見的好比 oom 內存溢出、內存泄漏、gc pause 、磁盤運行不足等api

● 數據庫性能優化

常見的好比數據庫負載繁忙、數據庫服務器超負載、單一 sql 語句執行緩慢、數據庫鏈接池獲取時間長、對數據庫鏈接池的訪問次數過多等服務器

● 外部服務微信

常見的好比外部服務網絡問題、不一樣應用之間的調用阻塞、索引設置不合適等網絡

● 其它問題

上面都是咱們常見的場景，可是還有一些問題是深深的潛藏在程序中，須要咱們深刻地分析代碼才能找到緣由。

線程死鎖、循環操做、事務異常、jvm crash 等

02什麼是 trace ？

trace 收集程序運行時的信息來查詢程序運行狀況，定位代碼中須要修改和優化的部分，提升代碼運行速度，提高用戶體驗。

業內經常使用的方法有以下三種：

● 事件方法

在 Java 語言中，使用 jvmti（ jvm tools interface ）api 方法來捕捉諸如方法調用、類載入、類卸載、進入離開線程等事件，而後再基於這些事件進行代碼行爲的分析。

● 統計抽樣

每隔一段事件中斷調用系統，收集當前的調用棧信息，記錄調用棧中出現的函數及這些函數的調用結構，基於這些信息獲得函數的調用關係圖及每一個函數的 cpu 使用信息。

● 插碼

在目標程序中插入指令代碼，這些指令代碼會記錄程序運行的開始時間、結束時間等，再通過統計得出函數調用狀況、函數 cpu 使用狀況。

03 AI 的 trace

Ai 採用插碼與快照（統計抽樣）的方式來實現 trace ，trace 包括慢 trace 、錯誤 trace 、sql trace 、snapshot 四類：

● 慢 trace

在用戶的事務響應時間超過閾值的時候去進行採集。系統默認是2秒，但用戶能夠根據本身實際狀況在 Ai 的「設置-慢事務」處進行設置。

● 錯誤 trace

當程序運行異常或直接報錯時，咱們會直接採集錯誤 trace，還原現場。

● Sql trace

在平臺開啓慢 sql 追蹤，並設置慢 sql 追蹤閾值，當 sql 的性能大於該閾值的時候，agent 記錄慢 sql 的堆棧信息。默認爲0.5s，用戶能夠根據本身實際狀況在 Ai 的「設置-數據庫」進行設置。

同時用戶能夠開啓 sql 執行計劃，對於執行緩慢的 sql 進行抓取。

● snapshot

snapshot 實現原理爲在客戶業務運行緩慢時對調用進行屢次代碼快照，而且進行方法、耗時分析，得出快照 trace 。

採集規則爲 web 事務連續兩分鐘的平均響應時間超過4*apdex_T(默認兩秒)，且每分鐘的快照數不超過1個。

用戶無需作任何配置，便可使用此功能，還能夠根據業務動態調整閾值。

用戶案例分析

01問題類型：鏈接服務被拒絕

1）問題現象：用戶反饋沒法退出登陸

2）問題調查和分析

a：登陸平臺查看登出的接口狀況

登陸接口爲 rest / api / login ，選擇該 web 事務後進入查看詳情，使用「篩選」進行條件過濾，獲取失敗的 trace 。

b：查看錯誤 trace

在總覽頁面，經過異常分析，看到 http 響應碼和異常類、異常信息，這時候咱們已經清楚問題緣由了。

點擊「詳情」查看程序的執行狀況，能夠看到程序循環了三次，均出現錯誤

在錯誤詳情，查看詳情的調用棧，咱們排查到「caused by java.net.ConnectException:拒絕鏈接（connection refused）

3）解決方案

與運維人員配合重啓負責註冊模塊的服務器後，業務恢復正常。

4）建議方案

在報警處針對重要業務服務進行配置，當響應時間超過閾值或者出現頻率超過閾值時，提早報警，挽回損失。

4.1 新功能體驗

登陸平臺後能夠查看報警狀態

進入事務詳情，鼠標懸停查看該時間段內發生的最近最嚴重的報警詳情

點擊紅點跳轉報警記錄查看該事務在該時間段內的全部詳情

4.2 如何配置報警

a：從 Ai 頁面點擊報警

進入報警頁面，再選擇報警規則，建立報警規則名稱、選擇類型、自定義規則的可用與不可用時間（好比節假日不可用等）

b：選擇報警對象

目前系統支持按照具體 web 事務、按照不一樣集羣、按照高頻 web 事務入口（ cpm >10）來進行選擇，咱們選擇按照具體的 web 事務爲報警對象。

c：選擇嚴重條件

根據咱們的業務述求，只要過去10分鐘內該事務的平均響應時間大於2秒，並且至少有5分鐘的平均響應時間大於2s, 則觸發嚴重報警。

d：選擇警告條件

根據咱們的業務述求，只要過去10分鐘內該事務的平均響應時間大於1秒，並且至少有5分鐘的平均響應時間大於1s, 則觸發嚴重報警。

此時咱們報警規則已配置好，當事務觸發報警時，即可在 Ai 平臺直接查看是否有報警、是否嚴重。若是您想及時感知報警，可進行進一步的配置。

4.3 如何接收報警

a：建立接收人

b：選擇接收方式

目前 Ai 默認郵件與 webhook 報警方式，但經過與 Cloud Alert （智能告警平臺，簡稱 CA 平臺）的打通，支持短信、微信、釘釘等通知方式，更詳細的報警分發與報警壓縮可查看（經過免費版，中小運維團隊夠夠的）https://www.aiops.com/CAintroduce.html

c：將接收人和報警規則關聯

選擇報警規則和觸發行爲便可

經常使用咱們 Ai 平臺看報警的小夥伴必定有點奇怪，爲何我沒有在 Ai 平臺中看到報警狀態的相關信息呢？

沒錯，Ai 與報警深度關聯功能是咱們新開發的功能，我也提早體驗了一把，感受棒棒噠！該功能於12月中旬上線，小夥伴們敬請期待吧~

若您還不是 OneAPM 用戶，請點擊 https://user.oneapm.com/pages/v2/signup 當即註冊免費試用，即刻感覺性能優化吧！