公司的架构师要求把日志封装成 LogUtil 类，提供 sdk 给各团队使用，并且不允许使用 slf4j 直接打印日志，请问各位这么做有哪些好处（我还没想到任何好处）？

[WillingXyz]

所有的日志打印都通过 LogUtil 类，并且日志上还得加上 code 来区分，比如 LogUtil.info("code101", "xxx")。 不能直接使用 slf4j 的 log.info("xxx")。

我完全不能理解这种操作，和他讨论了很多次，我觉得这样没有任何好处，因为 slf4j 本来就是一个门面，并且 logback 等实现提供了 Filter ，Coverter ，Appender 等扩展，完全可以通过 logback 来实现扩展，而不是侵入业务代码，并且业务也很难都改成这种方式啊。

他说是为了统一入口，便于以后扩展。但给不出具体的例子。工作了十几年了，都没产生好处，还要坚持封装。

ps：此人是我 leader 的 leader 。

请问：封装成 LogUtil 是否真的有好处，且相比 logback 扩展实现的更好，只是我没有想到，欢迎各位指点

补充下，统一日志框架、统一日志格式已经做了，通过提供 sdk 实现的。
另外，至于说限流、自定义序列化、增加上下文信息字段，这些可以通过 Filter 、Converter 等扩展无侵入的方式实现，所以我才觉得 LogUtil 没必要。
而打印日志的时候加个 code ，是 slf4j 做不到的，但没觉得加这个有什么好处，而且实施难度太大，有点理想化。
我业务日志是排查问题用的，不是用于数据分析的，我根据 logger name ，行号，模糊匹配都能定位，没必要用 code ，日志区分度有这么低吗

各位说的对，既然架构师说要做，那就按他说的做吧，我也只能执行啊。毕竟他是领导，和领导对着干没好处，学到了。

[ppllss]

@RightHand 没有毛病

[Feiex]

在#85 楼的基础上补充一下，
1. 不管是 log4j2 还是 logback ，在生产环境都会有一些坑（比如打 error 日志把 CPU 打满的），这时候没必要每个团队都去写 error 限流代码，让 Util 团队升级即可
2. 很多时候实体和异常的日志序列化并不尽如人意（例如三方包的实体 toString 缺很多东西、toJson 性能又很差），这时候也需要 Util 出手统一解决
3. 最重要的还有 trace 、channel 、position 、region 等等这种链路上下文的参数打印，每个人写一遍 format 也是没必要的，需要 Util 出手统一处理

[exmario]

你 Leader 的 Leader 这种级别你就别折腾了，他脾气已经足够好了，还和你讨论很多次

[jobsssss]

这是我最近的感悟，只要使用了第三方库，尽量都 不要直接使用三方库提供的方法；而是自己抽象一套接口出来供业务使用。

因为我遇到了第三方库作者把库给删了的情况，我需要更换第三方库；如果我自己做了抽象的话，那就只用在抽象层换下适配驱动就可以了；如果是直接使用的第三方库那麻烦真大了。

[Foxkeh]

可以私聊去问问设计目的是什么?
是要在远程记录日志? 统一处理数据脱敏? 还是特殊格式要求便于采集分析?

[testHu]

“他说是为了统一入口，便于以后扩展。但给不出具体的例子。”
这是和架构师对话的一个好话题，楼主为啥不和他多沟通呢？

大型互联网公司，做统一的日志工具是很常见的操作，因为日志都汇总到监控系统和大数据分析平台了。

[WillingXyz]

@Foxkeh
@testHu 沟通几次了，每次讲一个小时，他只是之前习惯是这么做的，所以觉得应该这么做，但这么做的好处讲不出来

[sharpless]

v2 还是闲人多啊，打起来 赶紧 打起来

[SWALLOWW]

入戏太深
这事跟你一点关系没有
朋友

听领导就对了，何况是这种也跟你没有关系的活，

[Kaiv2]

LogUtil.get(业务场景 Enum).info(fmt, msg);
如果是我想的这样，可能是为了方便后续的日志分析

[vhcn]

使用统一接口当然是方便拓展咯，比如现在你们日志写文件，日后假如想统一传阿里云 sls 是不是就不用挨个业务去部署上传脚本了，更新一下你这个库就行了；后续再有海外的业务了，做数据隔离是不是也直接都能对接海外的云服务了；假如你们日志中可能有用户敏感信息需要脱敏后落盘的，是不是也可以统一做脱敏规则不需要各自业务方自己注意规则了

[kehuduanbuxing]

实际效果没差别，通过各种拓展肯定都能实现。
但是从架构的角度看，依赖关系得到了优化。第三方包变为二次封装包的依赖，而非项目的依赖。
理论上一堆二次封装包就可以形成公司的核心依赖 XX Foundation （虽然实际上也没什么用，增加了稳定性也降低了灵活性）增加了稳定性就降低了工作门槛，可控也就可随时换人

[chenliangcl02]

这个是架构管理的问题，站得位置不同看到的视角不一样，站在你自己的角度是没好处，但是在管理角度，就是全局统一，对人加约束，避免五花八门的问题出现

[layxy]

我们就统一使用 LogUtil,日志调整啥的基本都是工具类内部统一调整,打印日志的地方不需要调整, 比如统一日志格式,日志降级都在 util 中做的

[LFL]

你太菜鸡了，这个都不懂，执行就行了

[k9982874]

@lucasdev
@bk201
你俩可能是有误会，可以使用 slf4j 作为底层输出，这没问题。
上层封装 LogUtil 底层随便换实现，没人说要从头再造轮子。
人家架构师也没不让用 slf4j ，再仔细读读原文。

[sagaxu]

@Feiex 102# slf4j 只是个接口，如果 log4j2 和 logback 不行，那就做一个同层面的 logutil 实现，不用侵入接口。项目里有一堆第三方库用到了 slf4j ，你不可能把那些库全都 fork 一遍改掉，做个平替的 implementation 正好统一解决问题。

[weixind]

多次讲，每次一个小时 ，还是你的 +2 ，依旧说服不了你。

1. 你 +2 脾气也太好。
2. v2 那么多人竟然还想着讲道理能够说服你。

[BeforeTooLate]

1.OP 不想做自己认为没有意义的事情
2.OP 一定要问出 CTO 这么做的意义
3.要么 OP 当 CTO ，要么还是劝你不要这么闲。既然你已经和 CTO 讨论过 2 次了，还有必要继续这个话题吗？就服从安排工作不就行了。你要什么结果，要 CTO 认输，说好的，经过几轮友好协商认为 OP 同学对的，暂时不要封装了。

[canvascat]

不要反驳领导，领导说怎么做就怎么做

[MasterC]

没有明显坏处或者缺陷的话，统一编码规范这种事情，还是听领导的

[expkzb]

是不是怕哪天爆出来 slf4j 有漏洞啥的

[000sitereg]

如果以后支持多语言....

[rockxsj]

你是领导他是领导？ 如果你要拒绝工作安排也是你要拿出来切实的统一日志 sdk 的明显缺点，而不是要他拿出来优点，如果你拿不出来那就老实做就完了。

[edotac]

没啥用，数据脱敏、数据清洗更好的实践定好日志采集格式，各个项目在 CICD 过程上上报日志目录，然后专门的服务来采集分析。
而不是每个技术栈维护一个 LogUtil 来上报一定格式的日志

[wenjun19931112]

1 、数据脱敏（统一做脱敏规则）
2 、日志收集（当你做多实例集群部署的时候，需要将多个实例的日志汇总收集，不然关键日志很难找）
3 、使用 code 方便监控（运维人员可以通过统计日志中的 code 做运营级别、系统级别的告警。如某个时间内注册用户激增、某一个异常报错树超过阈值）

[kerb15]

@WillingXyz #17 既然是+2 ，那他管辖范围内的人都得无条件用吧，以他的名义去 push

[Suaxi]

别纠结了，按领导的要求来就完事了（领导要的是干活的组员按他的要求来，很多时候自己心里知道就行）

[encro]

需要的可能是：

log = get_logger("name")
log.info(xxxx,[ddadasdf])

[encro]

要的就是一个统一的 log 而已。

这样修改 log 时候比较方便。先简单，后复杂，向后兼容。

[encro]

就是为了统一，方便以后修改日志的处理和存储，并没有什么很多需要解释的。


如果楼主这个不能想到，
哎，
建议早点转行。。。
不是我打击你。。。

[encro]

建议学习：

高内聚松耦合,高扇入低扇出

[Rorysky]

自主可控 打破国外垄断

[cornorj6]

这么多人讨论，有没有一种可能架构师之前搞其他语言的，习惯了 LogUtil 这种打日志的方法？ java 中 slf4j 以及非常好用了，根本不需要封装。话说回来，日志系统都是标配了，根本不需要考虑那些落在哪里。比如 k8s 你打在本地就行了，剩下是日志系统干的事儿。

[lucasdev]

@Feiex 这些对 Java 生态来说都不是问题，都有很成熟的方案，写在统一的 sdk 即可。
楼主也补充了，“统一日志框架、统一日志格式已经做了，通过提供 sdk 实现的。”

关于你提到的几点，分别有：1. logback filter 2. logback converter 3. MDC

但看了下楼主已经找架构师沟通过几次了，那就封装呗，干嘛跟领导做对。

[kilakilia007]

@dcsuibian 1.1 Thread 可以获取调用栈

[rangoBen]

LogUtil.log 是给你提供一个接口。
至于下面的实现是什么，以及后续他要再加什么，甚至是换一个日志打印内核，你不需要关心。这对业务对架构都是有好处的。

[zhaokun]

项目多了可以增加项目标识，然后有开源平台抓取项目标识遇到错误主动往企微群里通知，项目少怎么弄都可以

[hdfg159]

工作久了心累了，我觉得领导怎么说怎么做，属于公司盈利项目不要较真，又不是个人项目或者开源项目，这种环境下，代码能跑就行；如果有能力，可以去开源社区给日志框架提交 新功能增强拓展，这是应该做的。

从技术角度，个人觉得，都能通过日志框架拓展实现各种功能，不需要封装

[dcsuibian]

@kilakilia007 这个我知道
但是 Thread.currentThread().getStackTrace()会创建一个调用栈数组吧。我不清楚的是，如果高频调用的话，那么这个数组的创建是否会影响到日志框架的性能和 jvm 的内存占用。

[night98]

@dcsuibian #139 一般能提出这种问题的企业，没啥性能要求

[z1829909]

@CodeCodeStudy 直接通过关键字搜索不是更快吗, 为什么还需要再转一层呢.

[sampeng]

为啥都在说统一封装的好处呢，都不看原文到底？ op 说的很清楚了，已经做了 sdk 的封装。这就已经 ok 了啊…是嫌弃架构师，脱裤子放屁…多此一举。有且不可能在成熟项目里面更换日志底层。这个未来的变更可能把公司干黄了都不会有可能性。就算你封装了一层，你随便换一个试试…而且都是版本绑定，谁换 sdk 全部服务产品线自动升级啊，感觉架构师是个水货。

[oneisall8955]

slfj 本身就提供很好的扩展性，没必要，集成 starter+Lombok 自动注入直接用就好了

[jeesk]

公司内部以前分享的内容

1. 对内较真，对外果断
2. 快速犯 2 次错误并修正问题， 比陷入设计质量更能够提交设计能力。
3. 跳出争论， 先想一想自己坚持的方案和其他的方案的差异是否在实际情况中带来的真实影响到底有多大。 如果区别不搭， 先想办法让事情可以走下去，只有走下去最终产出结果，此刻争论，纠结的对错才会被赋予微不足道的意义。


再想想 go-format ， 在看看 java 和 kotlin 的各种风格。


最后我就要搬出瑞达利欧的一段：

一个决策团队，如果内部有人因为决策没有达到自己的需求而持续闹事，肯定要遭遇败绩——在公司、机构，甚至政治体系和国家，这样的例子比比皆是。我不是说人们要假装喜欢相关决策，或者不再对相关问题进行核查。我的意思是，为了提高有效性，所有集体合作的团队必须遵照规定，为分歧解决预留时间，同时，要让持不同意见的少数派明白，一旦他们的观点被推翻，整个团队的一致性要优先于个人的喜好。

团队比个人更重要，要避免破坏既定路径的行为。 换位思考很重要，决策是由公司管理层决定的， 如果你是管理层？