日志瘦身骚操作:从 5G 优化到 1G,牛逼!!

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 日志瘦身骚操作:从 5G 优化到 1G,牛逼!!


背景

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

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

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

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

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

日志瘦身方法论

只打印必要的日志

有时候为了方便测试,临时打印很多 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 ,虽然没那么直观,但既可以查问题,又降低了日志量。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

优化案例

场景描述

一个业务场景涉及很多 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)来辅助我们查问题。

你还有哪些不错的日志瘦身技巧?欢迎在文章末尾评论和我交流。



相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
相关文章
|
12天前
|
缓存 Java 应用服务中间件
Spring Boot配置优化:Tomcat+数据库+缓存+日志,全场景教程
本文详解Spring Boot十大核心配置优化技巧,涵盖Tomcat连接池、数据库连接池、Jackson时区、日志管理、缓存策略、异步线程池等关键配置,结合代码示例与通俗解释,助你轻松掌握高并发场景下的性能调优方法,适用于实际项目落地。
188 4
|
10月前
|
人工智能 自动驾驶 5G
5G频谱规划:资源优化与共享策略
【10月更文挑战第27天】
594 4
|
5月前
|
监控 安全 BI
优化 Apache 日志记录的 5 个最佳实践
Apache 日志记录对于维护系统运行状况和网络安全至关重要,其核心包括访问日志与错误日志的管理。通过制定合理的日志策略,如选择合适的日志格式、利用条件日志减少冗余、优化日志级别、使用取证模块提升安全性及实施日志轮换,可有效提高日志可用性并降低系统负担。此外,借助 Eventlog Analyzer 等专业工具,能够实现日志的高效收集、可视化分析与威胁检测,从而精准定位安全隐患、评估服务器性能,并满足合规需求,为强化网络安全提供有力支持。
138 0
优化 Apache 日志记录的 5 个最佳实践
|
7月前
|
关系型数据库 MySQL
图解MySQL【日志】——磁盘 I/O 次数过高时优化的办法
当 MySQL 磁盘 I/O 次数过高时,可通过调整参数优化。控制刷盘时机以降低频率:组提交参数 `binlog_group_commit_sync_delay` 和 `binlog_group_commit_sync_no_delay_count` 调整等待时间和事务数量;`sync_binlog=N` 设置 write 和 fsync 频率,`innodb_flush_log_at_trx_commit=2` 使提交时只写入 Redo Log 文件,由 OS 择机持久化,但两者在 OS 崩溃时有丢失数据风险。
178 3
|
10月前
|
JSON 监控 JavaScript
Node.js-API 限流与日志优化
Node.js-API 限流与日志优化
|
11月前
|
Arthas 监控 Java
JVM知识体系学习七:了解JVM常用命令行参数、GC日志详解、调优三大方面(JVM规划和预调优、优化JVM环境、JVM运行出现的各种问题)、Arthas
这篇文章全面介绍了JVM的命令行参数、GC日志分析以及性能调优的各个方面,包括监控工具使用和实际案例分析。
1032 3
|
11月前
|
机器学习/深度学习 算法 5G
|
11月前
|
监控 自动驾驶 5G
|
11月前
|
存储 监控 固态存储
如何监控和优化 WAL 日志文件的存储空间使用?
如何监控和优化 WAL 日志文件的存储空间使用?
304 1
|
缓存 监控 算法
分析慢日志文件来优化 PHP 脚本的性能
分析慢日志文件来优化 PHP 脚本的性能