索引存在时间（lifecycle_date）的基准取决于是否配置了 rollover ：若未使用 rollover，则从索引创建时间开始计算；若使用了 rollover，则从 rollover 时间开始计算。各阶段的 min_age 均相对于该基准时间累加。
📌 核心计算规则
- 未使用 rollover ：
min_age从索引的创建时间开始计算。 - 使用了 rollover ：
min_age从索引发生 rollover 的时间开始计算（因为 rollover 后会生成新索引，新索引的创建时间即为计算基准）。 - 阶段过渡条件：在进入下一阶段前，当前阶段的所有 action 必须执行完成。
- min_age 递增 ：各阶段的
min_age必须逐级递增。
📐 计算示例
假设策略配置为：hot 阶段 30 天 rollover，warm 阶段 min_age: 7d，delete 阶段 min_age: 365d。
- 未使用 rollover：索引创建后 365 天被删除。
- 使用 rollover ：索引 rollover 后 365 天被删除。若索引在创建后第 30 天 rollover，则实际存在时间最长可达 30 + 365 = 395 天。
🔧 特殊配置：自定义时间基准
若索引包含历史数据，可通过以下设置覆盖默认计算基准：
index.lifecycle.origination_date：指定 Unix 时间戳作为计算索引年龄的起始时间。index.lifecycle.parse_origination_date：设为true时，ES 会从索引名中解析日期（需匹配yyyy.MM.dd格式，如logs-2016.10.31-000002）作为起始时间。
🔍 查看与调试
- 查看索引年龄与阶段 ：
GET /<index>/_ilm/explain，关注lifecycle_date、age、phase等字段。 - 调整轮询频率 ：ILM 默认每 10 分钟 检查一次索引是否满足阶段转换条件，可通过
indices.lifecycle.poll_interval调整。
IML示例
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"rollover": {
"max_age": "10d",
"max_size": "25gb"
},
"set_priority": {
"priority": 100
}
}
},
"warm": {
"min_age": "10d",
"actions": {
"set_priority": {
"priority": 20
},
"shrink": {
"number_of_shards": 1
}
}
},
"delete": {
"min_age": "30d",
"actions": {
"delete": {}
}
}
}
}
}针对这个新策略，我们套用之前推导出的通用公式：
物理最大保存天数 = 实际触发滚动的天数 + MAX(warm.min_age, delete.min_age)
代入数值：
-
实际触发滚动的天数：由
max_age: 10d或max_size: 25gb决定，取先达到者。最坏情况（25GB 一直没写满）下，滚动发生在 第 10 天。 -
MAX(warm.min_age, delete.min_age)=MAX(10d, 30d)= 30 天。
结论：索引最大物理存活天数为 10 + 30 = 40 天。
时间线拆解（最坏情况：25GB 一直未写满）
| 天数 | 事件 | 说明 |
|---|---|---|
| 第 0 天 | 索引创建，开始写入 | - |
| 第 10 天 | 达到 max_age: 10d，发生滚动 |
旧索引 lifecycle_date 重置为第 10 天，Warm 和 Delete 的倒计时同时开始 |
| 第 20 天 | 达到 warm.min_age: 10d（从第 10 天算起） |
索引进入 Warm 阶段，执行 shrink（收缩为 1 个分片） |
| 第 40 天 | 达到 delete.min_age: 30d（从第 10 天算起） |
索引进入 Delete 阶段，立即物理删除 |
如果提前写满 25GB，会怎样？
如果索引在 第 5 天 就写满了 25GB，那么滚动会提前在第 5 天发生。此时：
- 物理存活天数 = 5 天（滚动）+ 30 天（删除缓冲）= 35 天。
所以，40 天是"最大"值，实际可能因写满磁盘而缩短。