1.背景在日常开发中，通常为了方便调试排查，会打印很多INFO级别的日志。随着访问量的增加，不小心某天某个日志文件的大小超过了一定的阈值（比如5G），于是收到优化日志大小的告警，不优化反馈给主管一定时间内，尴尬...过多的日志很容易导致一些运维操作消耗机器性能，比如日志文件检索、数据收集、磁盘清理等。那么，原木瘦身的常见思路有哪些呢？本文根据一个具体案例来谈谈我的看法。二、日志瘦身方法1、只打印必要的日志有时为了测试方便，会临时打印很多INFO级别的日志。对于此类日志，可以在项目上线前删除不需要的日志或者调整为DEBUG级别。但是，在某些场景下，某些日志可以打印为DEBUG或INFO。INFO级别打印占用空间，在线检查问题时需要DEBUG级别打印。我应该怎么办？我们可以修改日志工具类，支持在上下文中传递某个开关（普通调用没有这个开关，传递公司的Tracer或者RPC上下文），可以将DEBUG日志临时提升到INFO等级。伪代码如下：if(log.isDebugEnable()){log.debug(xxx);}elseif(TracerUtils.openDebug2Info()){log.info("[debug2info]"+xxx);}这样,一些在纠结是否将日志打印成INFO日志，会打印成DEBUG级别的日志，检查问题时会自动升级为INFO日志。为了避免误解，DEBUG提升INFO日志与普通INFO日志区别开来，增加了类似[debug2info]的日志前缀。当然你也可以搞一些其他的表演操作，这里只是举个例子，请举一反三。2.合并打印一些可以合并的日志，可以考虑合并。如果前后打印IN??FO日志同样的方法：INFO[64-bittraceId]XXXServicebeforeexecutionsize=10INFO[64-bittraceId]XXXServiceafterexecutionsize=4可以合并为一个：INFO[64-bittraceId]XXXService执行前size=10执行后size=43。需要对某条日志进行精简压缩，但打印出来的对象有点大。如果能够满足故障排除的需要，我们可以：选择只打印它的ID。创建一个只保留关键字段的日志特定对象，将其转换为日志特定对象，然后打印。可以使用缩写，比如write简化为w，read简化为r，execute简化为e等；比如pipeline中有20个核心bean，在打印日志的时候可以用不同的数字代替bean的全名，比如S1和S2，虽然不是那么直观，但是可以查问题，减少量日志。三、优化案例1、场景描述一个业务场景涉及到很多bean。为了重用一些公共逻辑，这些bean继承自一个抽象类。在抽象类中，定义了执行bean前后的一些通用逻辑，比如执行前后打印当前pipeline中item的个数。最后一个bean需要在进行结果转换后打印出结果。2、优化分析1）只打印必要的日志由于当前bean的执行等同于执行后的前一个bean，所以只打印执行后的日志。执行前的INFO日志可以删除或者改成DEBUG（只打印必要的日志）通常只有在执行前后大小不一致的时候才会出现这个问题，所以可以在执行后打印日志前加上判断。如果执行前后大小相同，则不会打印。（只打印必要的日志）伪代码如下：if(sizeBefore!=sizeAfter){log.info("service:{},beforesize:{},aftersize:{}",getName(),sizeBefore,sizeAfter)}这一招的效果很明显，因为大部分bean在执行前后大小是一样的，所以不会打印这条log。并且假设之前有20条，这个日志需要打印20次，改进后可能只需要打印2-3次。2）日志合并需要打印执行前的大小，方便检查问题，然后将执行前的大小记录在内存中，执行后打印日志时打印执行前的大小。（合并打印）伪代码如下：log.info("service:{},执行前大小:{}",getName(),sizeBefore)log.info("service:{},执行后大小:{}",getName(),sizeBefore,sizeAfter)merged:log.info("service:{},beforesize:{},aftersize:{}",getName(),sizeBefore,sizeAfter)3)日志简化对于最后result，将result对象（比如XXDTO）转换成只包含id、title等关键信息的log对象（XXSimpleLogDTO），转换成log对象后打印出来。log.info("resultId:{}",result.getId());或log.info("result:{}",toSimpleLog(result));3、效果评价日志一天产生5G左右，这里有一百个80%左右是打印执行前后的大小，10%左右是打印最后的结果，还有一些其他的日志。通过上述方法优化后，每日日志量小于1G。在满足故障排除需求和实现日志瘦身之间存在权衡。4.总结日志瘦身需要权衡，排查必要的日志尽量保持精简。可以通过删除不需要的日志、合并日志、简化日志等方式进行优化。我们也可以进行一些花哨的操作，支持在线DEBUG临时增加INFO（当然也可以使用arthas）来协助我们排查问题。
