作者:kobe
部门:质量保障
没有仪表盘的车,那是自行车,只要会骑,人人都能骑······ 有仪表盘的车,没有故障灯,会开车的人可以开但也有坏的时候······ 有仪表盘的车,如果全是ERROR告警,估计也没人敢开,因为不知道会发生什么······
客户反馈系统又不好使了,客满找到了技术,技术才知道系统又崩了···
技术开始排查,发现全是ERROR日志,大海捞针,排查难,定位难,故障持续时间长,恢复慢
事后复盘,灵魂拷问:有报ERROR吗?有;有告警嘛?有;那为啥没有第一时间发现呢?日志太多了,告警太多了,被淹没了,关注不到···
以上这些是问题嘛?是,客观存在,是我们一年前面临的问题,怎么办?想办法解决呗··· 面对线上问题,故障频发,发现手段滞后,只能依赖商家客户的反馈,进而导致客服成本高,压力大,针对这种情况,首先明确一个问题,线上问题会被彻底消灭嘛?答案是:不会,那既然不会我们还能做什么呢?第一时间发现,快速修复---要做到这些,监控告警是非常有效的第一时间发现故障的手段,我们期望达到的目标是每一次告警都是有效的,为了这个目标我们做了两个专题:一个是ERROR日志治理的专项工作;另外一个是提升系统业务水位监控告警的敏感度和精确度;这两个专题相辅相成,其中重点介绍一些系统ERROR日志的治理经验总结,这项治理给我们带来的收益是很明显的。
怎么实现呢?先看看问题:
我们先说说ERROR日志的问题,打印日志简单,打印好日志-----难!!!
我们遇到一个问题,什么时候打印ERROR,什么时候打印Waring,Info就不说了?
确定标准,我们要根据各自系统的情况,确定目标:将每天的error日志降到多少条,100,200···有个目标就行。
具体怎么做的?每天关注生产环境的ERROR日志,进行归类分析并及时解决,持续做好直到达成目标。
如果只是针对ERROR日志进行处理的话,我们能达到的状态是持续的投入解决问题,来降低ERROR日志的数量,另外一个角度要将已经出现的问题进行总结,定期和组内研发/测试同学分享,避免问题重复出现,从根本上减少问题的发生,形成一个良性的循环状态。 最终达到目标:每一次告警,都是有效问题需要介入处理,缩短故障的影响时间和影响面,规范的日志内容提高了排查的效率;
近一年绝大部分线上问题都是监控告警首先感知,监控告警的敏感度有了极大的提升,在线上问题升级故障前就发现,有效减少了线上故障。 生产ERROR日志的产生类型也极大的减少,从原来每天上百种类型到目前的个位数,数量从之前的最高峰值上万到现在的平均每天100条左右;
“有这么一句话,错误日志应该做到,即使离开了代码情境,也能清晰的描述发生了什么。” 这就对了日志提出了如下的要求:
我们通常知道对ERROR日志进行告警的配置,配置在单位时间内Waring达到一定数量进行告警,但是存在这样一种情况,在业务上是正常的报错(例如参数校验未通过,可能是使用姿势的问题),这个时候没有打ERROR打的是Waring,但是正常情况下这个Waring会一直处于低水位状态,如果某一天水位出现大幅上升也代表存在问题,这个时候要配置对应的水位告警,具体的水位条件需要根据各个业务的具体情况和发展进行分析和动态的调优。
除了日志级别的监控外,在一些数据统计上也可进行监控,例如我们对出金系统每天的出金数据进行统计并通知出来,每天成功,失败,异常等状态的数据会是一个比较稳定的状态,某一天如果数据出现明显的变化,就代表系统很有可能存在问题,这是另外一个维度的监控。