簡介：因為線上線下環境隔離的問題，線上的輸入很多時候難以在日常環境中構造，定位 bug 效率低下。是否有簡單快捷的辦法呢？

一個小故事

周末12點的鬧鐘在回龍觀均價3000的出租屋急促的響起，程序員小A慵懶的拿過手機，滑開手機通知欄，沒有未接電話，點開手機的攔截信箱，沒有報警短信，昨晚的發布一定很順利。小A幸福的伸了個懶腰。戴上3000塊的BeatsSolo Pro，音樂逐漸響起來，小A緩緩的閉上了眼睛，正午的陽光從窗戶漫進來，撒在小A稀疏的頭發上。此時的小A正在腦海中勾勒著自己美好的未來。房東說：十年前住在這間屋的小B，現在已經是某度的T10 大佬，五年前住在這兒的小T，現在已經在某條帶領200人的團隊，想到這兒，小A的嘴角微微上揚，那我也一定不會太差吧～

嘀嘀..耳機里傳來兩聲消息提示音，小A心里咯噔一聲，刺骨的寒意彌漫開來，北京三月的陽光突然就不暖了。小A用力的微微睜開雙眼，通知欄測試同學小C的頭像一閃而過。

xx線上BUG緊急修復群

小C: “@小A 昨晚上線的代碼好像有點有問題，來公司看下？我在公司等你。”

點開群設置，老板的頭像赫然在列。

懷著愧疚、徘徊、悔恨、無奈、憤怒的心情，小A翻身穿上他在路邊買的價值20元的人字拖，坐上了前往西二旗的地鐵十號線。

不久，西二旗某辦公室傳來了亙古不變的對話，“這段代碼測試過，在我電腦上沒問題啊”、"你重啟下試試"、“是不是代碼沒上線”、“是不是誰把我代碼沖掉了”、“你們測試數據是不是有問題呀”……于是一個下午過去了、一個晚上過去了、一個周末過去了、一個程序員的青春過去了、一個程序員本就不長的職業生涯過去了。

一個小總結

上面這個虛構的小故事只是想說明一個簡單的現象，程序員的很多時間被線上bug fix占據。因為線上線下環境不一致、輸入輸出不一等等原因，很多bug定位起來效率低下，耗時巨長，導致很多時候程序員遇到線上bug總是頭疼不已，不由自主的想要甩鍋給外在因素，在確定是自己的問題的時候再排查問題。那么線上問題排查到底難在哪兒？首先來看看我們排查線上問題的一個基本步驟，這個步驟一般是排查大多數線上問題的步驟。

步驟1：找到能復現問題的輸入；

步驟2：判斷該輸入能否在日常環境構造, 如果能，調到步驟5。如果不能，繼續步驟3；

步驟3：查看線上環境日志，看能否找到異常輸入相關的異常日志，輔助排查問題；

步驟4：初步推斷問題原因，嘗試修復并加上更多日志輸出。然后打包、發布。重復步驟3直到定位根因；

步驟5：日常構造相同輸入，單點調試，定位問題；

實際的場景中，因為線上線下環境隔離的問題，線上的輸入很多時候難以在日常環境中構造，大多數時候我們都在步驟2、3、4中循環，于是時間就在循環中慢慢的流逝了。

上面做這么多步驟其實對于查問題而言就是希望可以知道當某段代碼執行不符合預期的時候，這段代碼的輸入是什么，輸出是什么，拋出了什么異常，以及代碼中每一行的具體執行情況。那么是否有一款產品可以讓用戶方便快捷的實現這個目標呢？答案是有的。

聊一聊ARMS

阿里云的應用實時監控服務ARMS是一款應用性能管理（APM）產品，包含應用監控、Prometheus監控和前端監控三大子產品，涵蓋分布式應用、容器環境、瀏覽器、小程序、APP 等領域的性能管理，能幫助用戶實現全棧式性能監控和端到端全鏈路追蹤診斷。

ARMS最新推出了Arthas診斷功能，其第一個版本主要包含四個能力，分別是JVM概覽、線程耗時分析、方法執行分析以及性能分析：

• JVM概覽：查看實時的JVM內存、GC信息以及操作系統信息、環境變量、系統變量等信息。
• 線程耗時分析：查看實時的線程耗時情況，并可查看每個線程實時的方法堆棧。
• 方法執行分析：實時的抓取滿足指定條件的方法執行明細、出入參數以及異常。
• 性能分析：快捷的通過火焰圖的的形式，展示系統性能瓶頸。

ARMS的Arthas功能使用起來也比較簡單，詳情可參照文檔。下面來簡單聊一聊如何利用ARMS的Arthas診斷能力來進行線上問題的定位。

聊一聊ARMS Arthas診斷

上一節簡單介紹了下ARMS的Arthas診斷具備的能力，那么用這些能力能解決哪些線上問題呢？在這里，我們對線上問題進行了一個歸納總結，將其分為下面四類問題：

• 方法執行不符合預期：包括方法執行耗時、方法返回值、方法拋出了異常等情況，表現在應用上可能是一些接口或者服務的RT增高，錯誤率增高，返回值異常等。
• 進程CPU耗時突增：一般有代碼死循環問題、FullGC導 GC線程耗時高、并發使用HashMap等。
• 性能優化問題：主要用于分析性能瓶頸，輔助性能優化，包括 CPU 耗時、內存分配、鎖競爭、itimer 等情況的性能分析。
• 其他問題：比如初始化環境變量讀取錯誤、內核版本不符合要求、類沖突等問題。

下面就以一個實際的demo來演示如何利用ARMS的Arthas來進行方法執行不符合預期這種問題的診斷，后續的文章會繼續介紹如何利用Arthas進行其他類型問題的診斷。

利用ARMS Arthas診斷方法執行不符合預期類問題

問題背景：product 應用的com.alibabacloud.hipstershop.productserviceapi.service.ProductService@confirmInventory 接口某次發布后平均 RT 到達 400，發布以前的平均 RT 在 1ms 以下，如下圖所示。現在想定位耗時具體耗在哪兒。?

圖 1

首先，進入ARMS Arthas診斷的頁面。當我們進行BUG定位的時候，首先需要知道出問題的類名和方法名，按照圖示截圖中的紅色注釋輸入相應的類名和方法名。如果你是EDAS用戶，可直接選擇一個服務或者接口，后臺會自動推斷相應的實現類和方法。對應到本案例，對應的類是com.alibabacloud.xxx.xxx.xxx.ProductService，方法是confirmInventory。填寫完畢后點擊確定。

圖 2

如下圖所示，點擊確定后可以得到confirmInventory方法執行的紀錄，包含執行的入參，返回值異常以及方法執行明細。

圖 3

但是這次執行的耗時2.89ms，不是我們預期中的一次耗時高調用。此時，可點擊右上角修改診斷參數，設定抓取耗時大于300ms的方法調用(除此以外還可以設置更多的過濾條件，包括方法參數滿足的條件等等，具體可查看文檔。

圖 4

點擊確定后，點擊右上角刷新圖標再次診斷，這次抓取到一次耗時1501ms的方法調用，發現原來是在該方法的執行過程中，執行了Thread.sleep() 方法。

圖5

到這里，你可能還會好奇，為什么會執行sleep方法呢？這塊代碼的邏輯是怎樣的呢？點擊右上角查看方法源碼，一目了然的將方法源碼與方法執行明細相結合。如下圖所示，confirmInventory方法中執行的每一次方法調用最后會以“//-”為前綴展示該方法執行的耗時情況。

圖 6

此外，你還可以點擊圖5 ，列表最右側的操作列的下鉆，快捷的進一步分析confirmInventory調用的子方法的執行情況。這在根因比較深的場景下十分方便好用。

至此，完成了我們這個問題的一個定位演示。

相信ARMS的Arthas診斷功能一定給你留下了深刻的印象，也一定會成為您線上問題診斷的利器，幫助您更快更方便的診斷線上故障。

寫在最后

點此快速免費體驗ARMS功能。此外，企業級分布式應用服務EDAS K8s作為一款一體化的產品，既具備了應用的托管能力，也集成了ARMS的監控診斷能力，同樣可以體驗ARMS的Arthas診斷功能，可根據您目前的實際情況選擇一款產品來體 ARMS的Arthas診斷能力。

備注：上述功能目前僅對部署在K8s為集群中的Java應用有效，后續會支持部署的ECS上的Java應用。

原文鏈接：https://developer.aliyun.com/article/783669?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的走完线上 BUG 定位最后一公里的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。