美文网首页
动态修改log日志等级方法

动态修改log日志等级方法

作者: 有个点丶 | 来源:发表于2018-09-28 14:43 被阅读0次

    log4j日志级别动态调整

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

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

    <!-- configuration标签下的scan属性开启logback的自动扫描如果不设置 ,默认为false -->
    <configuration scan="true" scanPeriod="60 seconds" debug="false">
        <!-- 定义日志文件 输入位置 -->
        <property name="log_dir" value="ucarbbs-logs/bbspost" />
        <!-- 日志最大的历史 30天 -->
        <property name="maxHistory" value="30"/>
        <!-- ConsoleAppender 控制台输出日志 -->
        <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
            <!-- 对日志进行格式化 -->
            <encoder>
                <pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger -%msg%n</pattern>
            </encoder>
        </appender>
        <!-- ERROR级别日志 -->
        <!-- 滚动记录文件,先将日志记录到指定文件,当符合某个条件时,将日志记录到其他文件 RollingFileAppender-->
        <appender name="ERROR" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <!-- 过滤器,只记录WARN级别的日志 -->
            <filter class="ch.qos.logback.classic.filter.LevelFilter">
                <level>ERROR</level>
                <onMatch>ACCEPT</onMatch>
                <onMismatch>DENY</onMismatch>
            </filter>
            <!-- 最常用的滚动策略,它根据时间来制定滚动策略.既负责滚动也负责出发滚动 -->
            <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                <!--日志输出位置  可相对、和绝对路径 -->
                <fileNamePattern>${log_dir}/%d{yyyy-MM-dd}/error-log.log</fileNamePattern>
                <!-- 可选节点,控制保留的归档文件的最大数量,超出数量就删除旧文件假设设置每个月滚动,且<maxHistory>是6,
                则只保存最近6个月的文件,删除之前的旧文件。注意,删除旧文件是,那些为了归档而创建的目录也会被删除-->
                <maxHistory>${maxHistory}</maxHistory>
            </rollingPolicy>
    
            <!-- 按照固定窗口模式生成日志文件,当文件大于20MB时,生成新的日志文件。窗口大小是1到3,当保存了3个归档文件后,将覆盖最早的日志。
            <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
              <fileNamePattern>${log_dir}/%d{yyyy-MM-dd}/.log.zip</fileNamePattern>
              <minIndex>1</minIndex>
              <maxIndex>3</maxIndex>
            </rollingPolicy>   -->
            <!-- 查看当前活动文件的大小,如果超过指定大小会告知RollingFileAppender 触发当前活动文件滚动
            <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
                <maxFileSize>5MB</maxFileSize>
            </triggeringPolicy>   -->
    
            <encoder>
                <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern>
            </encoder>
        </appender>
    
        <!-- WARN级别日志 appender -->
        <appender name="WARN" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <!-- 过滤器,只记录WARN级别的日志 -->
            <filter class="ch.qos.logback.classic.filter.LevelFilter">
                <level>WARN</level>
                <onMatch>ACCEPT</onMatch>
                <onMismatch>DENY</onMismatch>
            </filter>
            <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                <!-- 按天回滚 daily -->
                <fileNamePattern>${log_dir}/%d{yyyy-MM-dd}/warn-log.log
                </fileNamePattern>
                <!-- 日志最大的历史 60天 -->
                <maxHistory>${maxHistory}</maxHistory>
            </rollingPolicy>
            <encoder>
                <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern>
            </encoder>
        </appender>
    
        <!-- INFO级别日志 appender -->
        <appender name="INFO" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <!-- 过滤器,只记录INFO级别的日志 -->
            <filter class="ch.qos.logback.classic.filter.LevelFilter">
                <level>INFO</level>
                <onMatch>ACCEPT</onMatch>
                <onMismatch>DENY</onMismatch>
            </filter>
            <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                <!-- 按天回滚 daily -->
                <fileNamePattern>${log_dir}/%d{yyyy-MM-dd}/info-log.log
                </fileNamePattern>
                <!-- 日志最大的历史 60天 -->
                <maxHistory>${maxHistory}</maxHistory>
            </rollingPolicy>
            <encoder>
                <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern>
            </encoder>
        </appender>
    
        <!-- DEBUG级别日志 appender -->
        <appender name="DEBUG" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <!-- 过滤器,只记录DEBUG级别的日志 -->
            <filter class="ch.qos.logback.classic.filter.LevelFilter">
                <level>DEBUG</level>
                <onMatch>ACCEPT</onMatch>
                <onMismatch>DENY</onMismatch>
            </filter>
            <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                <!-- 按天回滚 daily -->
                <fileNamePattern>${log_dir}/%d{yyyy-MM-dd}/debug-log.log
                </fileNamePattern>
                <!-- 日志最大的历史 60天 -->
                <maxHistory>${maxHistory}</maxHistory>
            </rollingPolicy>
            <encoder>
                <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern>
            </encoder>
        </appender>
    
        <!-- TRACE级别日志 appender -->
        <appender name="TRACE" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <!-- 过滤器,只记录ERROR级别的日志 -->
            <filter class="ch.qos.logback.classic.filter.LevelFilter">
                <level>TRACE</level>
                <onMatch>ACCEPT</onMatch>
                <onMismatch>DENY</onMismatch>
            </filter>
            <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                <!-- 按天回滚 daily -->
                <fileNamePattern>${log_dir}/%d{yyyy-MM-dd}/trace-log.log
                </fileNamePattern>
                <!-- 日志最大的历史 60天 -->
                <maxHistory>${maxHistory}</maxHistory>
            </rollingPolicy>
            <encoder>
                <pattern>%d{yyyy-MM-ddH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern>
            </encoder>
        </appender>
        <logger name="com.ibatis.sqlmap.engine" level="DEBUG" />
        <logger name="com.test.LogLevelController" level="DEBUG" additivity="true">
            <appender-ref ref="STDOUT"/>
        </logger>
    
        <!-- root级别   DEBUG -->
        <root level="INFO">
            <!-- 控制台输出 -->
            <appender-ref ref="STDOUT" />
            <!-- 文件输出 -->
            <appender-ref ref="ERROR" />
            <appender-ref ref="INFO" />
            <appender-ref ref="WARN" />
            <appender-ref ref="DEBUG" />
            <appender-ref ref="TRACE" />
        </root>
    </configuration>
    

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

    <configuration scan="true" scanPeriod="60 seconds" debug="false">
    

    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标签声明定制包或类的日志打印级别:

    <logger name="packageName Or ClassName" level="DEBUG" />
    

    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<Logger> 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参与;

    1. 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的等级。
    希望这篇文章可以帮助到需要的人。

    相关文章

      网友评论

          本文标题:动态修改log日志等级方法

          本文链接:https://www.haomeiwen.com/subject/wgaeoftx.html