公司的架构师要求把日志封装成 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 扩展实现的更好，只是我没有想到，欢迎各位指点

[Bromine0x23]

评价为不如
https://www.elastic.co/guide/en/ecs-logging/java/current/index.html
和
https://spring.io/blog/2024/08/23/structured-logging-in-spring-boot-3-4

[MJTest]

线上出问题的时候动态修改 log level?

[rockdodos]

脱裤子放屁

[qdz]

好处是不用每个类定义 log 对象？没感觉有其他啥好处，新项目改就改了吧，旧项目让他自己改

[yc8332]

这个就是统一日志格式吧。。做日志搜集的时候方便，不然如果每个人写一个格式怎么解析

[lucasdev]

@unknown404 #26 如果是其他库或许可以这么说，但是 slf4j 出了 18 年了，在 mvnrepository 它是
#2 in MvnRepository
#1 in Logging Frameworks

Quartz 、Camel 、Akka 等有多少库使用了 slf4j

至于各种日志扩展，通过 Coverter 、Appender 等都可以实现，提供 sdk 引入即可，不需要侵入代码

[kneo]

非要说好处就是可以强制调用者提供一个代码。非要说必要性那肯定是没有。可能这人岁数比较大，旧项目里代理的习惯。

[daybreakfangyang]

不定规范，相当于在一坨💩山旁再拉一坨

[bk201]

日志收集不是靠入侵业务代码实现的吧。我个人觉得日志用 util 类封装，然后放入业务代码里是很垃圾的做法。一方面要大批量改 log.info 代码，另外一方面后续接受的人并不会明白这个做法，增大代码 review 复杂度以及后续接收复杂度。po 主既然讨论了，能否把架构师的理由说出来听听。单纯统一入口，便于以后扩展不是理由，slf4j 已经足够抽象化。提出一个方案，必然是解决某个痛点，而不是过度设计

[chendy]

从工作的角度，人家说啥就整啥就完事了
从经验的角度，我们也封了，但是总体来说 API 没啥变化，logger 看上去还是那个 logger 但是差了一些逻辑，直接出新 API 不是什么好文明
从自己的角度，应付过去就完事了，别耽误下班别耽误发工资就行

[Mikukko]

个人感觉目前看是为了规范，保不齐后面就变成新的屎山

[k9982874]

封装 LogUtil 很难理解吗？
封装 log 是统一格式，数据脱敏，数据清洗，大数据分析的第一步啊。
你只看你自己的业务，你们公司还有别的业务，其它语言写的平台吧，没有 slf4j 怎么办？
即使有 slf4j 开新项目每次都复制模板？模板分叉了怎么办？哪个模板是最新的？
天天制造屎山，还天天骂屎山

[SmiteChow]

你不改怎么体现他的价值，他不给你提需求怎么体现你的价值？

[securityCoding]

存粹是菜

[cloudzhou]

没什么好处，并且代码很难看，统一入口不是这么个统一法

[RandomJoke]

封装很常见，但是自己封装一个 Util 不常见，一般对日志有要求的，那么就基于 sl4j 做一个专门的 factory ，让业务无痛切换，底层实现格式化

[neocanable]

@k9982874 +1

[bk201]

@k9982874 你说的这些其他日志框架都实现了，而且性能更好，完全没必要自己造轮子。数据脱敏，数据清洗，大数据分析也不靠入侵业务代码实现，Logstash 、Fluentd 。多语言、多平台靠使用统一的日志收集平台 ELK 。LogUtil 这种入侵业务代码的非业务代码才会造成屎山，让人摸不着头脑。

[lucasdev]

@k9982874 1. slf4j 门面和 logback 等实现提供的扩展性都可以做到，楼主也说了，这些不是问题。
2. 每个语言有自己的最佳实践，别的语言或许封装一个 LogUtil 更为合适，但 Java 没必要。即使封装了 LogUtil ，也应该允许让其作为 slf4j 的实现，而不是不允许使用 slf4j 直接打印日志。此外，不同平台的日志不一定是统一管理。
3. 不存在模板复制的问题，安全、日志相关的自定义 sdk 使用 snapshot ，每次从 mvn repo 拉取最新版本。

[wangyzj]

没啥毛病
理论上一些高阶功能无法走扩展，尤其是公司内部的一些基础设施集成
对于用户来说最简单的方法集成公司现有平台是最好的改造方向
想法是好的，但得把功能点先列出来
这种东西作为基础设施一环，想不清楚就是一坨，想清楚了整个公司数据一致性都会提高

你老板如果写不出来具体 feature 可以给方向
但感觉他也不太懂