如何将日志最佳实践转化为一个？

近一年多以来想要分享知识的欲望降低了许多，不知道是否是近一年来工作较忙的原因，导致整个21年没有对外输出什么内容，唯一的一篇 “Log4j2 Jndi 漏洞原理解析、复盘” 还是在趁热想抓波热点的情况下写的这篇文章（21年12月10号爆出漏洞、11号公司内修复、12号凌晨05:00趁热发布文章，发布完以后直接埋头睡了一天，现在想来简直丧心病狂！）。 转眼已经到了2022，复盘2021的时候会发现并非如此，整个2021年是有做很多输入的，但由于并没有对外输出，而只是将对应的内容简单的记录到了自己的笔记中，导致回头再看时，会发现笔记中的很多内容并不系统，只是记录了一个点的问题，而非面。 输出是一个很好的习惯，输入并输出的过程也是在不断的翻新自我知识体系的过程，在持续输出的过程中，不仅帮助了自己也可能会帮助到他人。一举多得。 所以，就用这篇来作为2022年博客园的第一篇吧，GO，GO！ （PS：该篇文章已经在笔记中躺了有段时间了、略微整理后，重新分享出来。） 背景 公司当前日志平台一天所沉淀的业务日志有近600亿条，40T左右的大小，随着公司内降本增效的事项推进，再加上业务方业务日志越来越多等问题，导致整个日志平台的资源是越发紧张的。 为了约束业务团队的日志数量，除了一些硬性的手段（日志SDK端采样、服务端采样、成本平摊），以及通过一些硬性的指标，要求业务团队的日志条数链路比、日志大小链路比 必须控制在一个合理的范围内之外，还需要一些小的科普。 而这个科普便是这次内容的主题 “日志最佳实践”，目的是为了让部分研发知晓：“噢，日志原来也是要像代码一样不断优化的啊”。 前言 日志用来记录用户操作、系统运行状态等，是一个系统的重要组成部分。然而，由于日志通常不属于系统的核心功能，所以常常不被团队成员所重视，在出现问题需要通过日志来定位时，才发现日志还存在很多问题；日志记录的好坏直接关系到系统出现问题时定位的速度，同时通过对日志的监控和分析，可以提前发现系统可能的风险，避免线上事故的发生。 现阶段我们的监控系统已经为我们的服务稳定性提供了较强的支撑，其中实时的异常大盘、日志的异常告警、日志的统一收集检索以及日志和链路的串联等功能为我们在微服务体系下问题的诊断提供了快速的排查方案。但随着时间的推移，代码中的日志质量持续降低（当项目变大时，项目的代码也存在一样的问题，越写越乱）。随着越来越多不规范的日志开始出现，除了会增加监控系统的承压，还会对线上的问题定位、稳定性监控等造成干扰。所以，日志的优化则势在必行，一方面监控系统降压降本，另一方面增加线上服务的稳定性及故障快速定位的能力。 原创声明：作者：陈咬金、 博客地址：https://www.cnblogs.com/zh94/ 日志的分类 日志从功能来说，可分为诊断日志、统计日志、审计日志。 诊断日志， 典型的有： 请求入口和出口 外部服务调用和返回 资源消耗操作: 如读写文件等 容错行为：如云硬盘的副本修复操作 程序异常： 如数据库无法连接 后台操作：定期执行删除的线程启动、关闭、配置加载 统计日志： 用户访问统计：用户IP、上传下载的数据量，请求耗时等。（常用的Log Metric 则是统计日志） 审计日志： 管理操作、系统安全事件、非法访问记录等 需要避免的日志记录方式 在写代码的过程中，统计和审计日志是带有强烈目的性、功能性的，比如：用户访问统计的图表，非法访问的记录等。 但是针对诊断日志则不然，由于我们无法确定系统在具体哪行代码中会出现异常，所以诊断日志的添加也就因人而异，不同研发的风格，喜欢在不同的代码处增加诊断日志。 比如：有些研发同学喜欢在方法的入口处增加日志，有些研发则是在可能会出现不确定性的判断体中增加日志。这些都没问题，毕竟某块代码哪里最容易出现问题，最需要诊断日志，这些只有具体的研发才知晓。 但是我们需要约束并避免的情况是： 1、日志中不要记录无用的信息 如下图中的服务日志：单条日志的长度已经超出了5000的长度，并已经触发了服务端的日志截断操作。（既然是诊断日志，应该是诊断该方法内的部分属性，或者可能出现问题的属性，而不应该是全部输出） 2、不要记录无用的日志（不利于问题分析诊断的日志） 如下图中：日志Msg为 “threadLocal进行清除”这段日志，如果说这段日志有没有意义？“有的”，这段日志表示 threadLocal被清除了，很直接明了。但是如果说这段日志对问题的分析诊断有没有作用？作用极小。