日常开发部署时要避免的两个打爆磁盘的问题

日常开发部署时要避免的两个问题，处理不当，打爆磁盘，写COE，写 casestudy，怀疑职业选择。

生产日志输出到控制台上

有的同学在开发的时候，自己本机调试，喜欢把日志打到控制台上。方式是在logback.xml或者是log4j2.xml文件中进行了以下的配置(其他语言类似)：

<?xml version="1.0" encoding="UTF-8"?>
<!--configuration：根节点，以下3个属性都是根节点的配置，一般用默认参数即可-->
<!--scan（扫描）: 当此属性设置为true时，配置文件如果发生改变，将会被重新加载，默认值为true-->
<!--scanPeriod:多长时间扫描一次，默认60毫秒扫描一次-->
<!--debug：为true时打印出logback内部日志信息，实时查看logback运行状态，默认是false-->
<!--日志分几个级别：debug（输出调试信息，一般情况应用程序不会使用debug日志）、info（输出主要信息）、error（输出错误信息）-->
<configuration scan="true" scanPeriod="60 seconds" debug="false">
<!--property：子节点，定义一个变量-->
<!--name:LOG_PATH日志定义在哪个文件下-->
<property name="LOG_PATH" value="./logs"></property>
    <!--appender:指定日志输出的目的地，目的地可以是控制台、文件等-->
    <!--ConsoleAppender:控制台输出-->
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <!--layout:布局，输出的日志布局是什么，负责把事件转换成字符串，格式化的日志信息输出-->
        <layout>
            <!--%d：日期，代表几月几日输出的-->
            <!--%thread：线程名，web工程都是多线程-->
            <!--%5-level：代表输出级别；级别从左显示5个字符宽度-->
            <!--%logger{35}：打出的类名最长35个字符，否则按照句点分割-->
            <!--%msg：日志消息-->
            <!--%n：换行符-->
            <pattern>
                %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{35} - %msg %n
            </pattern>
        </layout>
    </appender>
    <!--root：根节点设置日志级别，设置使用哪些根节点，使用的是appender节点name的值-->
    <root level="info">
        <appender-ref ref="STDOUT"></appender-ref>
    </root>
</configuration>

上面代码中ConsoleAppender会处理将日志打印到控制台上。

在本机这样调试没有问题，但是到了生产环境，一般需要应用日志与启动日志分离。像上面的配置，root下配置了所有日志都会打印到控制台，而启动日志没有做好日志压缩和滚动清理，就会打满磁盘。

历史日志未清理

机器故障是日常运维中经常出现的问题。一般情况下，机器是可以被修复的，修复时间一般要几天到几个月不等。修复好了，手工一点的公司，会通知开发人员机器已恢复，可以将应用启用了。

然而，应用启动后一段时间磁盘，竟然收到告警说磁盘马上要被打满了。这是怎么回事咧。以logback为例说说日志清理的原理。

<!-- 日志文件输出 -->
<appender name="file" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <File>${log.base}/${log.moduleName}.log
    </File><!-- 设置日志不超过${log.max.size}时的保存路径，注意如果 是web项目会保存到Tomcat的bin目录 下 -->
    <!-- 滚动记录文件，先将日志记录到指定文件，当符合某个条件时，将日志记录到其他文件。-->
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <FileNamePattern>${log.base}/archive/${log.moduleName}_all_%d{yyyy-MM-dd}.%i.log.zip
        </FileNamePattern>
        <!-- 当天的日志大小 超过${log.max.size}时,压缩日志并保存 -->
        <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
            <maxFileSize>${log.max.size}</maxFileSize>
        </timeBasedFileNamingAndTriggeringPolicy>
        <maxHistory>${log.max.history}</maxHistory>
    </rollingPolicy>
    <!-- 日志输出的文件的格式  -->
    <layout class="ch.qos.logback.classic.PatternLayout">
        <pattern>%date{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread]%logger{56}.%method\(\):%L -%msg%n</pattern>
    </layout>
</appender>

其中如下定义了压缩和历史日志的保存策略，有两个比较重要的参数：maxFileSize，maxHistory

<timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
    <maxFileSize>${log.max.size}</maxFileSize>
</timeBasedFileNamingAndTriggeringPolicy>
<maxHistory>${log.max.history}</maxHistory>

先看一下继承关系图

继承关系

maxHistory默认为0，由源码可以看出(TimeBasedRollingPolicy-start())，只有不为0并且清理任务开启标志位true时会触发清理操作

if (maxHistory != INFINITE_HISTORY) {
  archiveRemover = timeBasedFileNamingAndTriggeringPolicy.getArchiveRemover();
  archiveRemover.setMaxHistory(maxHistory);
  if(cleanHistoryOnStart) {
    addInfo("Cleaning on start up");
    archiveRemover.clean(new Date(timeBasedFileNamingAndTriggeringPolicy.getCurrentTime()));
  }
}

清理过程会先计算需要清理的时间范围

int computeElapsedPeriodsSinceLastClean(long nowInMillis) {
    long periodsElapsed = 0;
    //如果尚未执行过清理操作，则默认清理除保留天数外64天以内的日志(由INACTIVITY_TOLERANCE_IN_MILLIS决定)
    if (lastHeartBeat == UNINITIALIZED) {
      addInfo("first clean up after appender initialization");
      periodsElapsed = rc.periodsElapsed(nowInMillis, nowInMillis + INACTIVITY_TOLERANCE_IN_MILLIS);
      if (periodsElapsed > MAX_VALUE_FOR_INACTIVITY_PERIODS)
        periodsElapsed = MAX_VALUE_FOR_INACTIVITY_PERIODS;
    } else {
      //如果已经执行过清理操作，则清理从上次到当前时间的需要清理的时间周期。
      periodsElapsed = rc.periodsElapsed(lastHeartBeat, nowInMillis);
      if (periodsElapsed < 1) {
        addWarn("Unexpected periodsElapsed value " + periodsElapsed);
        periodsElapsed = 1;
      }
    }
    return (int) periodsElapsed;
}

删除时会根据当天时间，生成一个正则表达式：/*****/rsms_all_2018-04-09.(\d{1,3}).log.zip，满足条件的文件就会被清理掉。

由以上可以得出两个结论

1. 如果首次项目启动时，超出maxHistory定义的时间的64天之前的日志是不会被清理的
2. 如果当天日志的编号超出3位数后缀，也将不会被清理
   
   

总结

上面两个问题其实可能对于很多人来说，理解是很简单的事情。但是有两点需要提醒：

1、要从原理上彻底理解清楚

2、要有良好的规范和方法来避免这样的问题。这一点，目前大多数公司都做不到

参考文章

https://www.jianshu.com/p/d9c08785430a

文章转载自公众号：编程一生