一、背景

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

随着访问量越来越大，一不小心，某个日志文件一天的 size 就大于了某个阈值（如 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 日志的 log 打印成 DEBUG 级别，查问题时自动提升为INFO 日志。为了避免误会，区分 DEBUG 提升 INFO 的日志和普通 INFO 日志，加上类似【debug2info】日志前缀。

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