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

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

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

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

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

具体机器的RT走势图：

![image](https://yqfile.alicdn.com/9822ac214802431b42d1e4e76fc17b5da5d45d4e.png)

查看存储在日志服务的原始数据，查看发生问题时的原始日志，发生某一次请求的rt突然变的很大，之后的rt都变的很大。

![image](https://yqfile.alicdn.com/756a7443ab1bb4bcde52570428a8e4a67ef7df6b.png)

同时也收到了健康检查发出的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的比例也更低。

我也想用小哥哥在用的监控！
日志服务数据加工最佳实践: 从其他logstore拉取数据做富化 本篇覆盖日志服务数据加工最佳实践: 从其他logstore拉取数据做富化的各种场景, 包括定期刷新拉取所有, 拉取部分数据, 拉取后再过滤数据, 调整返回表格结构等
日志服务数据加工最佳实践: 使用搜索映射做高级数据富化 典型映射方式不能满足富化需求时, 可以使用搜索映射, 搜索映射与传统方式映射的区别在于匹配方式不同. 本篇介绍日志服务数据加工最佳实践: 使用搜索映射做高级数据富化.
日志服务数据加工最佳实践: 从RDS-MySQL拉取数据做富化 本篇覆盖日志服务数据加工最佳实践: 从RDS-MySQL拉取数据做富化的各种场景, 包括定期刷新拉取所有, 拉取部分数据, 拉取后再过滤数据, 调整返回表格结构等
日志服务数据加工最佳实践: 构建字典与表格做数据富化 本篇介绍日志服务数据加工最佳实践: 构建字典与表格做数据富化, 覆盖多种方式: 直接, 任务配置, 字典表格函数, RDS-MySQL, 其他Logstore等
Elasticsearch全观测技术解析与应用（构建日志、指标、APM统一观测平台） 立即下载