本文通过一次日志打满问题引发的一次思考,探讨了常用日志问题的解决套路,引申思考了2个技术问题,其一:如何大日志预防与监控;其二:老应用如何快速支持日志降级能力,并在最后提供了一点技术上的解法思路供参考。
前序
收到监控报警短信,一看是某线上机器磁盘被打满,已经快100%了,线上业务反馈页面请求无响应,出现舆情,作为开发的我,立马用运维工具,执行应用日志清理,过一段时间,继续看xflush磁盘监控,发现日志磁盘日志在15分钟内又将被打满,思考下今天并不是发布日,最近也没有任何线上变更,只能硬着头皮继续不断清理日志,同时定位问题。。。。
思考
这是最近一次我碰到的磁盘问题解决过程描述,大部分同学应该都会遵循“先止损再排查”的稳定性故障解决思路,即先采取措施快速进行止损,降低业务损失,或恢复/降级用户体验,再事后进行问题定位,将问题进行刨根问底,直至解决问题,线上恢复,最后进行复盘整治等等。
套路
每一个专业的开发,在不断的事件解决过程中,都形成一套成熟的、有效的、满足上述过程的脚手架,或者问题解决套路。比如我的“磁盘打满问题解决套路”:
- 快速止损
- 执行日志清理,可选择的方式包括:1)登录跳板机,使用pgp进行批量定点清理,这种方式一般适用于脚本失效情况下使用,大促前最好先把脚本写好;2)直接登录机器,使用sudo rm -f xxx;注意:不能删除一个正在写入的日志,否则磁盘空间不能释放。4)针对日志代码写的有问题情况,比如直接写大量日志到了service_stdout.log(很久没有重启也有可能),不能强删,可以echo " " > service_stdout.log解决。
- 线上直接置换机器。好端端的为何要进行机器置换呢?这个主要针对日志打的过快,造成机器已经不堪重负,命令脚本都已经无法执行了,甚至机器都登录不了,这种情况只能进行置换解决。需要注意的是:置换完成后,要检查sls的监控机器配置,如果是写死的,要记得调整。
- 日志降级(若有)。使用开关方式开启日志降级,比如只打印error级别日志、完全不打印日志,在大促前要有预案。
- 问题定位
登录机器,使用du -h --max-depth=0 ./* 2>&1 | sort -t ' ' -k1gr命令走一遍,把日志有问题的文件找到。找到日志文件后,要揪出这个小鬼来,有时候不太容易。比较常见的情形是某代码不断循环打印了超大日志,比如打印了导入的文件。。。。当碰到这种情况,去机器下看日志就像下面一样。