logback-使用${spring.application.name}日志打印路径问题

万物~

1206人浏览 · 2023-01-31 13:23:51

万物~ · 2023-01-31 13:23:51 发布

项目场景：

前提：系统使用的logback打印日志，日志文件在服务器目录为/data/service/logs目录下，分别有debug.log,info.log和error.log三个

问题描述

今天发现服务器上debug.log,info.log日志停止了，没有后续日志，时间点为下午四点17，发现这个时间点为最近一次升级的时间，初步判断是因为升级导致

logback-spring.xml

<?xml version="1.0" encoding="UTF-8"?>
<configuration debug="false" scan="false">
    <springProperty scop="context" name="spring.application.name" source="spring.application.name" defaultValue=""/>
    <springProperty scop="context" name="server.port" source="server.port" defaultValue=""/>
    <property name="log.path" value="logs/${spring.application.name}"/>
    <!-- 彩色日志依赖的渲染类 -->
    <conversionRule conversionWord="clr" converterClass="org.springframework.boot.logging.logback.ColorConverter"/>
    <conversionRule conversionWord="wex"
                    converterClass="org.springframework.boot.logging.logback.WhitespaceThrowableProxyConverter"/>
    <conversionRule conversionWord="wEx"
                    converterClass="org.springframework.boot.logging.logback.ExtendedWhitespaceThrowableProxyConverter"/>

    <!-- 彩色日志格式 -->
    <property name="CONSOLE_LOG_PATTERN"
              value="${CONSOLE_LOG_PATTERN:-%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}}"/>
    <property name="common-pattern-color"
              value="[${spring.application.name}:${server.port}:%X{area}:%X{orgId}:%X{userId}] %clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint}:%clr([%5p]){blue} %clr([${PID}]){magenta} %clr([%X{trace}]){yellow} %clr([%t:%r]){orange} %clr([%logger{50}.%M:%L]){cyan} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}" />

    <!-- Console log output -->
    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <pattern>${common-pattern-color}</pattern>
        </encoder>
    </appender>


    <!-- Log file debug output -->
    <appender name="info" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${log.path}/info.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${log.path}/info/%d{yyyy-MM, aux}/log_info_%d{yyyy-MM-dd}.log.gz</fileNamePattern>
<!--            <maxFileSize>50MB</maxFileSize>-->
            <maxHistory>180</maxHistory>
        </rollingPolicy>
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <!--<pattern>%date [%thread] %-5level [%logger{50}] %file:%line - %msg%n</pattern>-->
            <pattern>${common-pattern-color}</pattern>
        </encoder>
        <filter class="ch.qos.logback.classic.filter.LevelFilter"><!-- 只打印INFO日志 -->
            <level>INFO</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>

    <!-- Log file debug output -->
    <appender name="debug" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${log.path}/debug.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${log.path}/debug/%d{yyyy-MM, aux}/log_debug_%d{yyyy-MM-dd}.log.gz</fileNamePattern>
<!--            <maxFileSize>50MB</maxFileSize>-->
            <maxHistory>180</maxHistory>
        </rollingPolicy>
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <!--<pattern>%date [%thread] %-5level [%logger{50}] %file:%line - %msg%n</pattern>-->
            <pattern>${common-pattern-color}</pattern>
        </encoder>
    </appender>

    <!-- Log file error output -->
    <appender name="error" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${log.path}/error.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${log.path}/error/%d{yyyy-MM}/log_error_%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
            <maxFileSize>50MB</maxFileSize>
            <maxHistory>180</maxHistory>
        </rollingPolicy>
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <pattern>%date [%thread] %-5level [%logger{50}] %file:%line - %msg%n</pattern>
        </encoder>
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>ERROR</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>
    <!--logstash 日志采集集成-->
    <appender name="logstash" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
        <destination>localhost:5044</destination>
        <encoder charset="UTF-8" class="net.logstash.logback.encoder.LogstashEncoder"/>
    </appender>

    <!--nacos 心跳 INFO 屏蔽-->
    <logger name="com.alibaba.nacos" level="OFF">
        <appender-ref ref="error"/>
    </logger>
    <!-- Level: FATAL 0  ERROR 3  WARN 4  INFO 6  DEBUG 7 -->
    <root level="INFO">
        <appender-ref ref="console"/>
        <appender-ref ref="debug"/>
        <appender-ref ref="error"/>
        <appender-ref ref="info"/>
        <appender-ref ref="logstash"/>
    </root>
</configuration>

原因分析：

后续排查发现在/data/service/logs目录下，多了一个目录captcha-service,captcha-service目录下有debug.log,info.log和error.log三个日志，排查发现是系统打印的日志

日志打印为何从/logs跑到了/captcha-service下？

<?xml version="1.0" encoding="UTF-8"?>
<configuration debug="false" scan="false">
    <springProperty scop="context" name="spring.application.name" source="spring.application.name" defaultValue=""/>
    <springProperty scop="context" name="server.port" source="server.port" defaultValue=""/>
    <property name="log.path" value="logs/${spring.application.name}"/>

观察发现，在logback-spring.xml里我定义的log.path为logs/${spring.application.name}，但是排查项目中application.yml中没有配置spring.application.name的参数，所以之前打印的日志才在/data/service/logs目录下。

通过在application.yml添加spring.application.name为test，重新启动发现生成了test文件夹 /data/service/logs/test ，那显然captcha-service也是同理，因为今天升级的时候我替换了一个maven的jar，主项目引用了这个jar，去看了下打这个jar包的项目，果然在application.properties里面发现了spring.application.name=captcha-service