文件系统健康检查间隔配置

配置项作用 #

monitor.fs.health.refresh_interval 配置项用于控制文件系统健康检查的刷新间隔时间。

FsHealthService 会按照此间隔定期检查文件系统的健康状况，通过在每个数据路径上创建临时文件来验证文件系统的写入能力。

配置项属性 #

配置路径: monitor.fs.health.refresh_interval
数据类型: TimeValue（时间值）
默认值: 120s（120秒，2分钟）
最小值: 1ms（1毫秒）
最大值: 无明确限制
是否可选: 是
作用域: NodeScope（节点级别）
动态更新: 否（需要重启节点生效）

配置项详解 #

工作机制 #

定时健康检查

scheduleWithFixedDelay 策略:

上次检查完成
    │
    ↓ 等待 refresh_interval
    │
    ↓
触发本次检查
    │
    ├── 创建临时文件
    ├── 写入数据
    ├── fsync 同步
    ├── 删除临时文件
    └── 记录结果
    │
    ↓ 检查完成
    ↓
等待 refresh_interval
    │
    ↓ (循环)


示例 (refresh_interval = 120s):

00:00 ──→ 检查 1 开始
00:00 ──→ 检查 1 完成 (耗时 5ms)
00:00 ──→ 等待 120s
02:00 ──→ 检查 2 开始
02:00 ──→ 检查 2 完成 (耗时 8ms)
02:00 ──→ 等待 120s
04:00 ──→ 检查 3 开始
...

检查操作详解 #

单次健康检查流程

1. 遍历所有数据路径
   │
   ├── path1: /data1/easysearch
   ├── path2: /data2/easysearch
   └── path3: /data3/easysearch


2. 对每个路径执行检查
   │
   ├── 创建: /data1/easysearch/.es_temp_file
   ├── 写入: UUID 数据
   ├── fsync: 确保写入磁盘
   ├── 删除: 临时文件
   └── 记录: 耗时


3. 判断健康状态
   │
   ├── 全部成功 → HEALTHY ✅
   ├── 部分失败 → UNHEALTHY ❌
   └── 记录失败路径


4. 慢路径检测
   │
   ├── 耗时 > threshold
   └── 记录警告日志

时间间隔选择 #

不同间隔的检查频率

refresh_interval = 30s:
├── 每小时检查: 120 次
├── 发现延迟: 最多 30 秒
├── IO 开销: 高
└── 适合: 高可用环境


refresh_interval = 120s (默认):
├── 每小时检查: 30 次
├── 发现延迟: 最多 2 分钟
├── IO 开销: 低 ✅
└── 适合: 生产环境


refresh_interval = 600s (10 分钟):
├── 每小时检查: 6 次
├── 发现延迟: 最多 10 分钟
├── IO 开销: 很低
└── 适合: 低频监控


refresh_interval = 3600s (1 小时):
├── 每小时检查: 1 次
├── 发现延迟: 最多 1 小时
├── IO 开销: 极低
└── 适合: 长期监控

配置建议 #

生产环境（默认） #

monitor:
  fs:
    health:
      refresh_interval: 120s  # 默认值

建议: 保持默认值 120s。平衡监控频率和性能。

高可用环境 #

monitor:
  fs:
    health:
      refresh_interval: 30s  # 更频繁检查

建议: 设置为 30-60s。需要快速发现问题时使用。

低频监控 #

monitor:
  fs:
    health:
      refresh_interval: 600s  # 10 分钟

建议: 设置为 600-1800s。降低检查频率时使用。

高性能存储 #

monitor:
  fs:
    health:
      refresh_interval: 60s
      slow_path_logging_threshold: 2s

建议: 降低间隔，同时调整慢路径阈值。

代码示例 #

easysearch.yml 基础配置 #

monitor:
  fs:
    health:
      enabled: true
      refresh_interval: 120s

高可用配置 #

monitor:
  fs:
    health:
      enabled: true
      refresh_interval: 30s
      slow_path_logging_threshold: 3s

低频监控配置 #

monitor:
  fs:
    health:
      enabled: true
      refresh_interval: 10m
      slow_path_logging_threshold: 10s

禁用健康检查 #

monitor:
  fs:
    health:
      enabled: false

配置项	作用	默认值
`monitor.fs.health.enabled`	是否启用健康检查	true
`monitor.fs.health.refresh_interval`	检查间隔	120s
`monitor.fs.health.slow_path_logging_threshold`	慢路径日志阈值	5s

性能影响分析 #

refresh_interval 设置	优点	缺点
30s	快速发现问题	IO 开销较高
60s	较快发现问题	IO 开销适中
120s（默认）	平衡频率和开销	标准设置
600s	低 IO 开销	发现延迟大

IO 开销对比 #

假设每次检查耗时 10ms

refresh_interval = 30s:
每小时检查: 3600 / 30 = 120 次
每小时开销: 120 × 10ms = 1.2 秒
占用率: 1.2 / 3600 = 0.033% ✅


refresh_interval = 120s (默认):
每小时检查: 3600 / 120 = 30 次
每小时开销: 30 × 10ms = 0.3 秒
占用率: 0.3 / 3600 = 0.008% ✅


refresh_interval = 600s:
每小时检查: 3600 / 600 = 6 次
每小时开销: 6 × 10ms = 0.06 秒
占用率: 0.06 / 3600 = 0.002% ✅

使用场景 #

与其他配置的配合 #

配置组合建议

高可用配置:
enabled: true
refresh_interval: 30s
slow_path_logging_threshold: 2s
└── 快速发现，严格监控


标准配置:
enabled: true
refresh_interval: 120s
slow_path_logging_threshold: 5s
└── 平衡设置


低频配置:
enabled: true
refresh_interval: 600s
slow_path_logging_threshold: 10s
└── 降低开销，长期监控


禁用配置:
enabled: false
└── 完全禁用

发现延迟分析 #

故障发现延迟

refresh_interval = 30s:
故障发生在: 00:00
下次检查: 00:00 ~ 00:30
发现延迟: 最多 30 秒 ✅


refresh_interval = 120s (默认):
故障发生在: 00:00
下次检查: 00:00 ~ 02:00
发现延迟: 最多 2 分钟


refresh_interval = 600s:
故障发生在: 00:00
下次检查: 00:00 ~ 10:00
发现延迟: 最多 10 分钟 ❌

注意事项 #

默认值: 默认值为 120s，适用于大多数场景。
需要重启: 修改此配置需要重启节点。
固定延迟: 使用 scheduleWithFixedDelay 策略。
与阈值配合: 应与 slow_path_logging_threshold 配合。
IO 开销: 检查频率越高，IO 开销越大。
发现延迟: 检查间隔越长，故障发现延迟越大。
时间单位: 支持秒、分钟等单位。
最小值: 最小值为 1ms，不建议设置过小。
监控建议: 监控检查耗时和失败率。
测试验证: 配置变更后应验证检查效果。

定时任务实现 #

定时任务技术细节

线程池: ThreadPool.Names.GENERIC

调度方式:
threadPool.scheduleWithFixedDelay(
    new FsHealthMonitor(),
    refreshInterval,
    ThreadPool.Names.GENERIC
)


FixedDelay 特点:
├── 上次任务完成后开始计时
├── 等待 refresh_interval
├── 执行下一次任务
└── 不会并发执行


与 FixedRate 对比:

FixedDelay (当前使用):
├── 任务完成后计时
├── 不受任务执行时间影响
└── 实际间隔 = refresh_interval + 执行时间


FixedRate:
├── 固定频率执行
├── 可能并发
└── 不适合健康检查

标签

监控文件系统健康检查定时任务