If you don’t know about Logback, you can do some research on the theory of logback.

I. Effect after use:

The default SpringBoot logback log is as follows

[127.0.0.1] - [the 2021-01-11 14:03:45. 847] - [INFO] - [I.R.I nterceptors. TestInterceptor] : + + + + + + + + + + + + + + + + + + + + + + + + interceptor interceptor + + + + + + + + + + + + + + + + + + + + + + + + [127.0.0.1] - [the 2021-01-11 14:03:46. 215] - [INFO ]-[io.renren.common.utils.CoreSignUtil]: Core to get the signature of the string prefix = = = = = = = = = = = = = = = = = : appId = 115 b0ebb388f4edd3675d276074cb & cardNum = 100 [the 2021-01-11 14:03:46. 215] - [INFO ] - [io.renren.com mon. Utils. CoreSignUtil] : core to get the signature of the = = = = = = = = = = = = = = = = = : 89 af602fc85ddd4b1638623081589Copy the code

Such logs are the most common. However, when problems occur, logs can be used to operate the failure time. Only logs can be turned over line by line, and troubleshooting is very difficult.

Your system’s logs could look something like this after using the methods in this article

[f1400701cc3549f79793ce0bea0f9ac7] - [127.0.0.1] - [the 2021-01-11 14:03:45. 847] - [INFO] - [I.R.I nterceptors. TestInterceptor] : + + + + + + + + + + + + + + + + + + + + + + + + interceptor interceptor + + + + + + + + + + + + + + + + + + + + + + + + [f1400701cc3549f79793ce0bea0f9ac7] - [127.0.0.1] - [the 2021-01-11 14:03:46. 215] - [INFO] - [io.renren.com mon. Utils. CoreSignUtil] : Core to get the signature of the string prefix = = = = = = = = = = = = = = = = = : appId = 115 b0ebb388f4edd3675d276074cb & cardNum = 100 [f1400701cc3549f79793ce0bea0f9ac7] - [127.0.0.1] - [the 2021-01-11 14:03:46. 215] - [INFO] - [io.renren.com mon. Utils. CoreSignUtil] : Core to get the signature of the = = = = = = = = = = = = = = = = = : 89 af602fc85ddd4b1638623081589Copy the code

Explain:

[f1400701cc3549f79793ce0bea0f9ac7] this is logoId, namely the track ID,

[127.0.0.1] This is requestIp and this is the requester IP

By looking for this ID, you can form a trace chain in the log so that you can see the entire execution of a request.

XML configuration logback(reference)

Create logback-spring. XML file in the resources root directory

<configuration> <! - print to the console - > < appender name = "consoleAppender" class = "ch. Qos. Logback. Core. ConsoleAppender" > < encoder > < pattern > <! --> [%X{logId}]-[%X{requestIp}]-[%d{YYYY-MM-DD HH:mm:ss.SSS}]-[%-5level]-[%logger{36}]: %msg%n </pattern> </encoder> </appender> <! Print a complete log, All levels of the inside - > < appender name = "rollingFileAppender" class = "ch. Qos. Logback. Core. Rolling. RollingFileAppender" > <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <! -- rollover daily --> <fileNamePattern>logs/test-server-log-%d{yyyy-MM-dd}.%i.log</fileNamePattern> <maxFileSize>10MB</maxFileSize> <maxHistory>30</maxHistory> <totalSizeCap>10GB</totalSizeCap> </rollingPolicy> <encoder>  <pattern> <! --> [%X{logId}]-[%X{requestIp}]-[%d{YYYY-MM-DD HH:mm:ss.SSS}]-[%-5level]-[%logger{36}]: %msg%n </pattern> </encoder> </appender> <! - the error log file -- > < appender name = "fileErrorLog" class = "ch. Qos. Logback. Core. Rolling. RollingFileAppender" > < filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>ERROR</level> </filter> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <! -- rollover daily --> <fileNamePattern>logs/test-server-error-log-%d{yyyy-MM-dd}.%i.log</fileNamePattern> <maxFileSize>10MB</maxFileSize> <maxHistory>30</maxHistory> <totalSizeCap>2GB</totalSizeCap> </rollingPolicy> <encoder> <pattern> <! --> [%X{logId}]-[%X{requestIp}]-[%d{YYYY-MM-DD HH:mm:ss.SSS}]-[%-5level]-[%logger{36}]: %msg%n </pattern> </encoder> </appender> <root level="INFO"> <appender-ref ref="consoleAppender"/> <appender-ref ref="rollingFileAppender"/> <appender-ref ref="fileErrorLog"/> </root> </configuration>Copy the code

How does the configuration not take effect: Can you specify the configuration file in the YML file

logging:
  config: classpath:logback-spring.xml
Copy the code

3. Customize and register a filter

1. Customize filter

@Slf4j public class TestFilter implements Filter { @Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException { final HttpServletRequest request = (HttpServletRequest) servletRequest; String logId = IdUtil.simpleUUID(); MDC.put("logId",logId); String ipAddr = iputils.getipaddr (request); // Log tracing ID logId is the same as configured in logback.xml. MDC.put("requestIp",ipAddr); / / IP address requestIp and configuration in logback. XML names consistent filterChain. DoFilter (servletRequest, servletResponse); }}Copy the code

2. Register the filter(you can also register the container with @webFilter)

@Configuration public class FilterRegisterBeanConfig { @Bean public FilterRegistrationBean registrationBean() { final FilterRegistrationBean<Filter> bean = new FilterRegistrationBean<>(); bean.setFilter(new TestFilter()); bean.addUrlPatterns("/*"); bean.setName("testFilter"); bean.setOrder(10); // Depending on the case return bean; }}Copy the code

When done, the testFilter requests are automatically added to the logId and requestId fields

You can create your own controllers and services and log them to see what happens.

You can extend as needed, such as combining interceptor or AOP, to enrich the log content, such as adding user IDS, request paths…… And so on, business needs parameters.