一次线上大日志打挂机器引发的思考

本文通过一次日志打满问题引发的一次思考，探讨了常用日志问题的解决套路，引申思考了2个技术问题，其一：如何大日志预防与监控；其二：老应用如何快速支持日志降级能力，并在最后提供了一点技术上的解法思路供参考。

前序

收到监控报警短信，一看是某线上机器磁盘被打满，已经快100%了，线上业务反馈页面请求无响应，出现舆情，作为开发的我，立马用运维工具，执行应用日志清理，过一段时间，继续看xflush磁盘监控，发现日志磁盘日志在15分钟内又将被打满，思考下今天并不是发布日，最近也没有任何线上变更，只能硬着头皮继续不断清理日志，同时定位问题。。。。

思考

这是最近一次我碰到的磁盘问题解决过程描述，大部分同学应该都会遵循“先止损再排查”的稳定性故障解决思路，即先采取措施快速进行止损，降低业务损失，或恢复/降级用户体验，再事后进行问题定位，将问题进行刨根问底，直至解决问题，线上恢复，最后进行复盘整治等等。

套路

每一个专业的开发，在不断的事件解决过程中，都形成一套成熟的、有效的、满足上述过程的脚手架，或者问题解决套路。比如我的“磁盘打满问题解决套路”：

• 快速止损

1. 执行日志清理，可选择的方式包括：1）登录跳板机，使用pgp进行批量定点清理，这种方式一般适用于脚本失效情况下使用，大促前最好先把脚本写好；2）直接登录机器，使用sudo rm -f xxx；注意：不能删除一个正在写入的日志，否则磁盘空间不能释放。4）针对日志代码写的有问题情况，比如直接写大量日志到了service_stdout.log（很久没有重启也有可能），不能强删，可以echo " " > service_stdout.log解决。
2. 线上直接置换机器。好端端的为何要进行机器置换呢？这个主要针对日志打的过快，造成机器已经不堪重负，命令脚本都已经无法执行了，甚至机器都登录不了，这种情况只能进行置换解决。需要注意的是：置换完成后，要检查sls的监控机器配置，如果是写死的，要记得调整。

1. 日志降级（若有）。使用开关方式开启日志降级，比如只打印error级别日志、完全不打印日志，在大促前要有预案。

• 问题定位

登录机器，使用du -h --max-depth=0 ./* 2>&1 | sort -t ' ' -k1gr命令走一遍，把日志有问题的文件找到。找到日志文件后，要揪出这个小鬼来，有时候不太容易。比较常见的情形是某代码不断循环打印了超大日志，比如打印了导入的文件。。。。当碰到这种情况，去机器下看日志就像下面一样。

根本看不到日志是从哪里打印的。。。。