516
【最佳實踐】如何使用雲監控+日誌服務快速完成故障發現和故障定位
今天分享一篇開發小哥哥如何使用雲監控和日誌服務快速發現故障定位問題的經曆。
事件起因
小哥哥正在Coding，突然收到雲監控報警，說他的API調用RT過高，小哥哥的業務主要為線上服務提供數據查詢，RT過高可能會導致大量頁麵數據空白，這還了得，趕緊查。
排查過程
收到報警後查看指標趨勢，發現突然RT突然增高。
查看單台機器維度的指標，發現30.239這台機器RT延時非常大。
- 具體機器的RT走勢圖：
查看存儲在日誌服務的原始數據，查看發生問題時的原始日誌，發生某一次請求的rt突然變的很大，之後的rt都變的很大。
同時也收到了健康檢查發出的30.239機器的業務java進程hang，端口telnet監控不通的報警。
於是去主機監控看這台機器到底出了什麼問題。
- cpu，load，內存都在波動，網絡有明顯變化，流量暴增，tcp連接數先增先減
- 再看進程監控：發現機器上的主要的業務進程-java進程，指標變化異常，
登錄服務器後，查看GC日誌
發現在事發時，有大量的fullgc。導致進程hang住。出現以上一係列的現象
排查結果
故障結果
結合nginx日誌和應用gc日誌，再結合實際的業務場景，定位到在某一次大查詢時，在內存hold住太多數據，導致內存爆掉，係統不斷gc，進程hang住，進一步導致係統指標和進程指標的現象。
進一步發現和優化
通過jstat -gcutil pid1000查看，發現是perm區的fullgc非常多。通過jmap−permstatpid (要謹慎，不要線上做)，發現google avaiator相關的類很多，想起使用了google的表達式引擎，看代碼發現在compile的時候，沒有加cache。
加上cache發布後，經過幾天的觀察，查詢前端服務器的內存更加平穩，後台5xx的比例也更低。
最後更新：2017-09-01 12:32:25