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