【最佳实践】如何使用云监控+日志服务快速完成故障发现和故障定位-阿里云开发者社区

开发者社区> 开发与运维> 正文

【最佳实践】如何使用云监控+日志服务快速完成故障发现和故障定位

简介: 今天分享一篇开发小哥哥如何使用云监控和日志服务快速发现故障定位问题的经历。

今天分享一篇开发小哥哥如何使用云监控和日志服务快速发现故障定位问题的经历。

事件起因

小哥哥正在Coding,突然收到云监控报警,说他的API调用RT过高,小哥哥的业务主要为线上服务提供数据查询,RT过高可能会导致大量页面数据空白,这还了得,赶紧查。

排查过程

收到报警后查看指标趋势,发现突然RT突然增高。

image

查看单台机器维度的指标,发现30.239这台机器RT延时非常大。

image

  • 具体机器的RT走势图:

    ![image](https://yqfile.alicdn.com/9822ac214802431b42d1e4e76fc17b5da5d45d4e.png)
  • 查看存储在日志服务的原始数据,查看发生问题时的原始日志,发生某一次请求的rt突然变的很大,之后的rt都变的很大。

    ![image](https://yqfile.alicdn.com/756a7443ab1bb4bcde52570428a8e4a67ef7df6b.png)
    
  • 同时也收到了健康检查发出的30.239机器的业务java进程hang,端口telnet监控不通的报警。
    image

于是去主机监控看这台机器到底出了什么问题。

  • cpu,load,内存都在波动,网络有明显变化,流量暴增,tcp连接数先增先减
    image

image

image

  • 再看进程监控:发现机器上的主要的业务进程-java进程,指标变化异常,
    image

登录服务器后,查看GC日志

发现在事发时,有大量的fullgc。导致进程hang住。出现以上一系列的现象

image

排查结果

故障结果

结合nginx日志和应用gc日志,再结合实际的业务场景,定位到在某一次大查询时,在内存hold住太多数据,导致内存爆掉,系统不断gc,进程hang住,进一步导致系统指标和进程指标的现象。

进一步发现和优化

通过jstat -gcutil pid1000查看,发现是perm区的fullgc非常多。通过jmap−permstatpid (要谨慎,不要线上做),发现google avaiator相关的类很多,想起使用了google的表达式引擎,看代码发现在compile的时候,没有加cache。
image

加上cache发布后,经过几天的观察,查询前端服务器的内存更加平稳,后台5xx的比例也更低。

image

我也想用小哥哥在用的监控!

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章