老项目中日志使用混乱,某些项目使用log4j,某些项目使用logback,统一是必须的。既然Spring Boot已经将logback做为默认集成的日志框架,全面了解学习是必然了。

曾经log4j是流行的日志框架,现在已被它的继任者logback替代,logback更快,更小,更灵活。当然,如果你的项目中还在用System.out.println()来输出内容,那更是得行动起来,要么“逃”吧,要么改造吧。

logback简介

先来看看logback何许人也,最直接的就是看看它的官网http://logback.qos.ch

logback

官网首页直言不讳的说它将是log4j的继承者,所以,如果还没用到或如果还不会使用,赶紧行动起来吧。

logback主要由三个模块构成:logback-core,logback-classic及logback-access。

logback

logback-core为基础核心,另外两个均依赖它。其中logback-classic实现了简单日志门面SLF4J;logback-access主要作为一个与Servlet容器交互的模块,提供与HTTP访问相关的一些功能。

通常使用时直接引入logback-classic的依赖,便可自动引入logback-core,当然为保险起见也可以显式的引入两者。

SpringBoot对logback的支持

上面已经提到SpringBoot默认集成了logback,因此无需专门引入便可进行直接使用。后面的示例我们也基于SpringBoot来进行演示和讲解,毕竟方便嘛。

logback

在SpringBoot的web项目中logback的依赖关系如下:

我们可以看到一旦引入spring-boot-starter-web依赖,对应的不仅引入了logback框架,还同时引入了slf4j相关框架。所以,项目中直接使用即可。

SpringBoot的集成

首先创建一个SpringBoot项目,核心依赖文件便是spring-boot-starter-web。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

如此便集成完成,其实嘛,等于根本不用集成。我们在项目中创建一个Controller类,其中打印不同级别的日志信息。

@RestController
public class HelloWorldController {

    private static final Logger log = LoggerFactory.getLogger(HelloWorldController.class);

    @RequestMapping("/hello")
    public void hello() {
        log.debug("Hello world 测试debug日志");
        log.info("Hello world 测试info日志");
        log.warn("Hello world 测试warn日志");
        log.error("Hello world 测试error日志");
    }
}

上面代码中分别使用debug,info,warn,error方法输出日志。日志的所有配置,都是基于SpringBoot集成logback时的默认配置来的。

此时如果访问对应的url,便可打印出对应日志。

2020-10-18 21:22:59.800  INFO 45952 --- [nio-8080-exec-2] c.s.controller.HelloWorldController      : Hello world 测试info日志
2020-10-18 21:22:59.800  WARN 45952 --- [nio-8080-exec-2] c.s.controller.HelloWorldController      : Hello world 测试warn日志
2020-10-18 21:22:59.800 ERROR 45952 --- [nio-8080-exec-2] c.s.controller.HelloWorldController      : Hello world 测试error日志

为什么只打印了三行?因为SpringBoot默认日志输出级别为info级别。在application.properties文件中添加如下配置便可打印出debug级别的日志。

logging.level.com.secbro2=debug

其中com.secbro2为项目的基础package路径。更多配置使用下节专门进行讲解。

SpringBoot对logback的基础配置

SpringBoot对logback内置了一些默认配置,这与SpringBoot集成其他框架异曲同工。默认情况下SpringBoot将日志输出到控制台,不会写到日志文件。如果输出到日志文件,则需在application.properties中设置logging.file或logging.path属性。

# 注:二者不能同时使用。否则只有logging.file生效
logging.file=文件名
logging.path=日志文件路径

logging.level.包名=指定包下的日志级别
logging.pattern.console=日志打印规则

logging.file设置日志文件,可以是绝对路径或相对路径。如:logging.file=my.log。

logging.path设置日志目录,会在指定目录下创建spring.log文件,并写入日志内容,如:logging.path=/var/log。

二者不能同时使用,否则只有logging.file生效。

我们使用一下IDEA的提示功能可以看到,基于SpringBoot的默认配置还有以下选项。

logback

关于日志级别的配置,在上面已经有具体的示例了。设置格式为logging.leve.* =LEVEL,其中*为包名或logger名,LEVEL有:TRACE,DEBUG,INFO,WARN,ERROR,FATAL,OFF。

其他的就是日志文件的大小(默认10MB)、格式,以及控制台和日志文件内日志的格式配置了。根据提示我们可以很轻易搞定。

但是,你可能也发现了在application.properties中支持的配置有些简单。对的,如果需要配置复杂的日志内容,则需要基于xml配置文件来进行操作。

自定义logback配置

在application.properties中配置日志,通常在小型系统或对日志没有严格要求的系统中使用。如果运用在生产环境,通常建议通过基于xml文件来对logback进行自定义配置。

logback

在SpringBoot中,默认支持四种命名的日志文件。

也就是说如果在src/main/resources目录下放置其中任一类型的配置文件,SpringBoot便会自动进行使用。

而Spring Boot官方推荐优先使用带有-spring的文件名配置(如有logback-spring.xml,则不会使用logback.xml)。

若需要对配置文件名进行修改,或者希望把放到其它目录下,可以在application中通过logging.config属性来指定,如logging.config=classpath:config/my-log-config.xml。

logback-spring.xml详解

对于xml日志文件的配置,大多数人第一次接触时有一种望而生畏的感觉,其实如果仔细分析,会发现核心的部分只有三个元素:appender、logger、root。

logback

通过上图我们可以清理的了解整个xml文件的元素及功能。

其中configuration是根元素,必须的;logger和root可视为同一类,都是日志组件;logger定义日志从哪里(包)获取以及级别;appender配置日志格式、如何过滤、文件处理等。property和contextName元素,分别用来定义变量和应用上下文名称,非必须。

先通过一个简单的日志模板,从视觉上感受一下:

<configuration>
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
    </encoder>
  </appender>
  <logger name="chapters.configuration" level="INFO"/>
  <root level="DEBUG">          
    <appender-ref ref="STDOUT" />
  </root>  
</configuration>

上述实例定义了控制台输出debug级别日志的配置。下面对相关的元素进行逐一讲解。

configuration元素

logback.xml配置文件的基本结构可以描述为configuration元素,包含零个或多个appender元素,后跟零个或多个logger元素,后跟最多一个root元素(也可以没有)。

根元素configuration有三个属性:

  • debug:默认为false,若设置为true,则打印出logback内部日志信息。
  • scan:默认值为true,若设置为true,配置文件如果发生改变,将会被重新加载。
  • scanPeriod:与scan配合使用,当scan为true时,此属性生效,默认的时间间隔为1分钟,设置监测配置文件是否有修改的时间间隔,如果没有给出时间单位,默认单位是毫秒。如可以设置为scanPeriod=”30 seconds”每30秒检测一次。

定义上下文名称

contextName元素,每一个日志组件(logger)都会关联到日志上下文,默认上下文名称是’default’,用于标识应用,如果多个应用输出到同一个地方,就有必要使用%contextName来区别。

上线文的配置直接在configuration元素下:

<configuration>
    <contextName>HelloWorld-log</contextName>
</configuration>

经过定义之后,在其他property属性或appender中便可通过“%contextName”来获取和使用该上下文名称了。

定义变量

通过property元素可定义变量。它有name和value两个属性。变量可以使“${name}”来使用变量。作用类似于代码中的常量字符串,定义之后公共地方便可以统一使用。如日志文件名称前缀、日志路径、日志输出格式等。

<configuration>
    <property name="log.path" value="./log" />
</configuration>

上面便是定义了日志的根路径的变量。

如果是在Spring或SpringBoot项目当中,想让value值是通过配置文件获取,可使用springProperty来定义。

<springProperty scope="context" name="log.path" source="catalina.base"/>

其中source指定的catalina.base便是在application.properties当中配置变量。此配置还是比较常用的,可以做到灵活区分环境。

appender组件

appender组件用来定义日志输出格式,日志如何过滤以及日志文件的处理。appender的结构如下:

logback

appender的属性有name和class。name指定appender名称,后面使用该appender是也是通过名称来指定。

class属性指定要实例化的appender类的完全限定名称。appender类默认有以下几种:

  • ConsoleAppender:日志输出到控制台,类名ch.qos.logback.core.ConsoleAppender。
  • FileAppender:日志输入到文件,类名ch.qos.logback.core.FileAppender。
  • RollingFileAppender:滚动记录文件,FileAppender的子类,当符合条件(大小、时间),日志进行切分处理。类名:ch.qos.logback.core.rolling.RollingFileAppender。

appender元素可以包含零个或一个layout元素,零个或多个encoder元素以及零个或多个filter元素。

实战中ConsoleAppender及RollingFileAppender使用较多,若需要自定义如把日志输出到消息队列,可以自定义实现AppenderBase接口。

ConsoleAppender上面已经有示例,主要作用就是将日志输出到控制台,并通过pattern元素指定了输出的格式。下面重点看一下RollingFileAppender的配置。

RollingFileAppender配置

RollingFileAppender是FileAppender的子类,扩展了FileAppender,具有翻转日志文件的功能。

例如,RollingFileAppender可以记录到名为log.txt文件的文件,并且一旦满足某个条件,就将其日志记录目标更改为另一个文件。

RollingFileAppender通常包括File、filter,rollingPolicy,encoder和layout元素。

encoder用来指定日志的输出格式及编码等:

<!-- 文件输出日志格式 -->
<property name="FILE_LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} %contextName [%thread] %-5level %logger{36} - %msg%n" />

<appender>
    <!--日志文件输出格式-->
    <encoder>
        <pattern>${FILE_LOG_PATTERN}</pattern>
        <charset class="java.nio.charset.Charset">UTF-8</charset>
    </encoder>
</appender>

file元素用来配置日志的路径和名称,一般把路径和文件名前缀定义到变量(property中)。

<encoder>
    <!-- 正在记录的日志文件的路径及文件名 -->
    <file>${log.path}/log_error.log</file>
</appender>

${log.path}获取的便是前面属性中定义的变量。

appender中可以有多个filter元素,比如用ThresholdFilter来过滤低于指定临界值的日志;用LevelFilter来过滤日志级别。以LevelFilter为例:

<!-- 过滤器,只记录debug级别的日志 -->
<filter class="ch.qos.logback.classic.filter.LevelFilter">
    <level>DEBUG</level>
    <OnMismatch>DENY</OnMismatch>
    <OnMatch>ACCEPT</OnMatch>
</filter>

其中level指定日志级别,onMath指定符合过滤条件的操作接收(ACCEPT),onMismatch指定不符合条件的拒绝(DENY)。

如果需要将不同级别的日志输出到不同的日志文件,那么就需要配置多个filter,每个filter像上面一样指定level级别:DEBUG,INFO,WARN和ERROR。

通常情况下,日志输出会配置三个,一个控制台输出用于开发阶段;一个INFO及以上级别的日志输出,可追踪相应的生产日志;一个单独ERROR级别的日志输出,方便快速检查出异常日志。

rollingPolicy用于配置滚动策略,支持TimeBasedRollingPolicy、SizeAndTimeBasedRollingPolicy、FixedWindowRollingPolicy、SizeBasedTriggeringPolicy。

分别是基于时间滚动、基于大小和时间滚动、固定窗口滚动和大小触发。其中FixedWindowRollingPolicy一般和SizeBasedTriggeringPolicy同时使用。下面以TimeBasedRollingPolicy为例,以天为单位输出日志,每天一个日志。

<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    <!-- 日志输出格式 -->
    <fileNamePattern>${log.path}/debug.%d{yyyy-MM-dd}.log</fileNamePattern>
    <!-- 日志保留天数 -->
    <maxHistory>30</maxHistory>
</rollingPolicy>

fileNamePattern指定日志的路径及名称,此处是按日期输出,即%d{yyyy-MM-dd}格式。maxHistory表示日志最多保留天数,存活超过30天的日志会被删除。

logger配置

logger用来设置某一个类或者某个包的日志输出级别、以及关联的appender。

logger包含三个属性:

  • name:要输出日志的包名或者类名,比如com.secbro2。必选项。
  • level:设置日志级别,允许一个不区分大小写的字符串值TRACE,DEBUG,INFO,WARN,ERROR,ALL或OFF。如果未设置,则logger会向上继承最近一个非空级别。可选项。
  • additivity:是否将日志向上级传递,默认为 true。可选项。

logger通过1个或多个子节点appender-ref来控制日志的输出。

<logger name="org.springframework" level="WARN"/>
<logger name="com" level="debug" />

上面示例表示org.springframework包下的日志以warn级别输出,com包下的日志以debug级别输出。

<logger name="com.secbro2" level="info" additivity="true">
    <appender-ref ref="CONSOLE" />
</logger>

上面的示例对指定包指定appender进行日志控制,由于设置了info级别,additivity为true,而且关联CONSOLE的appender,因此info以上级别的日志会输出到控制台。

同时会把日志上传到父级,即root。若root也有配置CONSOLE的输出的话,会在控制台输出两次。additivity为false,则不会。

root配置

root元素配置根记录器。它是一个特殊的logger,是所有logger的根节点,只有一个属性level,默认为DEBUG 。

<root level="info">
    <appender-ref ref="CONSOLE" />
    <appender-ref ref="LOGSTASH" />
    <appender-ref ref="INFO_FILE" />
    <appender-ref ref="ERROR_FILE" />
</root>

level属性的值可以是不区分大小写的字符串TRACE,DEBUG,INFO,WARN,ERROR,ALL或OFF之一。root元素可以包含零个或多个appender-ref元素;被引用的每个appender都被添加到根记录器中。

如果是基于SpringBoot项目,针对不同环境(profile)有不同的日志输出,比如开发(dev)环境只输出CONSOLE的,生产环境(prod)只输入info和error,那则可用到Spring支持的profile机制。对应的元素为springProfile。

profile的值与springboot中配置文件的spring.profiles.active值进行对照。

<!-- 开发环境 -->
<springProfile name="dev">
    <logger name="com" level="debug" />
    <root level="info">
        <appender-ref ref="CONSOLE" />
    </root>
</springProfile>
<!-- 测试环境+生产环境 -->
<springProfile name="test,prod">
    <logger name="com" level="info" />
    <root level="info">
        <appender-ref ref="INFO_FILE" />
        <appender-ref ref="ERROR_FILE" />
    </root>
</springProfile>

当引入了springProfile,我们可以看到root元素可以出现多次了,但还是保证了一个环境只有一个root元素的要求。springProfile的name对应spring.profiles.active的值,多个值用逗号分隔。

ELK的配置

如果项目中的日志采用的是基于ELK(Elasticsearch,Logstash,Kibana三个开源软件的缩写)来进行日志管理。则可以在pom文件中引入logstash-logback-encoder依赖。

<dependency>
    <groupId>net.logstash.logback</groupId>
    <artifactId>logstash-logback-encoder</artifactId>
    <version>5.1</version>
</dependency>

然后在logback-spring.xml中配置对应的appender:

<appender name="LOGSTASH" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
        <level>debug</level>
    </filter>
    <destination>192.168.0.11:5061</destination>
    <encoder charset="UTF-8" class="net.logstash.logback.encoder.LogstashEncoder">
        <customFields>{"project": "springboot-logback-elk"}</customFields>
    </encoder>
</appender>

该appender的使用与其他appender的使用无异。主要使用了LogstashTcpSocketAppender类来完成与Logstash的通信。其中destination为Logstash提供的服务地址。customFields为自定义的参数,便于Logstash识别日志是从哪个业务系统传输过来的。

输出logback状态数据

某些时候为了了解logback配置文件加载情况,配置中对应的appender、logger的装载情况等,我们需要启用logback状态数据的输出。这也是logback官网强烈推荐的,可以帮助我们排除诊断一些问题。

启用状态数据输出有两种方式:

  • 在根元素(configuration) 中设置属性debug=”true”。
  • 添加元素(statusListener),class使用OnConsoleStatusListener。如下:
<!-- 输出logback的本身状态数据 -->
<statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />

两种方式选其一即可。第一种方式的debug与配置文件中的日志级别没有关系,只用于表示输出状态数据。

logback

当采用第一种方式时,访问最开始的实例打印日志如下:

通过日志可以看出打印了日志输出的文件及相关TimeBasedArchiveRemover的操作信息。

异步输出日志

前面讲到的appender,日志输出到文件是同步输出的,即每次输出都会直接写IO到磁盘文件。对于高并发的应用,会产生一定的阻塞,造成不必要的性能损耗。

logback提供了日志异步输出的AsyncAppender。处理方式也很简单,添加一个基于异步写日志的appender,并指向原配置的appender即可:

<!-- 异步输出 -->
<appender name="ASYNCDEBUG" class="ch.qos.logback.classic.AsyncAppender">
    <!-- 默认如果队列的80%已满,则会丢弃TRACT、DEBUG、INFO级别的日志,若要保留全部日志,设置为0 -->
    <discardingThreshold>0</discardingThreshold>
    <!-- 更改默认的队列的深度,该值会影响性能.默认值为256 -->
    <queueSize>1024</queueSize>
    <!-- 添加附加的appender,最多只能添加一个 -->
    <appender-ref ref="DEBUGFILE"/>
    <includeCallerData>true</includeCallerData>
</appender>
// INFO结构同上
<!-- 异步输出关联到root -->
<root level="DEBUG">
    <appender-ref ref="STDOUT"/>
    <appender-ref ref="ASYNCDEBUG" />
    //...
</root>

AsyncAppender的实现原理是通过阻塞队列(BlockingQueue)来避免日志直接输出到文件,先把日志事件输出到BlockingQueue中,然后启动一个新的worker线程,主线程不阻塞,worker线程则从队列中获取需要写的日志,异步输出到对应的位置。

MDC分布式应用追踪请求

上面所讲的日志都是在单个应用系统下记录日志的。一旦进入分布式系统,很可能就会出现日志错乱,对日志追踪和排查造成难题。如果使用像ELK这类框架将日志进行归集统一处理,也需要一个标识,来记录日志的整个请求处理过程。

logback提供了MDC(Mapped Diagnostic Contexts诊断上下文映射),可以让开发人员在诊断上下文中放置信息。通过ThreadLocal实现了线程与线程之间的数据隔离。在输出时可以通过标识符%X{key}来输出MDC中设置的内容。

分布式应用追踪请求实现思路如下:

logback

下面来看一下具体的实现代码。首先定义个简单工具来生成一个唯一的请求标识,这里采用UUID作为标识。

public class IdUtil {
    public static String simpleUuid() {
        return UUID.randomUUID().toString().replaceAll("-", "");
    }
}

然后通过实现接口HandlerInterceptor来自定义一个拦截器。

@Component
public class RequestIdTraceInterceptor implements HandlerInterceptor {

    private static final String REQUEST_ID_KEY = "request-id";

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response,
                             Object handler) {
        MDC.put(REQUEST_ID_KEY, getRequestId(request));
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response,
                                Object handler, Exception ex) {
        // 把requestId添加到响应头,以便其它应用使用
        response.addHeader(REQUEST_ID_KEY, MDC.get(REQUEST_ID_KEY));
        // 请求完成,从MDC中移除requestId
        MDC.remove(REQUEST_ID_KEY);
    }

    public static String getRequestId(HttpServletRequest request) {
        String paramRequestId = request.getParameter(REQUEST_ID_KEY);
        String headerRequestId = request.getHeader(REQUEST_ID_KEY);
        // 根据请求参数或请求头判断是否有“request-id”,有则使用,无则创建
        String requestId;
        if (paramRequestId == null && headerRequestId == null) {
            requestId = IdUtil.simpleUuid();
        } else {
            requestId = paramRequestId != null ? paramRequestId : headerRequestId;
        }
        return requestId;
    }
}

代码的思路与上面的图一致,实现接口的preHandle方法用于请求前的处理,调用getRequestId方法从参数和header中获取对应的值,如果都没有获取到,则生成一个新的。否则,取两者中不为空的那个值。

实现接口的afterCompletion方法做了两件事:第一,相应其他系统时返回request-id的值,以便其他系统继续保持同一因为的连续性;第二,清除自身系统中存储的值。

上面只是实例化了自定义的拦截器,并没有对拦截器进行注册使用。在SpringBoot项目中可在实现接口WebMvcConfigurer的addInterceptors方法时,将实例化的拦截件进行添加。

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Resource
    private RequestIdTraceInterceptor requestIdTraceInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        // 添加拦截器
        registry.addInterceptor(requestIdTraceInterceptor);
    }
}

这里通过@Resource将RequestIdTraceInterceptor注入,然后通过InterceptorRegistry的addInterceptor方法将其注册。

此时,理论上访问URL请求的过程中已经添加了request-id。但上面我们提到,还需要通过%X{key}才能在logback中获取和输出。

那么就在logback中定义输出格式时在适当的位置进行添加。

<property name="CONSOLE_LOG_PATTERN"
  value="${CONSOLE_LOG_PATTERN:-%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) [%X{request-id}] %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}}"/>

上面的是基于控制台的输出表达式,比较复杂。大家注意看“[%X{request-id}]”部分便是用来输出request-id的值的。

现在启动程序,会发现并没有打印出request-id的值:

2020-10-19 22:02:10.200  INFO [] 76397 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2020-10-19 22:02:10.204  INFO [] 76397 --- [           main] com.secbro2.ElkApplication               : Started ElkApplication in 2.02 seconds (JVM running for 2.715)
2020-10-19 22:02:24.052  INFO [] 76397 --- [nio-8080-exec-1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring DispatcherServlet 'dispatcherServlet'
2020-10-19 22:02:24.053  INFO [] 76397 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2020-10-19 22:02:24.060  INFO [] 76397 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 7 ms
2020-10-19 22:02:24.078 DEBUG [] 76397 --- [nio-8080-exec-1] c.s.i.RequestIdTraceInterceptor          : no request-id in request parameter or header

只是打印了一个空的中括号,这是因为还没有Http请求,当然就没创建对应的request-id。下面请求一下最初实例的URl,日志打印格式如下:

2020-10-19 22:02:24.085 DEBUG [0097978409374988b7fcaf2debb1a125] 76397 --- [nio-8080-exec-1] c.s.controller.HelloWorldController      : Hello world 测试debug日志
2020-10-19 22:02:24.085  INFO [0097978409374988b7fcaf2debb1a125] 76397 --- [nio-8080-exec-1] c.s.controller.HelloWorldController      : Hello world 测试info日志
2020-10-19 22:02:24.085  WARN [0097978409374988b7fcaf2debb1a125] 76397 --- [nio-8080-exec-1] c.s.controller.HelloWorldController      : Hello world 测试warn日志
2020-10-19 22:02:24.085 ERROR [0097978409374988b7fcaf2debb1a125] 76397 --- [nio-8080-exec-1] c.s.controller.HelloWorldController      : Hello world 测试error日志

request-id完美打印出来了。读者可以尝试两个系统之间的交互操作,这里就不再用实例演示了。

代码中的日志格式

在日常使用日志时,可以通过最开始的示例定义Logger对象,然后调用其对应级别的日志输出。当然,如果采用Lombok的情况下,可直接类上使用@Slf4j注解来自动注入log属性,不用再声明:

private static final Logger log = LoggerFactory.getLogger(HelloWorldController.class);

替换为:

@Slf4j
@RestController
public class HelloWorldController {
}

其他内容不变。

而在日志输出格式也有多种,其中最不可取的形式是如下模式的日志输出:

Object entry = new SomeObject(); 
logger.debug("The entry is " + entry);

这种模式会导致即使采用info基本输出,debug中的对象toString和字符串拼装依旧会处理。建议采用如下模式输出:

Object entry = new SomeObject(); 
logger.debug("The entry is {}.", entry);

此时,如果日志输出级别为info,则不会处理对象的toString和字符串的拼接。

logback作者进行测试得出:第一种和第二种写法输出结果相同。但在禁用日志记录语句的情况下,第二种将比第一种写法优于至少30倍。

小结

到此,关于logback日志框架的讲解告一段落,如果你还想了解更多底层原理和一些表达式,建议看一下官方的手册,虽然是英文的,但还是比较全面的。

本文用巨大篇幅,描述了logback日志常见的使用场景,想必读到此处时,原来在那复杂的日志配置文件已经变得十分简单吧。赶快尝试一下吧。用了两天写完这篇文章,多多支持,你懂得该怎么做的。



万字详解logback日志框架,再没这么全的了!插图9

关注公众号:程序新视界,一个让你软实力、硬技术同步提升的平台

除非注明,否则均为程序新视界原创文章,转载必须以链接形式标明本文链接

本文链接:http://www.choupangxia.com/2020/10/21/springboot-logback/