本文共 1534 字，大约阅读时间需要 5 分钟。

案例

某天，可爱的产品经理跑过来对陈皮说，一个使用了好久，近期也未发过版的xx服务挂了！！需要赶紧处理下，并输出事故报告。

服务挂了，要尽快恢复，首先肯定使用重启大法。果不其然，运维人员以迅雷不及掩耳之势已经将服务重启了，并且服务运行也正常了。

就只剩输出事故报告了，因为作为一个内部使用服务，于是没接入ELK日志分析平台，然而在向运维人员将服务的日志文件下载下来分析的时候，运维人员反馈没有日志了，就只剩当天重启后的一个日志文件了！！！

没有了日志，如何输出事故报告，这不是要拿程序员祭天？？好家伙，直呼好家伙！！

排查

首先，想到的办法肯定是要先甩锅啦！！甩锅运维，是不是你使用万能命令rm -rf /了。然而，倔强的运维死活不承认，那只能另寻他法。

既然不是人为删除，那会不会是服务器上有定时清理日志文件的脚本程序，经排查不会对此服务下的日志进行清理。

既然排除了他杀，那会不会是自杀呢？于是只能分析工程本身了。因为此项目原先是其他人开发维护的，于是陈皮pull了此工程，打开了日志配置文件logback.xml，分析是有将日志输出到本地日志文件中。其二，也对日志文件按天按大小切割保存，即单个文件大小上限50MB，并且保存最近7天的日志文件，属实没毛病啊，部分配置信息如下：

   
   
   	
    
     ./logs/server.log
    	
    		
     
      ./logs/server%d{yyyy-MM-dd}_%i.log
     		
     
      ${maxHistory}
     		
     			
      
       ${maxFileSize}
      		
     	
    	
    		
     
      UTF-8
     		
     
      ${layout}
     	
    
   

于是看能不能帅锅给可爱的产品经理，询问产品经理什么时候发现的这个问题，最近一次使用了什么功能。产品经理反馈今天想登录这个系统导出一些分析数据，想给开发多提几个需求，上一次使用这个系统是过年前几天的时候了。

好家伙，上一次使用都是年前时候了，可能这服务挂了好长一段时间了，因为很少人用，所以没发觉。不过即使年前挂了，也会至少保留服务挂当天前7天的日志文件啊。

这时，想到向运维要日志文件时候，运维已经将服务重启了，根据工程日志配置文件的配置信息，真相水落石出了。

原来服务早就已经挂了，而且挂了至少有7天了，并且工程日志配置保存的最长时间是7天，服务一重启，根据配置策略，直接将7天前的日志文件全部清除了！！然后生成重启后当天的日志文件！所以，这锅谁来背？

再询问产品经理，也证实了这点。产品经理在年前使用此系统导出了一年将近几十万的数据，并且当时导出一直转圈圈，等待许久就直接关了系统。而且服务设置的JVM内存又不是很大，很有可能当时就OOM了。针对此问题，服务加大了内存，并且对导出数据量做了限制。

优化解决

为避免再次发生这样的事故，可以通过以下几个手段来解决：

1. 灾备，对日志做多份备份处理，不仅要将日志保存在服务器本地文件，还需要将日志文件备份到其他地方或者接入ELK日志分析平台。
2. 工程日志配置文件保存时长从7天扩大到30天，不过具体多久根据自身场景来设置。
3. 服务出现事故，首先保留案发现场，对于日志和服务线程堆栈等信息进行保留，再恢复服务。
4. 服务接入监控平台，出事故及时通知相关负责人，及时解决，避免滞后带来更严重的事故。

关于Logback日志相关知识，最近在看官网的文档学习，后续会整理一些有用的知识点发出来。

Logback官网地址：

转载地址：https://javalib.blog.csdn.net/article/details/115186938 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！