近一年多以来想要分享知识的欲望降低了许多，不知道是否是近一年来工作较忙的原因，导致整个21年没有对外输出什么内容，唯一的一篇 “Log4j2 Jndi 漏洞原理解析、复盘” 还是在趁热想抓波热点的情况下写的这篇文章（21年12月10号爆出漏洞、11号公司内修复、12号凌晨05:00趁热发布文章，发布完以后直接埋头睡了一天，现在想来简直丧心病狂！）。
转眼已经到了2022，复盘2021的时候会发现并非如此，整个2021年是有做很多输入的，但由于并没有对外输出，而只是将对应的内容简单的记录到了自己的笔记中，导致回头再看时，会发现笔记中的很多内容并不系统，只是记录了一个点的问题，而非面。
输出是一个很好的习惯，输入并输出的过程也是在不断的翻新自我知识体系的过程，在持续输出的过程中，不仅帮助了自己也可能会帮助到他人。一举多得。
所以，就用这篇来作为2022年自由互联的第一篇吧，GO，GO！ （PS：该篇文章已经在笔记中躺了有段时间了、略微整理后，重新分享出来。）
背景公司当前日志平台一天所沉淀的业务日志有近600亿条，40T左右的大小，随着公司内降本增效的事项推进，再加上业务方业务日志越来越多等问题，导致整个日志平台的资源是越发紧张的。
为了约束业务团队的日志数量，除了一些硬性的手段（日志SDK端采样、服务端采样、成本平摊），以及通过一些硬性的指标，要求业务团队的日志条数链路比、日志大小链路比 必须控制在一个合理的范围内之外，还需要一些小的科普。
而这个科普便是这次内容的主题 “日志最佳实践”，目的是为了让部分研发知晓：“噢，日志原来也是要像代码一样不断优化的啊”。
前言日志用来记录用户操作、系统运行状态等，是一个系统的重要组成部分。然而，由于日志通常不属于系统的核心功能，所以常常不被团队成员所重视，在出现问题需要通过日志来定位时，才发现日志还存在很多问题；日志记录的好坏直接关系到系统出现问题时定位的速度，同时通过对日志的监控和分析，可以提前发现系统可能的风险，避免线上事故的发生。
现阶段我们的监控系统已经为我们的服务稳定性提供了较强的支撑，其中实时的异常大盘、日志的异常告警、日志的统一收集检索以及日志和链路的串联等功能为我们在微服务体系下问题的诊断提供了快速的排查方案。但随着时间的推移，代码中的日志质量持续降低（当项目变大时，项目的代码也存在一样的问题，越写越乱）。随着越来越多不规范的日志开始出现，除了会增加监控系统的承压，还会对线上的问题定位、稳定性监控等造成干扰。所以，日志的优化则势在必行，一方面监控系统降压降本，另一方面增加线上服务的稳定性及故障快速定位的能力。
原创声明：