要求输出事故报告，线上日志文件却不见了！！
案例
某天，可爱的产品经理跑过来对陈皮说，一个使用了好久，近期也未发过版的 xx 服务挂了！！需要赶紧处理下，并输出事故报告。
服务挂了，要尽快恢复，首先肯定使用重启大法。果不其然，运维人员以迅雷不及掩耳之势已经将服务重启了，并且服务运行也正常了。
就只剩输出事故报告了，因为作为一个内部使用服务，于是没接入 ELK 日志分析平台，然而在向运维人员将服务的日志文件下载下来分析的时候，运维人员反馈没有日志了，就只剩当天重启后的一个日志文件了！！！
没有了日志，如何输出事故报告，这不是要拿程序员祭天？？好家伙，直呼好家伙！！
排查
首先，想到的办法肯定是要先甩锅啦！！甩锅运维，是不是你使用万能命令rm -rf /了。然而，倔强的运维死活不承认，那只能另寻他法。
既然不是人为删除，那会不会是服务器上有定时清理日志文件的脚本程序，经排查不会对此服务下的日志进行清理。
既然排除了他杀，那会不会是自杀呢？于是只能分析工程本身了。因为此项目原先是其他人开发维护的，于是陈皮 pull 了此工程，打开了日志配置文件 logback.xml，分析是有将日志输出到本地日志文件中。其二，也对日志文件按天按大小切割保存，即单个文件大小上限 50MB，并且保存最近 7 天的日志文件，属实没毛病啊，部分配置信息如下：
于是看能不能帅锅给可爱的产品经理，询问产品经理什么时候发现的这个问题，最近一次使用了什么功能。产品经理反馈今天想登录这个系统导出一些分析数据，想给开发多提几个需求，上一次使用这个系统是过年前几天的时候了。
好家伙，上一次使用都是年前时候了，可能这服务挂了好长一段时间了，因为很少人用，所以没发觉。不过即使年前挂了，也会至少保留服务挂当天前 7 天的日志文件啊。
这时，想到向运维要日志文件时候，运维已经将服务重启了，根据工程日志配置文件的配置信息，真相水落石出了。
原来服务早就已经挂了，而且挂了至少有 7 天了，并且工程日志配置保存的最长时间是 7 天，服务一重启，根据配置策略，直接将 7 天前的日志文件全部清除了！！然后生成重启后当天的日志文件！所以，这锅谁来背？
再询问产品经理，也证实了这点。产品经理在年前使用此系统导出了一年将近几十万的数据，并且当时导出一直转圈圈，等待许久就直接关了系统。而且服务设置的 JVM 内存又不是很大，很有可能当时就 OOM 了。针对此问题，服务加大了内存，并且对导出数据量做了限制。
优化解决
为避免再次发生这样的事故，可以通过以下几个手段来解决：
1. 灾备，对日志做多份备份处理，不仅要将日志保存在服务器本地文件，还需要将日志文件备份到其他地方或者接入 ELK 日志分析平台。
2. 工程日志配置文件保存时长从 7 天扩大到 30 天，不过具体多久根据自身场景来设置。
3. 服务出现事故，首先保留案发现场，对于日志和服务线程堆栈等信息进行保留，再恢复服务。
4. 服务接入监控平台，出事故及时通知相关负责人，及时解决，避免滞后带来更严重的事故。
关于 Logback 日志相关知识，最近在看官网的文档学习，后续会整理一些有用的知识点发出来。
Logback 官网地址：https://logback.qos.ch/
版权声明: 本文为 InfoQ 作者【陈皮的JavaLib】的原创文章。
原文链接:【http://xie.infoq.cn/article/c7ecf7a88b872b400a47863f4】。文章转载请联系作者。
CSDN博客专家，微信搜一搜 - 陈皮的JavaLib 2020.02.22 加入
CSDN博客专家，专注各项技术领域的Java开发工程师，微信搜一搜【陈皮的JavaLib】，关注后学习更多技术文章和一线大厂面试资料和技术电子书籍。
评论