ISM 历史索引滚动检查周期配置

配置项作用 #

index_state_management.history.rollover_check_period 配置项用于控制ISM 历史索引执行滚动和过期清理操作的检查周期。

系统会按照此配置的周期定期检查历史索引是否需要滚动（满足 max_docs 或 max_age 条件），以及是否有过期索引需要删除。

配置项属性 #

配置路径: index_state_management.history.rollover_check_period
数据类型: TimeValue（时间值）
默认值: 8h（8小时）
最小值: > 0（正数）
是否可选: 是
作用域: NodeScope（节点级别）
动态更新: 是（支持动态更新）

配置项详解 #

工作机制 #

滚动检查调度流程

调度器启动
    │
    ↓
等待 rollover_check_period (8h)
    │
    ↓
执行检查任务
    │
    ├──────── 检查滚动条件
    │              │
    │         ├─── max_docs 达到？
    │         │         ↓
    │         │    是 ──→ 触发滚动
    │         │
    │         └─── max_age 达到？
    │                   ↓
    │              是 ──→ 触发滚动
    │
    └──────── 检查过期索引
                   │
              └─── 超过 retention_period？
                        ↓
                     是 ──→ 删除索引

检查周期影响 #

不同检查周期的影响

rollover_check_period = 1h:

0h ────→ 1h ────→ 2h ────→ 3h ────→ 4h
│        │         │         │         │
检查    检查     检查     检查     检查
优点: 快速响应条件变化
缺点: 频繁调度，系统开销较高


rollover_check_period = 8h (默认):

0h ────→ 8h ────→ 16h ────→ 24h ────→ 32h
│        │          │          │          │
检查    检查      检查      检查      检查
优点: 平衡响应和开销
缺点: 滚动可能有最多 8h 延迟


rollover_check_period = 24h:

0h ──────────→ 24h ──────────→ 48h
│              │                │
检查          检查             检查
优点: 最小系统开销
缺点: 滚动延迟最多 24h

实际滚动时间 #

滚动时间的实际范围

max_age = 24h
rollover_check_period = 8h

最早滚动时间:
24h (条件满足时立即触发)

最晚滚动时间:
24h + 8h = 32h (下次检查时)

实际滚动时间: 24h - 32h 之间

配置建议 #

生产环境（默认） #

index_state_management:
  history:
    rollover_check_period: 8h  # 默认值

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

高频操作环境 #

index_state_management:
  history:
    rollover_check_period: 2h  # 2 小时

建议: 减少到 2-4h。ISM 操作非常频繁时使用。

低频操作环境 #

index_state_management:
  history:
    rollover_check_period: 24h  # 1 天

建议: 增加到 12-24h。ISM 操作不频繁时使用。

快速响应要求 #

index_state_management:
  history:
    rollover_check_period: 1h  # 1 小时

建议: 减少到 1-2h。需要快速响应滚动条件时使用。

代码示例 #

easysearch.yml 基础配置 #

index_state_management:
  history:
    rollover_check_period: 8h

配合其他历史配置 #

index_state_management:
  history:
    enabled: true
    max_docs: 2500000
    max_age: 24h
    rollover_check_period: 8h
    rollover_retention_period: 30d

快速检查配置 #

index_state_management:
  history:
    rollover_check_period: 2h
    max_age: 12h

动态更新配置 #

PUT /_cluster/settings
{
  "transient": {
    "index_state_management.history.rollover_check_period": "4h"
  }
}

配置项	作用	默认值
`index_state_management.history.enabled`	是否启用历史记录	true
`index_state_management.history.max_age`	历史索引最大年龄	24h
`index_state_management.history.max_docs`	历史索引最大文档数	2500000
`index_state_management.history.rollover_check_period`	滚动检查周期	8h
`index_state_management.history.rollover_retention_period`	历史索引保留期	30d

检查任务调度 #

调度器工作原理

调度启动:
├── 创建固定延迟调度任务
├── 延迟 = rollover_check_period
└── 执行器 = RolloverCheckTask

每次执行:
├── 检查当前历史索引状态
│   ├── 统计文档数
│   ├── 计算索引年龄
│   └── 评估滚动条件
├── 如需滚动则执行滚动操作
└── 如有过期索引则删除

重新调度:
└── 等待 rollover_check_period 后再次执行

使用场景 #

系统资源影响 #

不同检查周期的资源消耗

假设每次检查消耗 100ms CPU

rollover_check_period = 1h:
每天检查次数 = 24
CPU 消耗 = 24 × 100ms = 2.4s

rollover_check_period = 8h:
每天检查次数 = 3
CPU 消耗 = 3 × 100ms = 0.3s

rollover_check_period = 24h:
每天检查次数 = 1
CPU 消耗 = 1 × 100ms = 0.1s

结论:
较长周期可以减少调度开销

配置调优指南 #

确定合适的检查周期 #

步骤 1: 评估操作频率

每小时产生多少条历史记录？
高频: > 10000 条/小时
中频: 1000-10000 条/小时
低频: < 1000 条/小时


步骤 2: 评估滚动条件

max_docs 和 max_age 设置
预计多久触发滚动？


步骤 3: 确定响应要求

需要多快响应滚动条件？
快速响应: 缩短检查周期
正常响应: 使用默认周期
延迟可接受: 延长检查周期


步骤 4: 计算检查周期

检查周期 ≈ 预计滚动时间的 1/4 到 1/3

例如: 预计每天滚动
检查周期 = 24h / 4 = 6h


步骤 5: 测试验证

在实际环境中测试
监控滚动延迟
根据实际情况调整

注意事项 #

默认值: 默认值为 8h，适合大多数场景。
延迟影响: 滚动实际执行时间最多延迟一个检查周期。
系统开销: 更频繁的检查会增加系统开销。
动态更新: 支持动态更新，修改后立即生效。
与 max_age 配合: 检查周期应该小于 max_age 值。
与 max_docs 配合: 确保能及时响应文档数条件。
配置变更影响: 新的周期会在下次调度时生效。
集群管理节点: 检查任务只在管理节点上运行。
监控建议: 监控检查任务的执行时间和资源消耗。
时间单位: 支持多种时间单位（ms, s, m, h, d）。

标签

索引状态管理 ISM 历史记录滚动检查