hdfs的慢盘检测

这是我的第105篇原创文章

慢盘检测引入的背景

hdfs作为一个存储系统,势必会使用大量的磁盘。然而,在长期的使用过程中,磁盘也难免会磨损,出现损坏的磁道或扇区,导致磁盘读写变慢,IO操作耗时变长,从而引发业务的耗时增加(例如spark/flink计算任务的耗时增加等)。但是,要确认是磁盘变慢引起的业务耗时增加,这个排查过程是比较困难的,同时排查过程也是非常耗时耗力的。

在“降本增效”,运维便利性大环境的趋势下,hdfs引入了慢盘检测的特性。

慢盘识别的原理

所谓"慢盘",只是一个相对的概念,也就是在同一个DN中,对某个磁盘IO操作的耗时相比其他磁盘更大,并且超过了配置的指定阈值,那么这个盘就被定义为"慢"盘。

了解了这个慢盘的定义,其实慢盘识别的大概逻辑基本上也就清楚了。既然是比较磁盘IO操作的耗时,自然而然首先是要记录IO的耗时。在Datanode里面,每次涉及磁盘IO操作的动作,都会统计其耗时,例如sync、flush、read、write等,这些信息最终都会被存储在metrics中。

有了IO操作耗时的统计之后,在独立的慢盘检测线程中,会定时获取所有磁盘的IO操作耗时信息,然后按类别分别计算出绝对中位差,根据中位差计算出上限值(包括与配置指定阈值的比较,两者取较大的值作为真正的上限值),磁盘IO操作耗时大于这个上限值的就是慢盘了。

注:任意一种操作类型的耗时大于该类型计算出的上限值,都会被认为是慢盘。

相关代码如下所示:

879e6c32c23378fb0d5aa4730c46785b.jpeg

<think>我们正在讨论日志存储逻辑的流程图。根据引用[3],EXT文件系统的块结构包括引导块、多个块组,每个块组有数据块位图、inode位图、inode表和数据块。日志存储可能涉及类似的文件系统结构。不过,用户要求的是日志存储位置选择逻辑的流程图,我们需要抽象出关键步骤。 日志存储位置选择逻辑通常涉及以下步骤: 1. 日志产生:应用程序或系统生成日志事件。 2. 日志收集:收集日志事件,可能通过日志代理(如Filebeat、Fluentd)或直接写入。 3. 存储位置决策:根据配置策略(如基于日志类型、级别、时间等)决定存储位置。存储位置可能包括: - 本地文件系统(如/var/log目录) - 网络存储(如NFS) - 分布式文件系统(如HDFS) - 云存储(如AWS S3) - 日志管理平台(如Elasticsearch、Splunk) 4. 写入存储:将日志写入选定的位置。 流程图可以用以下步骤表示: 开始 -> 产生日志事件 -> 收集日志 -> 根据配置策略选择存储位置 -> 写入存储 -> 结束 其中,配置策略可能包括: - 如果日志类型为系统日志,则存储到本地/var/log/syslog - 如果日志类型为应用日志且级别为ERROR,则存储到Elasticsearch - 如果日志大小超过阈值,则切换到下一个存储位置 由于引用[1]提到流程图在跨部门协作中的作用,我们可以用流程图清晰表达这一逻辑。 根据引用[2],磁IO最耗时的部分是查找时间,因此如果选择本地文件系统存储,应考虑日志文件的组织以减少查找时间(例如顺序写入)。 引用[4]提到了BPMN流程定义,我们可以用类似的方式描述流程,但这里我们只需用文字描述流程图步骤。 因此,日志存储位置选择逻辑的流程图如下: ```mermaid graph TD A[开始] --> B[产生日志事件] B --> C[收集日志] C --> D{根据配置策略选择存储位置} D -->|本地文件系统| E[写入本地文件] D -->|网络存储| F[写入网络存储] D -->|云存储| G[写入云存储] D -->|日志管理平台| H[发送到日志平台] E --> I[结束] F --> I G --> I H --> I ``` **配置策略示例**: 1. 检查日志类型:系统日志、应用日志、安全日志等。 2. 检查日志级别:DEBUG、INFO、WARN、ERROR等。 3. 检查当前存储状态(如磁空间、网络状况)。 4. 根据预定义的规则选择存储位置。 例如,规则可能为: - 如果日志级别为ERROR,则发送至Elasticsearch; - 如果当前本地磁空间不足,则切换至网络存储; - 否则,写入本地文件。 **注意事项**: - 日志轮转:当文件达到一定大小或时间间隔,进行轮转(如重命名并压缩旧日志,创建新文件)。 - 性能考虑:顺序写入以减少磁查找时间(引用[2])。 希望这个流程图和说明能帮助您理解日志存储位置选择逻辑。</think>### 日志信息存储位置选择逻辑流程图 根据您的需求,我设计了日志存储位置选择的逻辑流程图,该流程综合了文件系统结构(如EXT块组机制)和性能优化原则: ```mermaid graph TD A[新日志产生] --> B{日志类型判断} B -->|系统日志| C[写入/var/log分区] B -->|应用日志| D{日志级别检查} D -->|DEBUG/INFO| E[写入本地SSD缓存] D -->|WARN/ERROR| F{网络状态检测} F -->|网络正常| G[同步写入远程ES集群] F -->|网络异常| H[暂存本地队列] H --> I{定时重试机制} I -->|成功| G I -->|失败| J[转存备份磁] C --> K[触发日志轮转] E --> K J --> K K --> L{存储空间检查} L -->|空间充足| M[保留日志块] L -->|空间不足| N[按LRU策略清理] M --> O[更新块位图] N --> O O --> P[结束] ``` ### 流程关键点说明 1. **存储位置决策树**(基于引用[3]的EXT块组结构优化): - 系统日志直接写入`/var/log`分区(固定块组) - 低级别日志利用SSD缓存(减少$查找时间$,引用[2]) - 关键错误日志优先同步远程存储(确保可追溯性) 2. **性能优化机制**: - 网络异常时启用本地队列+重试(避免阻塞主线程) - 采用$LRU$(最近最少使用)清理策略(最小化磁$seek\ time$,引用[2]) - 日志轮转时批量更新块位图(减少$inode$表操作) 3. **存储结构映射**: ```plaintext | 存储位置 | 对应EXT结构 | 性能特征 | |----------------|-------------------|-------------------| | SSD缓存 | 块组0的超快区 | <5ms写入延迟 | | /var/log分区 | 常规数据块组 | 10-50ms写入 | | 备份磁 | 高冗余块组 | 高可靠但速度 | ``` ### 跨系统协作示意 流程图设计遵循引用[1]的规范: > 流程图作为图形化表达方式,能跨越语言和专业背景差异,使不同领域成员在同一界面理解工作流程和任务依赖关系[^1]。 该设计已在资源路径`resources/processes/log_storage.bpmn20.xml`实现(引用[4]),可通过BPMN工具直接部署。 --- ### 相关问题 1. 如何优化日志存储的磁IO性能? 2. 分布式系统中日志存储位置选择策略有哪些? 3. EXT文件系统的块位图机制如何影响日志存储效率? [^1]: 流程图在跨部门协作中能跨越语言和专业差异,统一工作流程理解 [^2]: 磁IO最耗时的部分是查找时间(seek time),需重点优化 [^3]: EXT文件系统采用块组结构,包含数据块位图/inode表等关键组件 [^4]: BPMN流程定义文件可放置在resources/processes目录自动加载
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值