动态修改log日志等级方法

log4j日志级别动态调整

修改logback.xml来定制日志级别

由于项目中的在生产上的包由于经过几轮测试，所以在打生产包时会将某些日志级别打开到info级别，但是在某些突发情况下，我们需要将日志的级别调整到debug级别来查看更加详细的日志来追踪问题，logback.xml可以在进行配置，如下面的代码在logback.xml进行声明：

    
    
    
    
    
    
        
        
            %d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger -%msg%n
        
    
    
    
    
        
        
            ERROR
            ACCEPT
            DENY
        
        
        
            
            ${log_dir}/%d{yyyy-MM-dd}/error-log.log
            
            ${maxHistory}
        

        
        

        
            %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n
        
    

    
    
        
        
            WARN
            ACCEPT
            DENY
        
        
            
            ${log_dir}/%d{yyyy-MM-dd}/warn-log.log
            
            
            ${maxHistory}
        
        
            %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n
        
    

    
    
        
        
            INFO
            ACCEPT
            DENY
        
        
            
            ${log_dir}/%d{yyyy-MM-dd}/info-log.log
            
            
            ${maxHistory}
        
        
            %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n
        
    

    
    
        
        
            DEBUG
            ACCEPT
            DENY
        
        
            
            ${log_dir}/%d{yyyy-MM-dd}/debug-log.log
            
            
            ${maxHistory}
        
        
            %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n
        
    

    
    
        
        
            TRACE
            ACCEPT
            DENY
        
        
            
            ${log_dir}/%d{yyyy-MM-dd}/trace-log.log
            
            
            ${maxHistory}
        
        
            %d{yyyy-MM-ddH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n
        
    
    
    
        
    

    
    
        
        
        
        
        
        
        
        
    

而刷新配置的声明就是这个：

scan属性：并将值设置为true，
scanPeriod属性：扫描配置文件的间隔周期，有milliseconds,secends,minutes,hours。
debug属性：声明logback内部的日志是否打印，默认为false，即不打印。
scan属性如果之前配为false或者没有配置，那么后面改为true是否能够生效呢？

根据ConfigurationAction，可以最终追溯到JoranConfigurator，和Interpreter。
JoranConfigurator.doConfigure(URL url)方法被调用的地方基本与Interpreter有关，而从Interperter.startElement()方法追下去，最后会到ReconfigureOnChangeTask和ReconfigureOnChangeFilter这两个地方，前者只有scan=true时会创建，周期执行；后者甚至在一个groovy类中只剩一个import没有多余的信息。
ReconfigureOnChangeTask中，触发重新扫描配置的地方:

    public void run() {
        //此处省略无关代码
        if (mainConfigurationURL.toString().endsWith("xml")) {
            //配置文件是xml时执行的方法
            performXMLConfiguration(lc, mainConfigurationURL);
        } else if (mainConfigurationURL.toString().endsWith("groovy")) {
            //配置文件是groovy时执行的方法
            if (EnvUtil.isGroovyAvailable()) {
                lc.reset();
                GafferUtil.runGafferConfiguratorOn(lc, this, mainConfigurationURL);
            } else {
                addError("Groovy classes are not available on the class path. ABORTING INITIALIZATION.");
            }
        }
        //此处省略无关代码
    }

xml配置文件最终会调用的地方：

void processScanAttrib(InterpretationContext ic, Attributes attributes) {
        String scanAttrib = ic.subst(attributes.getValue(SCAN_ATTR));
        if (!OptionHelper.isEmpty(scanAttrib) && !"false".equalsIgnoreCase(scanAttrib)) {
        //此处无关代码省略
        ReconfigureOnChangeTask rocTask = new ReconfigureOnChangeTask();
        //此处无关代码省略
        ScheduledFuture scheduledFuture = scheduledExecutorService.scheduleAtFixedRate(rocTask, duration.getMilliseconds(), duration.getMilliseconds(),
                            TimeUnit.MILLISECONDS);
        }
    }

在groovy配置这里，它好像无视了scan属性(这里的源码看的很迷，明明这个类没有地方初始化，若有误，希望指正讨论):

void scan(String scanPeriodStr = null) {
        if (scanPeriodStr) {
            ReconfigureOnChangeTask rocTask = new ReconfigureOnChangeTask();
            //省略无关代码
                Duration duration = Duration.valueOf(scanPeriodStr);
                ScheduledExecutorService scheduledExecutorService = context.getScheduledExecutorService();
                ScheduledFuture scheduledFuture = scheduledExecutorService.scheduleAtFixedRate(rocTask, duration.getMilliseconds(), duration.getMilliseconds(), TimeUnit.MILLISECONDS);
                //省略无关代码  
        }
    }

回到之前的问题，scan属性如果之前配为false或者没有配置，那么后面改为true是否能够生效呢？
我的结论是不能。配置文件是xml，一开始scan设置为true，那么后面改为false，再改回true，那么仍然可以正常的开启，因为会周期性执行。如果一开始scan属性设置为false，那么之后就不会再扫描了。
关于groovy配置文件的流程，就不详细说了，不理解。
在configuration标签下添加logger标签声明定制包或类的日志打印级别:

ps：将更深路径的日志级别放到后面声明，因为修改日志的级别时，会修改整个包下面的log日志级别，那么在前面的声明会被下面的上级包的配置给覆盖掉。

通过网络接口来动态调整应用内的日志级别

由于日志的级别在logback.xml文件是热加载，但是它是额外启动一个线程每间隔一段时间去重新扫描仪电xml配置文件覆盖内存中的参数，但是这对于一些资源相对紧张的环境下，或者在无法直接接触到服务机器时，只能通过网络接口查询日志的这些场景下，就可以通过在这种方式来对日志级别进行动态的定制。
代码如下：

import ch.qos.logback.classic.Level;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class LogLevelController {

    private static final Logger LOGGER = LoggerFactory.getLogger(LogLevelController.class);

    @GetMapping("/setLogLevel")
    public String getClassName(@RequestParam("level") String level, @RequestParam("packageName") String packageName) {
        if (LOGGER instanceof ch.qos.logback.classic.Logger) {
            ch.qos.logback.classic.Logger log = (ch.qos.logback.classic.Logger) LOGGER;
            ch.qos.logback.classic.Logger logger = log.getLoggerContext().getLogger(packageName);
            logger.setLevel(Level.toLevel(level));
            LOGGER.info("--------------------test msg modify result----------------------");
            return "success";
        }
        return "failed";
    }

}

可以指定日志级别的根源

1. Logger全局变量
   通过上面的两种修改方式，其实我们可以看到，共同点都是去修改Logger，那么当我们去定义的个中参数，最终影响到的都是Logger，所以可以去Logger的源码里面找一找，可以先看一下Logger中定义的全局变量：

    private String name;
    transient private Level level;
    transient private int effectiveLevelInt;
    transient private Logger parent;
    transient private List childrenList;
    transient private boolean additive = true;
    final transient LoggerContext loggerContext;

transient关键字是用来修饰对象被序列化时忽略的字段，为什么这么多参数都用transient关键字修饰没理解，暂时不管。
name：当前Logger的名称;
level:日志打印等级;
effectiveLevelInt:收level属性影响，日志打印时校验的参数，换句话说，我们只要能够修改这个参数，就可以修改日志打印的级别;
parent:父Logger，一般我们打印日志并不会用到它，主要是为了持有父节点引用，Logger中共有三个方法会使用到这个变量，handleParentLevelChange(newParentLevelInt)，setLevel(newlevel)，callAppenders(event),后面再对这三个方法进行详细说明;
childrenList:子节点集合，保存当前logger的下一层所有的子节点，但不会包括子节点的子节点，;
additive:这个变量主要印象的callAppenders方法的调用，当设置为false时，将子节点执行的appender事件，在自己这里执行之后不在向上传递;
loggerContext:logger上下文，主要处理跟logger对象业务相关的工作，比如Logger内部参数变化或者logger外部发生变化，这些场景可能会有部分工作需要loggerContext参与;

2. Logger中能影响日志等级的方法
   Logger中的方法大部分都跟打印日志有关，日志打印时仅仅只是检验effectiveLevelInt的值，能影响这个参数的方法只有handleParentLevelChange(newParentLevelInt)和setLevel(newlevel)。

private synchronized void handleParentLevelChange(int newParentLevelInt) {
        if (level == null) {
            effectiveLevelInt = newParentLevelInt;
            // propagate the parent levelInt change to this logger's children
            if (childrenList != null) {
                int len = childrenList.size();
                for (int i = 0; i < len; i++) {
                    Logger child = (Logger) childrenList.get(i);
                    child.handleParentLevelChange(newParentLevelInt);
                }
            }
        }
}

当子节点中的level为空时，将受到parent的Level影响，这个方法只会生效一次，之后会被忽略，并且截断parent的level变化事件继续传播给自己的Child，这个过程当中虽然parent的level发生了变化，但是只能影响level为空的子节点中effectiveLevelInt的值。
那么Logger中的Level在什么时候会被初始化呢？在LoggerFactory中找到默认的Logger创建工厂——LoggerContext，而在LoggerContext中，创建Logger的工作重新回到Logger本身的createChildByName()。

Logger createChildByLastNamePart(final String lastPart) {
        //省略一部分...
        childrenList.add(childLogger);
        childLogger.effectiveLevelInt = this.effectiveLevelInt;
        return childLogger;
}

Logger实例被创建时只会初始化effectiveLevelInt，并且直接使用parent节点effectiveLevelInt的值。那么Level只有自己被调用setLevel的时候才会初始化，之前在配置logback.xml中的logger标签中就是在调用setLevel方法。

总结

虽然上面说明了两种方式去修改日志打印等级的方法，但是其实本质上都是一样的，只不过修改配置文件是由log4j自己调用setLevel，提供网络接口的方式则是主动去调用setLevel，起到的效果是一样的。
有一点需要注意，举个例子：
比如修改了com.test级别的logger的level后，这个时候再去修改com级别的logger的level，那么这个修改事件会被com.test截断并且忽略，com.test以下的logger将无法再修改，如果要修改，只能特意的去修改com.test的等级。
希望这篇文章可以帮助到需要的人。