今天分享一篇開發小哥哥如何使用雲監控和日志服務快速發現故障定位問題的經曆。
小哥哥正在coding，突然收到雲監控報警，說他的api調用rt過高，小哥哥的業務主要為線上服務提供資料查詢，rt過高可能會導緻大量頁面資料空白，這還了得，趕緊查。
具體機器的rt走勢圖：
檢視存儲在日志服務的原始資料，檢視發生問題時的原始日志，發生某一次請求的rt突然變的很大，之後的rt都變的很大。
同時也收到了健康檢查發出的30.239機器的業務java程序hang，端口telnet監控不通的報警。
cpu，load，記憶體都在波動，網絡有明顯變化，流量暴增，tcp連接配接數先增先減
再看程序監控：發現機器上的主要的業務程序-java程序，名額變化異常，
發現在事發時，有大量的fullgc。導緻程序hang住。出現以上一系列的現象
結合nginx日志和應用gc日志，再結合實際的業務場景，定位到在某一次大查詢時，在記憶體hold住太多資料，導緻記憶體爆掉，系統不斷gc，程序hang住，進一步導緻系統名額和程序名額的現象。
通過jstat -gcutil pid1000檢視，發現是perm區的fullgc非常多。通過jmap−permstatpid (要謹慎，不要線上做)，發現google avaiator相關的類很多，想起使用了google的表達式引擎，看代碼發現在compile的時候，沒有加cache。
加上cache釋出後，經過幾天的觀察，查詢前端伺服器的記憶體更加平穩，背景5xx的比例也更低。