一、背景

在日常开发中，通常为了方便调试、方便查问题，会打印很多 INFO 级别的日志。

随着访问量越来越大，一不小心，某个日志文件一天的 size 就大于了某个阈值（如 5G），于是，收到了优化日志大小的告警，一定时间内不优化反馈给你主管，囧...

日志过大容易导致一些运维操作消耗机器性能，如日志文件检索、数据采集、磁盘清理等。

那么，日志瘦身哪些常见的思路呢？ 本文结合某个具体案例谈谈我的看法。

二、日志瘦身方法论

2.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 日志的 log 打印成 DEBUG 级别，查问题时自动提升为INFO 日志。 为了避免误会，区分 DEBUG 提升 INFO 的日志和普通 INFO 日志，加上 类似【debug2info】 日志前缀。

当然，你也可以搞一些其他骚操作，这里只是举个例子，请自行举一反三。

2.2 合并打印