关于java:日志瘦身骚操作从5G优化到1G

背景

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

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

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

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

日志瘦身方法论

| 只打印必要的日志

有时候为了不便测试，长期打印很多 INFO 级别日志。对于这种日志，等我的项目上线前，能够将非必要的日志删除或者调整为 DEBUG 级别。

但有些场景下有些日志可打印为 DEBUG 也可打印为 INFO，打印成 INFO 级别占空间，打印成 DEBUG 级别线上查问题的时候又须要用到，肿么办？

咱们能够对日志工具类进行革新，反对上下文传递某个开关时（失常调用没有这个开关，通过公司的 Tracer 或者 RPC 上下文传递），能够长期将 DEBUG 日志晋升为 INFO 级别。

伪代码如下：

if(log.isDebugEnable()){log.debug(xxx);
}else if(TracerUtils.openDebug2Info()){log.info("【debug2info】"+xxx);
}

这样，能够将一些纠结是否要打印成 INFO 日志的 log 打印成 DEBUG 级别，查问题时主动晋升为 INFO 日志。

为了防止误会，辨别 DEBUG 晋升 INFO 的日志和一般 INFO 日志，加上相似【debug2info】日志前缀。

当然，你也能够搞一些其余骚操作，这里只是举个例子，请自行触类旁通。

| 合并打印

有些能够合并的日志，能够思考合并。

如在同一个办法前后都打印了 INFO 日志：

INFO   [64 位 traceId]   XXXService 执行前  size =10 INFO   [64 位 traceId]   XXXService 执行后  size =4

能够合并成一条：

INFO [64 位 traceId] XXXService 执行前 size =10 执行后 size =4

| 简化 & 缩写 & 压缩

某个日志十分有必要，然而打印的对象有些大，如果能够满足问题排查需要的状况下，咱们能够：

• 抉择只打印其 ID
• 创立一个只保留关键字段的日志专用对象，转化为日志专用对象，再打印。
• 能够用缩写，如 write 简化为 w, read 简化为 r，execute 简化为 e 等；比方 pipeline 中有 20 个外围 bean，打印日志时能够应用不同的编号代替 bean 全称，如 S1，S2，尽管没那么直观，但既能够查问题，又升高了日志量。

优化案例

| 场景形容

一个业务场景波及很多 bean，为了复用一些通用逻辑，这些 bean 都继承自某个抽象类。

在抽象类中，定义了执行 bean 前后的一些通用逻辑，如执行前后打印以后 pipeline 中 item 的数量。最初一个 bean 执行完后果转换后须要打印出后果。

| 优化剖析

①只打印必要日志

只打印必要日志：

• 因为以后 bean 执行前 相当于前一个 bean 执行后，因而只打印执行后的日志就能够，执行前的 INFO 日志能够删除或者改为 DEBUG（只打印必要日志）

• 通常问题只呈现在执行前后 size 不统一的状况下，因而执行后打印日志前能够加个判断，如果执行前后 size 雷同则不打印。

  伪代码如下：

  if(sizeBefore != sizeAfter){log.info("service:{}, 前 size:{}, 后 size:{}", getName(),sizeBefore, sizeAfter)
  }

  这招成果很显著，因为大多数 bean 的执行前后 size 是雷同的，就不会打印这条日志。而假如之前有 20 个，这条日志就须要打印 20 次，改良后可能只须要打印 2-3 次。

②日志合并

为了不便查问题还须要打印执行前的 size，那么将执行前的 size 记录在内存中，打印执行后日志时多打印出执行前的 size。

伪代码如下：

log.info("service:{}, 执行前 size:{}", getName(),sizeBefore)

log.info("service:{}, 执行后 size:{}", getName(),sizeBefore, sizeAfter)

合并后：

log.info("service:{}, 前 size:{}, 后 size:{}", getName(),sizeBefore, sizeAfter)

③日志精简

对于最终后果，将后果对象（如 XXDTO）转化为只包含要害信息，如 id, title 的日志对象（XXSimpleLogDTO），转化为日志对象后再打印。

log.info("resultId:{}",result.getId());

或者：

log.info("result:{}",toSimpleLog(result));

| 成果评估

该日志一天产生 5G 左右，这里百分之 80% 左右都是打印执行前后的 size，10% 左右是打印最终后果，还有一些其余的日志。

通过上述办法优化后，每天日志量有余 1G。

在满足排查问题的须要，又实现日志瘦身之间进行了取舍。

总结

日志瘦身须要进行衡量，保留排查问题的必要日志状况下尽可能精简。能够采纳删除不必要日志，合并日志，日志简化等形式进行优化。

咱们还能够进行一些骚操作，反对线上 DEBUG 长期晋升 INFO（当然也能够应用 arthas）来辅助咱们查问题。

文章起源：https://c1n.cn/mtr19