Is There Just service_stdout.log on Your Application?

By Shuailing

1. Background

Recently, a colleague from my team reported an issue with the logback-spring.xml file not working as expected. Since I haven't applied for a new application in a while, I'm not very familiar with configuration matters. Most of the time, I just maintain existing applications and use logs directly without paying much attention to the configuration. So, troubleshooting took a lot of my time. In this article, I will describe the entire troubleshooting process, covering the configuration of Logback and the analysis of reasons for its ineffectiveness. I hope this will provide some insights for those facing similar issues.

1.1 Introduction to Logback

SLF4J (Simple Logging Facade for Java) serves as a simple facade for Java's logging API. It provides a simple and unified interface for logging, while specific logging implementation can be completed by different logging libraries.

Logback is one of these logging libraries. It is designed to integrate seamlessly with SLF4J or even replace it because one of the developers of Logback is also the founder of SLF4J.

2. Configuration of Logback

Since pandora-boot integrates Logback by default, additional Logback dependencies are not required.

2.1 Configuration

Logback is officially recommended, so all troubleshooting steps are based on the ineffectiveness of Logback.

1) Specify the configuration file path

application.properties Add configuration items logging.config=classpath:logback-spring.xml

2) Custom the configuration file

<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true">
    <!-- https://github.com/spring-projects/spring-boot/blob/v1.5.13.RELEASE/spring-boot/src/main/resources/org/springframework/boot/logging/logback/defaults.xml -->
    <include resource="org/springframework/boot/logging/logback/defaults.xml" />
    <property name="APP_NAME" value="xxxx" />
    <property name="LOG_PATH" value="${user.home}/logs/eleme/${APP_NAME}/" />
    <property name="LOG_FILE" value="${LOG_PATH}/application.log" />
    <property name="ERROR_LOG_FILE" value="${LOG_PATH}/common-error.log"/>
    <property name="TRACE_FILE_LOG_PATTERN" value="[%X{requestId}][%X{rpcId}] -%green(%d{yyyy-MM-dd HH:mm:ss.SSS}) ${LOG_LEVEL_PATTERN:-%5p} %magenta(${PID:- }) --- [%t] %-40.40logger{39} : %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>
    <property name="ERROR_FILE_LOG_PATTERN_D"
              value="${ERROR_FILE_LOG_PATTERN_D:-%d{yyyy-MM-dd HH:mm:ss.SSS} ${LOG_LEVEL_PATTERN:-%5p} [%X{requestId}] [%X{rpcId}][traceId:%X{EAGLEEYE_TRACE_ID}][%c{2}#%M] %logger{39} : %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}}"/>

    <appender name="APPLICATION"
              class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_FILE}</file>
        <encoder>
            <pattern>${TRACE_FILE_LOG_PATTERN}</pattern>
        </encoder>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
            <maxHistory>7</maxHistory>
            <maxFileSize>50MB</maxFileSize>
            <totalSizeCap>20GB</totalSizeCap>
        </rollingPolicy>
    </appender>

    <appender name="ERROR_APPENDER"
              class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${ERROR_LOG_FILE}</file>
        <encoder>
            <pattern>${ERROR_FILE_LOG_PATTERN_D}</pattern>
        </encoder>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${ERROR_LOG_FILE}.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
            <maxHistory>7</maxHistory>
            <maxFileSize>50MB</maxFileSize>
            <totalSizeCap>20GB</totalSizeCap>
        </rollingPolicy>
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>ERROR</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>

    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>${TRACE_CONSOLE_LOG_PATTERN}</pattern>
            <charset>utf8</charset>
        </encoder>
    </appender>

    <root level="INFO">
<!--        <appender-ref ref="CONSOLE" />-->
        <appender-ref ref="APPLICATION" />
        <appender-ref ref="ERROR_APPENDER" />
    </root>
</configuration>

2.2 Possible Problems with Configurations

1) Custom variables are invalid.

If you reference external variables, only a few are applicable, such as ${PID}, ${LOG_FILE}, ${LOG_PATH}, and ${LOG_EXCEPTION_CONVERSION_WORD}. For other variables, it is recommended that you define them as properties for normal use. such as the APP_NAME mentioned above.

2) How do I view more error messages?

You can add -Dlog4j.defaultInitOverride=true at startup.

2.3 Invalid after Configuration

After the preceding configuration, the custom Appender may not take effect. It means only the service_stdout.log is included in the specified directory, without customized configuration files.

All files will be output to the service_stdout.log, because in appctl.sh, the default start_pandora_boot method has already directed the output to "$SERVICE_OUT" 2>&1 "&". There's nothing wrong with this part. The core issue is how the custom logback-spring.xml is distributed.

3. Analysis of Reasons for Ineffectiveness

3.1 Remote Debugging

• Enable the remote debug.

JPDA_OPTS="-agentlib:jdwp=transport=$JPDA_TRANSPORT,address=$JPDA_ADDRESS,server=y,suspend=$JPDA_SUSPEND"

• Start the IDEA Remote JVM Debug

3.2. View the Logback Appender

Execute the command LoggerFactory.getLogger("ROOT"), and view the aai under the ROOT (the AppenderAttachableImpl serves to manage and process multiple Appender objects associated with the logger). It is found that they are not the Appender objects defined by logback-spring.xml, which means that they are overwritten or have different priorities.

Here, I also took a roundabout course and spent much time debugging the source code, including org.springframework.boot.context.logging.LoggingApplicationListener#initialize. Here, logback-spring.xml has been loaded.

After revisiting the official documents, I found a hint that the problem could stem from the package conflict.

3.3 Troubleshoot Log Conflicts

Keep in mind the order of the official diagram:

• In theory, the use of Logback excludes SLF4J-Log4j12.

• Because a conflict will occur between jcl-over-slf4j and commons-logging, so commons-logging needs to be excluded.

If there is no conflict with pom, the sub pom.xml should also be excluded, and using Dependency Analyzer can make this process much more efficient.

The minimum principle is used in this process to avoid affecting other business codes.

3.4 Double Check

Execute the command LoggerFactory.getLogger("ROOT"), and view the aai of the ROOT instance.

The result is the same as the appender defined by logback-spring.xml, and the file is also normally initialized.

4. Summary

(1) Read official documentation of spring-boot website carefully. Some issues may be included in the document.

(2) When introducing second-party packages, adopt the minimum principle and make good use of exclusion.

Disclaimer: The views expressed herein are for reference only and don't necessarily represent the official views of Alibaba Cloud.

Community

Is There Just service_stdout.log on Your Application?

1. Background

1.1 Introduction to Logback

2. Configuration of Logback

2.1 Configuration

1) Specify the configuration file path

2) Custom the configuration file

2.2 Possible Problems with Configurations

1) Custom variables are invalid.

2) How do I view more error messages?

2.3 Invalid after Configuration

3. Analysis of Reasons for Ineffectiveness

3.1 Remote Debugging

3.2. View the Logback Appender

3.3 Troubleshoot Log Conflicts

3.4 Double Check

4. Summary

Read previous post:

Read next post:

Alibaba Cloud Community

You may also like

Comments

Alibaba Cloud Community

Related Products

Web Hosting Solution

Web Hosting

EMAS Superapp

Web App Service