wordpress英文站,徐州最好网站建设,竞价推广,太原网站建设公司背景
我们生产环境有一个服务半夜报警#xff1a;磁盘剩余空间不足10%#xff0c;请及时处理。排查后发现是新上线的一个功能#xff0c;日志打太多导致的#xff0c;解决方法有很多#xff0c;就不赘述了。领导担心报警不及时、或者报警遗漏#xff0c;担心磁盘满了对线…背景
我们生产环境有一个服务半夜报警磁盘剩余空间不足10%请及时处理。排查后发现是新上线的一个功能日志打太多导致的解决方法有很多就不赘述了。领导担心报警不及时、或者报警遗漏担心磁盘满了对线上业务有负面影响甚至不可用令我研究一下该情况下对服务的影响。
正文
注我们线上的应用使用Logback日志框架进行打印所以log4j、log4j2或其它日志框架不在本次研究的范围。
实验研究
实验步骤
启动服务观察各项指标正常模拟正常工作的服务以及环境状态将磁盘写满观察应用服务、宿主机各项指标查看服务响应是否正常包括功能以及性能将大文件删除恢复重复第3步
实验过程
第1、3、5步重在观测不赘述。
第2步的模拟磁盘写满使用linux的fallocate命令。
将磁盘写满的方式如下有几种
自己写文件写满为止速度较慢有开发写脚本成本使用dd命令但是比较慢取决于磁盘的速度使用truncate命令但是该命令操作的结果并不占用实际的磁盘空间使用fallocate命令fallocate -l {size} {fileName}如fallocate -l 20G text1
我选择了方式4很快就写满了磁盘
验证方式vim {xxx}进入文件编辑写入任意内容保存失败并提示Can’t open file for writing(No space left on device)
实验结果
磁盘写满前、后应用服务各项指标均正常功能、性能磁盘写满后服务器磁盘空间报警无可用空间删除文件后报警恢复磁盘写满后应用日志停止打印删除文件后应用日志恢复打印
即磁盘满了对于使用logback日志框架的应用并不会造成影响。
实验结果令人诧异按正常理解磁盘满了之后再写入会报No space left on device异常进而影响到应用程序的功能。
原理分析
logback配置文件里的文件appender如下RollingFileAppender同理
appender nameFILE classch.qos.logback.core.FileAppenderfile${LOG_HOME}/${APP_NAME}.log/fileencoderpattern%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n/pattern/encoder
/appender把关注点放到appender即可因为最终的日志输出是由appender控制的它控制写在哪个文件里格式是怎样的滚动策略又是怎样的。
通过IDEA查看RollingFileAppender的继承关系如下下示 将视线聚焦到ch.qos.logback.core.OutputStreamAppender#writeBytes代码如下
private void writeBytes(byte[] byteArray) throws IOException {if(byteArray null || byteArray.length 0)return;lock.lock();try {this.outputStream.write(byteArray);if (immediateFlush) {this.outputStream.flush();}} finally {lock.unlock();}
}由上可知写日志时会加锁避免资源竞争然后通过outputStream写出接着马上刷盘默认情况。
这里的outputStream可了不得是个ResilientFileOutputStream实例顾名思议【弹性的】FileOutputStream。它是个子类核心逻辑在父类ResilientOutputStreamBase上看看write方法
public void write(byte b[], int off, int len) {if (isPresumedInError()) {if (!recoveryCoordinator.isTooSoon()) {attemptRecovery();}return; // return regardless of the success of the recovery attempt}try {os.write(b, off, len);postSuccessfulWrite();} catch (IOException e) {postIOFailure(e);}
}这个write方法隐藏着【即使磁盘满了也不影响业务】的秘密它的核心逻辑是如果能正常写文件就写如果写入失败出现了IO异常就抓住异常并切换至失败状态接下来的一段时间都不再继续写文件直接返回。
而此处所有的IO异常就包含了No space left on device因此此处便是磁盘满了之后继续日志写入却不会抛出No space left on device异常进而影响业务的原因。
还有一个问题待磁盘有剩余空间后如何恢复日志写入上面实验结果提到磁盘写满后应用日志停止打印删除文件后应用日志恢复打印。因此必然会有一个策略能够在磁盘空间恢复后继续进行日志写入。
再仔细查看看write方法方法首先判断当前状态是否为“失败”。若是接着检查自上次失败至今的时间。如果已经经过了很长时间就【尝试恢复】。
void attemptRecovery() {try {close();} catch (IOException e) {}addStatusIfCountNotOverLimit(new InfoStatus(Attempting to recover from IO failure on getDescription(), this));// subsequent writes must always be in append modetry {os openNewOutputStream();presumedClean true;} catch (IOException e) {addStatusIfCountNotOverLimit(new ErrorStatus(Failed to open getDescription(), this, e));}
}尝试恢复的逻辑是关闭旧文件流并重新打开文件流将【失败】状态切换至【半恢复】状态此处并未完全进入【正常】状态而是立即返回即是说当次的日志记录请求并不会写文件。
下次的日志写入才会尝试将日志写入文件
若日志成功写入文件就将状态切换至【正常】状态。若日志写入文件失败就将状态切换至【失败】状态。
此处的失败以及恢复逻辑非常像Hystrix断路器即经历一个正常→失败→半通路状态通过下次请求的结果来决定是恢复正常还是保持失败。
上面提到若经过很长时间就尝试恢复这里的【很长时间】其实是一个泛指它有自己的时间计算逻辑此处采用了类似于RocketMQ在消费失败时的重试策略即采用指数退避逻辑来控制重试时间间隔。
每次【半恢复】状态下写文件失败时会保持【失败】状态且每一次的失败写入都会指数级延长【失败】状态保持的时间。
public boolean isTooSoon() {long now getCurrentTime();if (now next) {next now getBackoffCoefficient();return false;} else {return true;}
}private long getBackoffCoefficient() {long currentCoeff backOffCoefficient;if (backOffCoefficient BACKOFF_COEFFICIENT_MAX) {backOffCoefficient * BACKOFF_MULTIPLIER;}return currentCoeff;
}backOffCoefficient初始值20
BACKOFF_COEFFICIENT_MAX327680
BACKOFF_MULTIPLIER4
总结
使用Logback日志框架当磁盘满了后不必惊慌它不会对应用程序产生太负面影响。仔细考虑做为一个日志框架本该如此不能因为写不了日志就抛出异常进而影响应用本身毕竟日志终究是个辅助的旁路逻辑没有它应用也应该work well。
底层知识的掌握有助于迅速理解上层应用。在阅读源码的过程中我发现了非常熟悉的设计逻辑即类似于Hystrix的断路器和RocketMQ消费失败重试的策略。由于之前有相关经验因此我很快就能够理解作者的设计意图。
注事后我测试了一下Log4j2日志框架表现也差不多磁盘满了也不会对应用程序本身产生影响。
