公司的架构师要求把日志封装成 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 ，日志区分度有这么低吗

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

[RightHand]

改了就是他的 kpi：推进了 xxxlog 的自研。
你们？你们爱怎么麻烦怎么麻烦

[ddonano]

你可以重写或者扩展 slf4j 的 log.info 的啊 ，内部调用他的 LogUtil 即可

[iikebug]

架构师没活给你们找点活干，还行拉

[mohyz]

也许可以规范整个公司的日志格式，好做监控和采集上报

[unknown404]

你 leader 的 leader 说的没错，统一入口方便后面统一改造升级，比如统一的日志格式，如果日志收集处理的话这个是必要条件，直接让使用 slf4j 的结果是日志格式千千万，想统一都统一不了，问就是屎山。

[theniupa]

如果人多了不见得大家都能遵守约定

[skyrim61]

利益分析法来分析这个问题

[nealHuang]

统一入口是最好的，就跟抛异常一个道理，你可以为异常的内容设定各种规范，但是一旦出现一个 throw new RuntimeException()，你知道的，一发不可收拾 :(

[Wh1te]

没有什么好处，他封装的扩展性还能比 logback 的好？

[daya0576]

方便监控吧，根据上下文加一些标准的字段和格式，就能统一收集处理了。

[azwcl]

正常吧，不然日志采集，监控报警不好；日志格式后期还是要规范的；

[baolei666]

@RightHand 正解

[WillingXyz]

@mohyz
@unknown404
@daya0576
@azwcl 格式是规范了的，已经在 sdk 里提供了统一的 logback.xml ，现在问题是，打印日志需要封装一个 LogUtil 吗

[WillingXyz]

@daya0576 比如 logback ，可以通过 converter 机制来增加字段，只需要实现一个 converter 类，然后修改 logback.xml 即可

[devilweime]

spring 有可以配置日志格式的地方，slf4j 的 logger 可以标识是哪个类打的日志，蛮有用处的，LogUtil 感受不到太大的好处

[2han9wen71an]

日志加密、日志脱敏？

[WillingXyz]

@RightHand
@iikebug
那我写出来怎么推广出去啊，他又不推广，总是 push 我们推广，我没有充足的理由让各个业务团队这么改

[RightHand]

推广是他的事，怎么成你的任务了？

[huguohuan]

也许可以规范整个公司的日志格式，好做监控和采集上报

[tool2dx]

日志封装是很常见的操作啊，后期可以根据 code101 来做源代码级别的筛选/过滤/屏蔽。

如果维护的人经常变动，统一代码格式挺重要的。当然不离职，怎么方便怎么来。

[Fca]

他可能属于那种不接受新鲜事物的人，内心鄙夷这种框架，你自己写他学习成本也会变低

[fengpan567]

kpi 而已

[sagaxu]

没什么好处，自定义 LogUtil 能做到的功能，在 Filter, Appender 层面完全可以做到。

LogUtil.info("code101", "xxx") 跟 log.info("code101", "xxx") 并无区别。

[lucasdev]

没好处，楼上说到的日志格式、脱敏加密、监控采集等都可以通过项目中引用 sdk 来实现，不需要改代码形式。

再者说，封装的 LogUtil 的扩展性谁来保证，动来动去的更麻烦。

[WillingXyz]

@tool2dx 我们当前的日志是排查问题用的，整个 code 对我排查问题没什么帮助，现在都有分词，还有 logger name 之类的来筛选。
日志格式是统一的，比如 level ，time ，threadname ，自定义 mdc 这些

[unknown404]

@WillingXyz #13 为了以后的扩展变更还是需要的，万一出了一个比 slf4j 更好用的呢？或者需要对日志统一做一些额外处理呢？无规矩不成方圆，对于稍微大点的项目，应该全部禁止直接引用第三方包，而是需要自己包装下才可以，都是千万屎山得来的教训，等你坐到他那个位置，你可能要求比他更夸张

[luobingit]

你别说 我还真见过用 LogUtil.info 这种的

[lululau]

他是领导他说了算，建议类名叫 SBLogUtil ，要是领导问 SB 前缀是什么含义，你就说 Spring Boot 的缩写

[neocanable]

太年轻了，没有被屎山教育过

[WillingXyz]

@neocanable 屎山见多了，只是不知道 LogUtil 怎么防范屎山

[boywang004]

纯技术上讲，他对 facade 理解不够或者能力所限……但是考虑到国情和企业环境，也许你有机会能理解他的做法。

[HtPM]

他是架构师，你是程序员，你如果一下就理解了，他架构师的水分也太大了。

[CodeCodeStudy]

LogUtil.info("code101", "xxx")

这样可以快速通过 code101 来排查啊

[hafuhafu]

没任何好处，相当于进行了一次没有太大意义的封装，入侵性还大。
可能他不知道能直接扩展，基于自己的认知和经验就只是再包一层封装...

[fredweili]

小的个人开发者的类库，我会封装 API ，防止跑路
slf4j 也要这么搞，太闲了吧

[piecezzz]

纯纯浪费时间。

[flmn]

相信你们肯定用了很多开源库吧，开源库也要打日志吧。slf4j 作为门面，很多开源库也是用它打日志。
下面问题来了，这些日志怎么办？让你们的架构师给这些开源库推 PR 吧，改用你们的；
或者，想到了人家不会接受，那就把用到的开源库都 fork 一份自己维护吧，这样接下来十年的 kpi 都有了……

这个架构师真是吃饱撑的。他厉害，可以替换 logback 啊，可以指定日志规范啊，制定规范，监督规范的执行，也是 kpi 啊。

[ichou]

沟通问题不要尝试通过技术解决 [狗头]

[chawuchiren]

需要看你们这个 logUtil 是不是为了特殊日志做准备的吧，比如你们日志比较多，存储有特异性（管道到某个公司内部的采集系统，二进制压缩存储等），高吞吐量（需要单独设计缓存区），复杂的上下文打印这些功能，只能如果架构师在推广一个 sdk 的时候无法说出理由，大概率就是一个 kpi 产物了

[ghost3281]

可能是为了方便扩展？比如后续收集日志进行统计分析之类，自动收集 crash 等等

[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 可以给方向
但感觉他也不太懂

[sxms77777]

1. 以后换了日志框架，业务层不会有任何修改
2. 单元测试方便 mock
3. 模糊业务对细节的了解，防止他们使用一些不科学的 api

[sxms77777]

@sxms77777 再补充下，如何需要一些对日志框架做拓展，也无需改到业务

[jackwang123]

感觉收益不大，完全不需要这样做，大面积推广一个东西，必须有充分的理由和解决实际问题为目的。

[cccvno1]

打工混日子你和 leader 较什么真呢，他最起码知道 logutil 不会出大问题，技术选型肯定选自己熟悉的。

[bk201]

@sxms77777 你说的这些现在的日志框架不能实现吗？ slf4j 换日志框架那么方便。而且日志框架就打印字符串，有啥复杂的 api 我是没太理解

[kinkin666]

统一成一个不用动脑的样子不好吗，不然

private static final java.util.Logger LOGGER
public final static slf.Logger logger
private logback.Logger loger
private log4j.logger log

更爽吗？虽然最后都是 logback

[dxddd]

绝对有好处啊。结合调用链，有利于跨平台日志收集、分析、追踪，不过前提是，你公司的得有这些基础设施。

[fpure]

不过说实话，我还挺喜欢 LogUtil 这种静态工具类打印日志的用法，不需要在类里面专门声明一个变量，免得老是没用上然后报 unused warning

[ChefIsAwesome]

多干点活，不然天天没事，把你们裁了。这叫供给端改革，不用管消费端需不需要。

[CloveAndCurrant]

不但毫无意义，反而会增加定位难度，日志自动携带的代码，类等信息已经方便定位了，加"codexxx"这种需要人为手动填写，全靠人为约束的东西，只会增加日志定位的复杂度。

[COW]

那你就封装 slf4j ，把 code 码注入进去要求必传参数就好了呗，反正 slf4j 就是抽象出来的，你上面多抽象一层。

[lucasdev]

@bk201 #65 这个帖子挂在"程序员"节点下，而不是"Java"节点下，感觉很多回复是对 Java 生态不太了解。看了你的几条回复，我和你的观点是比较一致的😁

[meeop]

挺好的，但是如果你是业务团队，要提要求：
1 兼容目前 slf4g 所有 api ，业务侧无改动成本
2 如果因为 logUtil 导致的 bug 和故障，要架构师负责

[git00ll]

哈哈习惯就好。jsonutil ，datautil ，redisutil ，cacheutil ，stringutil ，lockutil 还少吗

[lyxxxh2]

你用其他方法打印日志,不就是找喷。

[lyxxxh2]

扩展也可以理解。
后面可能考虑,丢 es 其他产品的日志呢,或者更加自定义的操作。

[lucasdev]

楼主可以问问 AI ，我把问题直接丢给了 gemini 2.0, claude 3.5 sonnet, gpt-4o ，似乎都更推荐 SLF4J + Logback

[ZeroDu]

很多人可能不了解 java 生态下的 SLF4J ，什么动态日志级别，源码级别的日志过滤，这些都是自带的。相比其他语言来说真的是很完善了。

[zhady009]

@git00ll 完全不能理解这种行为，库都提供好了非得自己再包一层然后弄成 static ，然后 util 对外暴露的 api 还更少了想用的时候又自己加一个方法。

[ldyisbest]

职业生涯最重要的一课是，你需要认识到，你工作的目的不在于使得公司的客户满意，而在于使得那些控制你的加薪、奖金和晋升的人满意。

[CloveAndCurrant]

@meeop 你想多了，出了事架构师不可能负责的，logUtil 又不是架构师开发的，是架构师让你开发的，“不是我领导无方，而是你能力不行”。

[dcsuibian]

假设确定了要写，那么大概有两种方案。

一、第一种方案，就是 LogUtil 内部调用其他日志框架来打日志。

1.1 、这就引入一个致命问题，就是类信息怎么传过来？你看哦，日志框架其实是需要在类里生成一个`private static final Logger log = LoggerFactory.getLogger(所在类.class);`所以打印的时候，才能打印出是哪个类的问题，但此时你是 LogUtil 来打印，那么所有的日志都会变成 LogUtil 的日志。怎么解决这个问题？

1.2 、第二个问题，如果我没封装，那日志框架出了问题（比如上次的 log4j2 漏洞），就是日志框架的问题。但如果我封装了 LogUtil ，那此时就是写 LogUtil 的人的问题。因为是你选择了内部要调用其它日志框架。

二、第二种方案，就是不调用其他日志框架。哦我的上帝啊，那样就会引入更多问题。

你得写自己的 Logger 、LoggerFactory 、 设计自己的 logback.xml 等等，最终还就是自己做了一个日志框架。

还有最终的致命问题，你程序里写的日志可以改成调用 LogUtil 的，那调用的第三方 jar 包里写的日志你怎么控制？



把这些问题抛给你 leader 的 leader ，让他解决

[YiXinCoding]

这波架构师在大气层啊，这样大家都有活干，有绩效，对项目影响又不大。
防御性编程，如果再加上不写文档，Code 自己拿小本本记着，那是绝杀。
换别人排查日志定位不到问题，自己一看就能定位，建立壁垒，避免了被取代裁员。
（透过现象看本质，到了这个级别，追求的不是什么扩展性和实用性了，而是利益了）

[xiangbohua]

我觉得还是有好处的，只是是什么阶段什么时候做合不合适的问题。
也不要觉得做这个事情的目的想的那么功利，本来加薪就是要做事情。（前提是别搞幺蛾子比如大家明明忙不过来还要搞这种事情）
是真的有些人是想在代码上面有写追求的，哪怕公司没有加薪计划。
所以遇到这种事情，你不明白的话就问问他这么做的目的，让他给你解释解释，相当于请教一下（也可以学学领导的思维方式，也有好处），如果他跟你解释了你还是不能理解，那就问问他应该怎么实现，然后按照他的想法去实现就行，退一万步讲，写代码的写什么代码不是写？
我主要还是说这件事情本身，如果做这个事情的过程比较恶心，那我觉得是另外一个范畴的问题了。

[zjiajun]

站在顶层看，封装是没任何问题的，但也不一定是要封装的，封装后的优点如下：

- 统一日志框架版本。举例，log4j 漏洞升级版本，那就不用每个项目都修改一遍了

- 统一定义日志格式，方便搜集/格式化/分析/告警/数据看板等等

- 并不是所有人都知道 slf4j 是门面，有的应用日志框架实现是 log4j2 、有的是 logback ，当然统一最好啦

- 增强 code 我理解为，提升可维护性

[ffyyhh]

现在你们有做日志采集吗，比如采集槽 ELK ，如何有的话，统一日志是有必要的

[liberize]

新项目可以理解，改现有的没有必要

[MoYi123]

个人经验, 工作中看到 “封装” 这个 2 个字就没好事.

[zizon]

你的 slf4j 方案有办法让人不带上 code101 就编译不了么?

[nl101531]

统一是好的，遇到过匿名化诉求，这个时候统一好处就来了

[leconio]

新需求，把所有 info 日志加埋点。or 这个日志性能太差了，灰度换其他的。评估下工作量

[highkay]

讲不清楚真正的具有说服力的优点的基本上说明没啥水平。统一日志（用来做分析）和你用的 log 封装根本没有直接关系，那主要是数据质量问题。

[Mandelo]

搞清楚自己的定位,就是个干活的

[xuanbg]

我司不规定日志实现，只规定日志格式，还必须是结构化的日志，不允许平铺直叙打日志

[iyaozhen]

LogUtil.info ，我倒没啥意见，我们公司几千个研发，也是这么干的。当然我们是 Go ，没有 slf4j 这类事实上标准规范。但其实不关心 LogUtil 底层是咋实现的，只是打个日志，你可以在你自己的框架里面包一下（用起来还是 log.info ）
好处前面很多人也提过了，日志脱敏、存储的统一性。虽然有点搓，但也无伤大雅。
不过肯定有性能的要求，开发 LogUtil 的团队需要给出性能报告，以及承担相关责任（比如日志库 panic 了，平台上查不到日志了）

我倒是反对加上 code101 ，这种纯沙币的行为，完全不可控，很容易就重复了，还不如直接记录文件名+行

[KIDJourney]

已经有 TCP 了，为什么大家不用 TCP 实现一切，还要在他上面发明个 HTTP ？明明什么问题都没解决

[clf]

不是很好……统一的话直接在框架里下毒就行。我们就是这么干的。提供统一的 logback.xml ，然后各个实现类里自己引入 org.slf4j.Logger

反倒是有副作用？不知道怎么封装的，一般现在日志前面会有一个缩略的日志打印的类的类名。不知道他封装后是不是丢了。。。

[clf]

如果不是通过框架全局做单纯用 Util 封装的话，封装后还会有几个问题：
1. IDE 的括号和变量个数是否匹配的检查不会生效了。
2. 其他第三方库并不会按照你们的规范来……

[woodfizky]

统一入口没毛病，日志 code 最好有个可扩展的枚举类之类的东西去约束。

你是不知道没统一日志工具类的情况，对本来各自为战的各个开发负责的各个不同风格的项目，统一做日志整改有多困难。

统一的好处就是好管理，日志工具也可以集成类似响应时间或者特定事件的监控，哪天公司要求对某些事件做监控报警了，限期做改造，然后你发现项目张三两个李四三个，却没用到统一的日志工具，整改起来你就头疼去吧。


有些日志侵入业务是因为一开始对日志没要求，或者说一开始业务没考虑日志和监控的需求，但是不代表这需求不合理。

[yor1g]

人家重点是那个 code 🤣 你解决不了那个 code 就无法说服他