Slf4j 介绍

原文标题:Java日志通关(三) - Slf4j 介绍

原文作者:阿里云开发者

冷月清谈:

Slf4j 是一个 Java 日志框架,用于简化日志记录。它提供了一个通用的 API,允许应用程序与不同的日志实现集成,如 Logback 和 Log4j。

创建 Logger 实例
使用 Slf4j 需要创建一个 org.slf4j.Logger 实例,可以通过工厂函数 org.slf4j.LoggerFactory.getLogger() 创建。参数可以是字符串或 Class。

日志级别
Slf4j 定义了五个日志级别:TRACE、DEBUG、INFO、WARN 和 ERROR。日志实现层决定哪个等级的日志可以输出。

打印接口
Slf4j 提供了多种日志打印接口,包括 info()、debug() 和 error()。这些接口接受字符串模板和参数,用于构建日志消息。

Marker
Marker 用于标记日志消息,由日志实现层处理,可以用于过滤或格式化日志。

MDC
MDC(Mapped Diagnostic Context)是一个线程安全的存储,用于存储扩展字段,如跟踪 ID。

Fluent API
Slf4j 从 2.0.x 开始支持 Fluent API,它提供了一种流式的调用方式,可以方便地设置日志消息的各个属性。




怜星夜思:


1、Slf4j 和 Log4j 有什么区别?
2、MDC 在实际项目中的应用场景有哪些?
3、Fluent API 的优势有哪些?




原文内容



阿里妹导读


作者日常在与其他同学合作时,经常发现不合理的日志配置以及五花八门的日志记录方式,后续作者打算在团队内做一次Java日志的分享,本文是整理出的系列文章第三篇。

一、创建 Logger 实例


1.1 工厂函数

要使用Slf4j,需要先创建一个org.slf4j.Logger实例,可以使用它的工厂函数org.slf4j.LoggerFactory.getLogger(),参数可以是字符串或Class:
  • 如果是字符串,这个字符串会作为返回Logger实例的名字;

  • 如果是Class,会调用它的getName()获取Class的全路径,作为Logger实例的名字;
public class ExampleService {
// 传 Class,一般都是传当前的 Class
private static final Logger log = LoggerFactory.getLogger(ExampleService.class);
// 上边那一行相当于:
private static final Logger log = LoggerFactory.getLogger("com.example.service.ExampleService");

// 你也可以指定任意字符串
private static final Logger log = LoggerFactory.getLogger(“service”);
}

这个字符串格式的「实例名字」可以称之为LoggerName,用于在日志实现层区分如何打印日志(见下一篇【3.1 Conversion Word】节)


1.2 Lombok

无论大家对Lombok或褒或贬,但它已经是Java开发的必备依赖了,我个人是推荐使用Lombok的。
Lombok也提供了针对各种日志系统的支持,比如你只需要@lombok.extern.slf4j.Slf4j注解就可以得到一个静态的log字段,不用再手动调用工厂函数。默认的LoggerName 即是被注解的Class;同时也支持字符串格式的topic字段指定LoggerName。
@Slf4j
public class ExampleService {
// 注解 @Slf4j 会帮你生成下边这行代码
// private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(ExampleService.class);
}

@Slf4j(topic = “service”)
public class ExampleService {
// 注解 @Slf4j(topic = “service”) 会帮你自动生成下边这行代码
// private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(“service”);
}

除了Slf4j,Lombok几乎支持目前市面上所有的日志方案,从接口到实现都没放过。具体明细可以参考Lombok的官方文档@Log (and friends)[1]

二、日志级别

通过org.slf4j.event.Level我们可以看到一共有五个等级,按优先级从低到高依次为:
  • TRACE:一般用于记录调用链路,比如方法进入时打印xxx start;

  • DEBUG:个人觉得它和 trace 等级可以合并,如果一定要区分,可以用来打印方法的出入参;

  • INFO:默认级别,一般用于记录代码执行时的关键信息;

  • WARN:当代码执行遇到预期外场景,但它不影响后续执行时,可以使用;

  • ERROR:出现异常,以及代码无法兜底时使用;
多说一句,Logback额外还有两个级别ALL/OFF表示完全开启/关闭日志输出,我们记日志时并不涉及。
日志的实现层会决定哪个等级的日志可以输出,这也是我们打日志时需要区分等级的原因,在保证重要的日志不丢失的同时,仅在有需要时才打印用于Debug的日志。
上边的解释比较抽象,来个栗子🌰:
@Slf4j
public class ExampleService {
@Resource
private RpcService rpcService;

public String querySomething(String request) {
// 使用 trace 标识这个方法调用情况
log.trace(“querySomething start”);
// 使用 debug 记录出入参
log.debug(“querySomething request={}”, request);

String response = null;
try {
RpcResult rpcResult = rpcService.call(a);
if (rpcResult.isSuccess()) {
response = rpcResult.getData();

// 使用 info 标识重要节点
log.info(“querySomething rpcService.call succeed, request={}, rpcResult={}”, request, rpcResult);
} else {
// 使用 warn 标识程序调用有预期外错误,但这个错误在可控范围内
log.warn(“querySomething rpcService.call failed, request={}, rpcResult={}”, request, rpcResult);
}
} catch (Exception e) {
// 使用 error 记录程序的异常信息
log.error(“querySomething rpcService.call abnormal, request={}, exception={}”, request, e.getMessage(), e);
}

// 使用 debug 记录出入参
log.debug(“querySomething response={}”, response);
// 使用 trace 标识这个方法调用情况
log.trace(“querySomething end”);

return response;
}
}

三、打印接口

通过org.slf4j.Logger我们可以看到有非常多的日志打印接口,不过定义的格式都类似,以info为例,一共有两大类:
  • public boolean info(...);

  • public boolean isInfoEnabled(...);


3.1 info 方法

这个方法有大量的重载,不过使用逻辑是一致的,为了便于说明,我们直接上图:
可以看到,IDEA编辑器对Slf4j API的支持非常好,那些黄底的警告可以让我们马上知道这句日志记录有问题。
虽然使用字符串模板会略有性能损耗(比较[2]),但相比于它提供的可读性和便捷性,这个缺点是可以接受的。最终开发者传入的参数,会由日志实现层拼装,并根据配置输出最终结果(请参考下一篇【三、占位符】节)。


3.2 isInfoEnabled 方法

通过isInfoEnabled方法可以获取当前Logger实例是否开启了对应的日志级别,比如我们可能见过类似这样的代码:
if (log.isInfoEnabled()) {
log.info(...)
}
但其实日志实现层本身就会判断当前Logger实例的输出等级,低于此等级的日志并不会输出,所以一般并不太需要这样的判断。但如果你的输出需要额外消耗资源,那么先判断一下会比较好,比如:
if (log.isInfoEnabled()) {
// 有远程调用
String resource = rpcService.call();
log.info("resource={}", resource)

// 要解析大对象
Object result = …; // 一个大对象
log.info(“result={}”, JSON.toJSONString(result));
}

四、Marker

在前边介绍接口时,我们只提到了log.info()中填字符串模板及参数的情况,细心的朋友应该发现,还有一些接口多了一个org.slf4j.Marker类型的入参,比如:
  • log.info(Marker, ...)
我们可以通过工厂函数创建 Marker 并使用,比如:
Marker marker = MarkerFactory.getMarker("foobar");
log.info(marker, "test a={}", 1);
这个 Marker 是一个标记,它会传递给日志实现层,由实现层决定 Marker 的处理方式,比如:
  • 将Marker通过%marker打印出来;

  • 使用MarkerFilter[3]过滤出(或过滤掉)带有某个Marker的日志,比如把需要Sunfire监控的日志都过滤出来写到一个单独的日志文件;

五、MDC

MDC的全称是Mapped Diagnostic Context,直译为映射调试上下文,说人话就是用来存储扩展字段的地方,而且它是线程安全的。比如OpenTelemetry[4]的traceId就会被存到MDC中(见下一篇【五、MDC 中的 traceId】节)。
而且MDC的使用也很简单,就像是一个Map<String, String>实例,常用的方法put/get/remove/clear都有,又到了举粟子🌰时间:
// 和 Map<String, String> 相似的接口定义
MDC.put("key", "value");
String value = MDC.get("key");
MDC.remove("key");
MDC.clear();

// 获取 MDC 中的所有内容
Map<String, String> context = MDC.getCopyOfContextMap();

六、Fluent API (链式调用)

Fluent API也可以直译为「流式 API」, Slf4j从2.0.x开始支持[5],它很像Lombok中@Builder提供的能力,即通过链式调用分别设置各个属性,最后再调用.log()(就像调用.build()那样)完成整个调用。
举个例子:
Marker marker = MarkerFactory.getMarker("foobar");
Exception e = new RuntimeException();

// == 以下几个示例的最终效果是完全一致的 ==

// 这是传统的调用方式
log.info(market, “request a={}, b={}”, 1, 2, e);

// Fluent API 例1
log.atInfo() // 表示这是 INFO 级别。你猜对了,还有 atTrace/atDebug/atWarn/atError
.addMarker(marker)
.log(“request a={}, b={}”, 1, 2, e); // 与传统 API 很像

// Fluent API 例2
log.atInfo()
.addMarker(marker)
.setCause(e)
.setMessage(“request a={}, b={}”) // 传字符串模板
.setMessage(() -> “request a={}, b={}”) // setMessage 支持传入 Supplier
.addArgument(1) // 添加与字符串模板中占们符所对应的值
.addArgument(() -> 2) // addArgument 支持传入 Supplier
.log(); // 大火收汁

// == addKeyValue 的输出格式依赖日志实现层的配置,默认格式与上边示例不同 ==

// Fluent API 例3
log.atInfo()
.setMessage(“request”) // 注意这里没有占位符
.setKeyValue(“a”, 1) // 通过 setKeyValue 添加关心的变量
.setKeyValue(“b”, () -> 2) // value 支持传入 Supplier
.log();
// 通过 setKeyValue 设置的值默认会放在 message 前边,比如上边这个例子,默认会输出:
// a=1 b=2 request

总结一下:
  • 所有add前缀的方法,都支持设置多个,比如addMarker/addArgument/addKeyValue。所以在Fluent API中是支持给一条日志添加多个Marker的,而传统API不可以。
  • 所有set前缀的方法,对应的值都只有一个,比如setMessage/setCause,虽然你可以多次调用,但只有最后一次会生效。
在上边的示例中传统API看起来更简洁。但如果日志中占位符很多,那用Fluent API,特别是使用其中的addKeyValue就很有优势。
不过目前 IDEA 编辑器对流式API的支持还不太好,无法支持占位符与参数不匹配的情况:
顺便说一下,相比Slf4j,更晚推出的Log4j 2在传统API中也支持通过传入Supplier惰性求值,就像这样:
log.info("request a={}", () -> a);

七、后记

以上只是简单介绍了Slf4j的常用功能,如需进一步了解可以参考官方文档SLF4J user manual[6]
参考链接:

[1]https://projectlombok.org/features/log

[2]https://juejin.cn/post/6915015034565951501

[3]https://logback.qos.ch/apidocs/ch/qos/logback/classic/turbo/MarkerFilter.html

[4]https://www.aliyun.com/product/xtrace

[5]https://www.slf4j.org/manual.html#fluent

[6]https://www.slf4j.org/manual.htm

点击查看《

Slf4j 是一个日志门面,它提供了统一的 API 来访问不同的日志实现,而 Log4j 是一个具体的日志实现。Slf4j 依赖于 Log4j 等日志实现来实际记录日志信息。简单来说,Slf4j 就像一个适配器,它允许你使用相同的 API 来使用不同的日志系统,而 Log4j 就是一个具体的日志系统。

**可测试性:**Fluent API 中的方法通常易于测试,这有助于确保日志记录功能的正确性。

**诊断和故障排除:**MDC 可以存储与请求或事务相关的上下文信息,这有助于在发生错误时诊断和故障排除。

**性能分析:**MDC 可以存储与请求或事务相关的性能度量,允许分析系统性能和优化。

Slf4j 对线程安全有严格的要求,而 Log4j 则相对宽松。Slf4j 确保日志记录操作在多线程环境中是线程安全的,而 Log4j 则可能出现线程安全问题,特别是当使用某些特定的日志记录风格或配置时。

Slf4j 是一种更轻量级的日志框架,而 Log4j 则提供更多功能和更细粒度的控制。Slf4j 非常适合那些需要更简单和一致的日志记录体验的项目,而 Log4j 则更适合那些需要更多自定义和控制的项目。

**一致性:**Fluent API 确保日志消息按照一致的格式构建,减少了错误和不一致性的可能性。

**可扩展性:**Fluent API 易于扩展,允许添加自定义方法和功能,以满足特定的日志记录需求。

Slf4j 具备更广泛的日志记录抽象,支持更高级别的日志记录概念和模式。Log4j 虽然功能强大且广泛使用,但它的抽象级别可能较低,一些高级日志记录需求可能无法很好地满足。

Slf4j 鼓励使用“标记”来增强日志消息,而 Log4j 则支持使用过滤器来控制日志输出。标记就像额外的元数据,可以附加到日志消息上,而过滤器可以根据各种标准过滤日志消息。这两种方法都可以在日志记录过程中提供额外的灵活性。

**跟踪请求:**MDC 可以存储请求 ID 或其他标识符,允许追踪请求在系统中流动的路径。

**安全审计:**MDC 可以存储用户 ID、IP 地址和其他安全相关的上下文信息,用于安全审计和取证。

**代码简洁:**Fluent API 可以简化日志记录代码,减少样板代码,使代码更简洁易于管理。

**集成上下文:**MDC 可以存储来自多个来源或系统的信息,将它们集成到一个日志上下文,简化日志分析和故障排除。

**可读性和可维护性:**Fluent API 提供了一种更具可读性和可维护性的方式来构建日志消息。它消除了对字符串连接和格式化字符串的需要,使日志消息更易于阅读和理解。