Logback动态修改日志级别的方法

问题提出：

一般在生产环境上，日志的级别是INFO以上，但有时候程序出现问题（如SQL报错），少量日志不能尽快定位问题，这时候可以动态修改日志级别到DEBUG，打印更多日志后可以快速定位到问题。

解决方法：

定义动态修改日志级别的接口：这种方法的好处是不用修改配置文件，排错后再次调用接口把日志级别修改回去；坏处是需要在代码中写死指定哪些包要修改日志级别。示例代码如下：

@RestController
public class LogController {
 private static Logger logger = LoggerFactory.getLogger(LogController.class);

@RequestMapping(value = "logLevel/{logLevel}")
 public String changeLogLevel(@PathVariable("logLevel") String logLevel) {

try {
     LoggerContext loggerContext = (LoggerContext) LoggerFactory.getILoggerFactory();
     loggerContext.getLogger("org.mybatis").setLevel(Level.valueOf(logLevel));
     loggerContext.getLogger("org.springframework").setLevel(Level.valueOf(logLevel));
   } catch (Exception e) {
     logger.error("动态修改日志级别出错", e);
     return "fail";
   }

return "success";
 }
}

修改logback.xml配置文件：在configuration根节点配置属性scan和scanPeriod，scan为true时，配置文件被修改会被重新加载，scanPeriod定义了扫描文件变化的周期，默认6000毫秒，即一分钟。这种做法的好处是不用自己写修改日志级别的逻辑；坏处是要手动更改配置文件，排错完成后需改回原来的配置。示例配置如下：

<?xml version="1.0" encoding="UTF-8" ?>
<configuration scan="true" scanPeriod="6000">
 <property name="LOG_HOME" value="/export/logs/cmdb/" />
 <property name="APP_NAME" value="cmdb" />
 <property name="LOG_FILE_EXPIRE_TIME" value="180" />

<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
   <encoder>
     <pattern>％d{yyyy-MM-dd HH:mm:ss.SSS} | ${APP_NAME} - ％p | ％thread | ％c | line:％L - ％m％n</pattern>
   </encoder>
 </appender>
 <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
   <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
     <fileNamePattern>${LOG_HOME}${APP_NAME}.％d{yyyy-MM-dd}.log</fileNamePattern>
     <maxHistory>${LOG_FILE_EXPIRE_TIME}</maxHistory>
   </rollingPolicy>
   <encoder>
     <pattern>％d{yyyy-MM-dd HH:mm:ss.SSS} | ${APP_NAME} - ％p | ％thread | ％c | line:％L - ％m％n</pattern>
   </encoder>
 </appender>

<root>
   <level value="INFO" />
   <appender-ref ref="STDOUT" />
   <appender-ref ref="FILE" />
 </root>
</configuration>

来源：https://blog.csdn.net/totally123/article/details/78931287