📣 极限科技诚招搜索运维工程师(Elasticsearch/Easysearch)- 全职/北京 👉 : 立即申请加入

配置项作用 #

monitor.fs.health.slow_path_logging_threshold 配置项用于控制文件系统健康检查操作超过多少时间会被记录为慢路径警告日志

当文件系统健康检查操作(创建临时文件、写入数据、fsync 同步、删除文件)的执行时间超过此阈值时,系统会记录一条警告日志,提示某个数据路径的 IO 性能可能存在问题。

配置项属性 #

  • 配置路径: monitor.fs.health.slow_path_logging_threshold
  • 数据类型: TimeValue(时间值)
  • 默认值: 5s(5秒)
  • 最小值: 1ms(1毫秒)
  • 最大值: 无明确限制
  • 是否可选: 是
  • 作用域: NodeScope(节点级别)
  • 动态更新: 是(支持动态更新)

配置项详解 #

工作机制 #

慢路径检测流程

每次健康检查:
├── 记录开始时间 (executionStartTime)
├── 执行检查操作
│   ├── 创建临时文件
│   ├── 写入 UUID 数据
│   ├── fsync 同步
│   └── 删除临时文件
├── 记录结束时间
├── 计算耗时: currentTimeMillis - executionStartTime
└── 判断是否记录日志


耗时判断:
elapsedTime > slow_path_logging_threshold?
    │
    ├──── 是 → 记录警告日志 ⚠️
    │         logger.warn("health check of [{}] took [{}ms] which is
    │         above the warn threshold of [{}]", path, elapsedTime, threshold)
    │
    └──── 否 → 不记录日志 ✅

慢路径日志示例 #

警告日志示例

slow_path_logging_threshold = 5s


正常情况 (耗时 100ms):
health check completed in 100ms
100ms < 5000ms
→ 不记录日志 ✅


慢路径情况 (耗时 8000ms):
health check of [/data/easysearch] took [8000ms] which is above the warn threshold of [5000ms]
→ 记录警告日志 ⚠️


极慢路径情况 (耗时 30000ms):
health check of [/mnt/nfs/easysearch] took [30000ms] which is above the warn threshold of [5000ms]
→ 记录警告日志 ⚠️

性能监控作用 #

慢路径检测的价值

1. 性能问题预警
   ├── 发现存储设备性能下降
   ├── 发现网络存储延迟
   └── 发现文件系统问题


2. 容量规划参考
   ├── 监控 IO 性能趋势
   ├── 评估存储压力
   └── 预测性能瓶颈


3. 故障排查依据
   ├── 记录性能问题发生时间
   ├── 关联其他日志分析
   └── 定位问题路径

配置建议 #

生产环境(默认) #

monitor:
  fs:
    health:
      slow_path_logging_threshold: 5s  # 默认值

建议: 保持默认值 5s。适用于大多数场景。

高性能存储 #

monitor:
  fs:
    health:
      slow_path_logging_threshold: 2s  # 降低阈值

建议: 设置为 1-2s。使用高性能存储时使用。

网络存储/慢速存储 #

monitor:
  fs:
    health:
      slow_path_logging_threshold: 15s  # 提高阈值

建议: 设置为 10-30s。使用网络存储或慢速存储时使用。

严格监控 #

monitor:
  fs:
    health:
      slow_path_logging_threshold: 1s  # 更严格阈值

建议: 设置为 500ms-1s。需要严格监控性能时使用。

代码示例 #

easysearch.yml 基础配置 #

monitor:
  fs:
    health:
      enabled: true
      slow_path_logging_threshold: 5s

高性能存储配置 #

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

网络存储配置 #

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

动态更新配置 #

PUT /_cluster/settings
{
  "transient": {
    "monitor.fs.health.slow_path_logging_threshold": "10s"
  }
}

相关配置 #

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

性能影响分析 #

threshold 设置优点缺点
500ms-1s捕获所有性能问题日志量大,误报多
2-3s及时发现性能下降可能有一些误报
5s(默认)平衡监控和噪音标准设置
10-30s减少误报可能漏掉问题

日志量对比 #

不同阈值的日志量

假设健康检查平均耗时 100ms,偶尔有慢峰值

threshold = 1s:
├── 正常检查: 100ms < 1s → 不记录
├── 慢峰值: 1500ms > 1s → 记录 ⚠️
├── 偶发延迟: 1200ms > 1s → 记录 ⚠️
└── 日志量: 中等


threshold = 5s (默认):
├── 正常检查: 100ms < 5s → 不记录
├── 慢峰值: 1500ms < 5s → 不记录
├── 严重延迟: 8000ms > 5s → 记录 ⚠️
└── 日志量: 少 ✅


threshold = 10s:
├── 正常检查: 100ms < 10s → 不记录
├── 慢峰值: 8000ms < 10s → 不记录
├── 极端延迟: 15000ms > 10s → 记录 ⚠️
└── 日志量: 很少

使用场景 #

推荐使用默认值的场景 #

  • 标准存储: 使用本地硬盘或标准存储
  • 稳定环境: 存储性能稳定
  • 平衡需求: 平衡监控敏感度和日志量

推荐降低阈值的场景 #

  • 高性能存储: 使用 SSD 或高性能存储
  • 性能敏感: 对存储性能敏感
  • 严格监控: 需要捕获所有性能问题
  • 容量充足: 日志存储空间充足

推荐提高阈值的场景 #

  • 网络存储: 使用 NFS、CIFS 等网络存储
  • 高负载环境: 存储经常高负载
  • 接受延迟: 可以接受偶尔的慢 IO
  • 减少噪音: 减少误报日志

常见慢路径原因 #

慢路径的常见原因

1. 存储设备问题
   ├── 硬盘故障/老化
   ├── RAID 重建
   └── 存储控制器问题


2. 网络存储问题
   ├── 网络延迟
   ├── 带宽不足
   ├── NFS 服务端负载
   └── 网络不稳定


3. 系统负载
   ├── IO 竞争
   ├── CPU 资源不足
   ├── 内存压力
   └── 进程竞争


4. 文件系统问题
   ├── 文件系统损坏
   ├── inode 耗尽
   ├── 磁盘空间不足
   └── 文件系统碎片化

故障排查流程 #

慢路径日志处理

1. 发现慢路径日志
   health check of [/data] took [8000ms] which is above the warn threshold of [5000ms]
   │
   ↓
2. 确认慢路径
   检查 /data 路径的存储状态
   │
   ↓
3. 分析原因
   ├── 检查磁盘健康 (smartctl)
   ├── 检查 IO 状态 (iostat)
   ├── 检查系统负载 (top, iotop)
   └── 检查网络状态 (网络存储)
   │
   ↓
4. 解决问题
   ├── 更换故障硬盘
   ├── 优化网络配置
   ├── 降低负载
   └── 升级存储设备

注意事项 #

  1. 默认值: 默认值为 5s,适用于大多数场景。

  2. 动态更新: 支持动态更新,修改后立即生效。

  3. 仅记录日志: 此配置只影响日志记录,不影响功能。

  4. 继续执行: 超时后仍然会继续执行健康检查。

  5. 与间隔配合: 应与 refresh_interval 配合考虑。

  6. 日志量: 阈值越低,日志量越大。

  7. 误报风险: 过低阈值可能导致过多误报。

  8. 监控建议: 配合其他监控工具分析慢 IO。

  9. 测试验证: 配置变更后应观察日志量。

  10. 问题跟踪: 发现慢路径应及时处理。

测试验证 #

测试用例: testLoggingOnHungIO

测试内容:
1. 设置不同的阈值
2. 模拟不同的 IO 延迟
3. 验证日志记录逻辑


测试场景:
├── threshold = 5s, latency = 3s → 不记录 ✅
├── threshold = 5s, latency = 8s → 记录 ⚠️
├── threshold = 2s, latency = 3s → 记录 ⚠️
└── threshold = 10s, latency = 8s → 不记录 ✅