Logback实现按业务输出到对应日志文件

背景

　　最近负责的项目，需要新对接一个第三方api，在对接编码过程中肯定少不了日志的输出，避免上了生产环境出问题排查困难， 由于这个项目已经在线上运作了有2-3年了，各种业务、非业务、框架等日志都集中在一个文件，查看了下生产环境的最近几天日志文件，发现一天的日志接近2个G，如果需要精确去查看新对接的第三方api业务日志，无异于大海捞针。因此希望可以把这些和第三方对接的日志生成在另外一个单独的文件。这也就是标题中的实现按业务输出日志到不同的文件，下面开始讲解具体的实现方案。

一、方案

    由于需要按业务生成不同的日志文件，看到按业务来区分，我的第一感觉就是业务其实是可以按包名来区分的。所以其实我们只要实现不同的包下面的日志输出到不同的文件，就能实现需求了。由于本人以前玩过log4j2，要实现这个还是不难的，所以马上就有思路了。

具体的实现思路如下：

    （1）自定义一个输出到文件的appender（理解为日志输出器）

    （2）配置logger，logger的name为需要单独生成文件的那个包的全包名，然后在里面引用上面定义的appender

二、具体实现

（1）准备阶段

    由于项目采用SpringBoot框架，而且使用的是默认日志框架logback。看了下官网，只需要在resources下面定义一个logback-spring.xml的XML文件就能覆盖默认的logback配置。

    由于SpringBoot默认的日志配置还是挺不错的，因此想把默认的配置保留下来。通过查看springboot的jar包才找到默认的logback的xml配置。

它的位置为spring-boot-2.1.0.RELEASE.jar!\org\springframework\boot\logging\logback\base.xml，这个默认xml中有如下配置：

 

 定义了2个appender，分别为输出到控制台的appender和输出到文件的appender

 <appender name="ztripLogAppender"
            class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${LOG_DIR}/ztrip.log</file>
    <rollingPolicy
            class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <fileNamePattern>${LOG_DIR}/ztrip.%d{yyyy-MM-dd}.log.bak
      </fileNamePattern>
    </rollingPolicy>
    <encoder>
      <pattern>${COMMON_LOG_PATTERN}</pattern>
    </encoder>
  </appender>

 

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>
        <!--[%d{yyyy-MM-dd HH:mm:ss.SSS}] [%t] %-5level %logger{50} - %msg%n-->
        ${COMMON_LOG_PATTERN}
      </pattern>
      <charset>UTF-8</charset>
    </encoder>
  </appender>

 默认日志级别为info，默认引用了上面定义的这个2个appender

<logger name="ztripLog" additivity="false" level="INFO">
    <appender-ref ref="ztripLogAppender"/>
    <appender-ref ref="CONSOLE"/>
  </logger>

 

（2）代码引用（2种方式）

1.通过lombok提供的注解，指定上面配置好的logger name

@Slf4j(topic = "ztripLog")

2.通过LoggerFactory去创建

private final static Logger ztripLogger = LoggerFactory.getLogger(ZtripConstants.ZTRIP_LOG_NAME);

 

（3）效果如下

 

三、最后

    （1）需要考虑到你的线上代码已经运行了一段时间，那么改动日志尽量不要去动原来的，最好新增一个配置；因为你不清楚之前的开发到底是不是还有其他逻辑在上面，盲目的改动有风险

    （2）通过不同业务的日志分离，既能解耦也能加快排查问题的速度，避免在大日志文件海选

 

感谢下面的文章给的思路，参考链接：

https://www.cnblogs.com/zeng1994/p/f9bff238b13a0bf8fb8bf88c41db7a34.html