十行代码，让日志存储成本降低80% _日志

日志是系统中熵增最快的一个模块，它承载了业务野蛮生长过程中的所有副产品。本文介绍了一个日志治理案例，围绕降本和提效两大主题，取得一定成效，分享给所有渴望造物乐趣的同学。
前言
履约管理是一个面向物流商家的OMS工作台，自从初代目把架子搭起来之后，就没有继续投入了，后来一直是合作伙伴同学在负责日常维护和需求支撑。经过几年的野蛮生长，系统已经杂草丛生，乱象百出。再后来，甚至一度成为一块无主之地，走行业共建的方式来支持。对于一个不支持行业隔离的系统，行业共建意味这个系统将快速腐化。
两年前我开始接管履约管理，来到这片广阔的蛮荒之地，正如所有那些渴望造物乐趣并且手里刚好有锤子镰刀的人，我就像一匹脱缰的野马，脑子里经常会产生很多大胆且新奇的想法，希望借此把履约管理打造成一个完美的系统。只可惜真正能够付诸实践的少之又少，本篇就是为数不多得以落地，并且有相当实用价值idea中的一个，整理出来分享给有需要的同学做参考。
一、日志乱象
日志是日常开发中最有可能被忽视，最容易被滥用的一个模块。被忽视是因为打日志实在是一个再简单不过的事，前人设计好了一个logback.xml，后面只需要依样画葫芦定义一个logger，随手一个info调用就搞定，他甚至不确定这条日志能不能打出来，也不知道会打在哪个文件，反正先跑一次试试，不行就换error 。
被滥用是因为不同场景日志的格式内容千差万别，或者说日志打法太灵活，太随意了，风格太多样化了，以至于几乎每个人一言不合就要自己写一个LogUtil，我见过最夸张的，一个系统中用于打日志的工具类，有二三十个之多，后人纠结该用哪个工具可能就要做半个小时的思想斗争，完美诠释了什么叫破窗效应。
最好的学习方式就是通过反面教材吸取教训，下面我们列举一些最常见的日志设计开发过程中的问题。
1.分类之乱
一般来说，一个系统必然需要设计多个日志文件以区分不同业务或场景，不可能所有的日志都打到一个文件里。但是怎么进行分类，没人告诉我们，于是就有了各种各样的分类。
按系统模块分。这种分类应该是最基础的一种分类，也是最有层次感的分类。比如履约服务中枢的系统分层。基本上每一层对应一个日志文件。

文章插图
按租户身份分。一般中台系统都会支持多个租户(行业)，每一个租户单独对应一个日志文件。这种分类一般不会单独使用，除非你要做完全意义上的租户隔离。
意识流分类法。不符合MECE法则，没有清晰统一的分类逻辑，按业务分，按系统模块分，按接口能力分，按新老链路分，各种分法的影子都能看到，结果就是分出来几十个文件，打日志的人根本就不知道这一行的日志会打进哪个文件。
以上说的各种分类方式，都不是绝对纯粹的，因为无论哪一种，无论一开始设计的多么边界清晰，随着时间的推进，最后都会演变为一个大杂烩。

某人希望单独监控某个类产生的日志，新增日志文件；
新增了一个业务，比如一盘货，想单独监控，新增日志文件；
发起了一场服务化战役，针对服务化链路单独监控，新增日志文件；
某个业务想采集用户行为，又不想全接日志消息，新增日志文件；
资损敞口的场景，需要特别关注，新增日志文件；
特殊时期内产生的日志，比如大促，新增日志文件；

凡此种种，不一而足。发现没有，总有那么一瞬间能让人产生新增日志文件的神经冲动，他们的诉求和场景也不可谓不合理，尽管这些日志的维度完全不相关，然而没有什么能阻止这种冲动。最开始的那一套日志设计，就像一个濒临死亡的大象，不断地被不同的利益方从身上扯下一块分去。
2.格式之乱
对于日志需要有一定的格式这点相信没有人会有异议，格式的乱象主要体现在两个方面：
第一个是格式的设计上，有些系统设计了非常复杂的格式，用多种分隔符组合，支持日志内容的分组，用关键词定位的方式代替固定位置的格式，同时支持格式扩展，这对人脑和计算机去解析都是一种负担。
第二个是同一个日志文件，还能出现不同格式的内容，堆栈和正常业务日志混杂。