先说结论
时间序列数据可通过 ILM 按条件 rollover，并在 hot、warm、cold、frozen 等阶段迁移到不同性能和成本的节点，逐步执行只读、压缩、降低副本或可搜索快照，最后按保留策略删除。
生命周期设计目标是让热数据满足写入和查询 SLO，同时让历史数据用更低成本保存，并保证迁移和恢复可控。
Rollover 设计
按主分片大小、文档数和年龄的组合触发，比分别每天建索引更能应对流量波动。数据流和索引模板统一映射、分片与 ILM 策略，避免每批索引配置漂移。
一条时间序列数据流的生命周期
写入 alias/data stream
↓ rollover（大小/年龄/文档数）
hot：高写入、高副本、快速查询
↓
warm：只读、可 merge、较低成本
↓
cold/frozen：低频访问、快照/可搜索快照
↓
delete：超过保留期后删除
rollover 以实际主分片大小和写入速度触发，避免“流量低时每天一个小索引、流量高时一天一个巨型索引”。别名或 data stream 让应用不需要感知当前具体索引名。
ILM 阶段的工程动作
hot 阶段关注写入吞吐、refresh、分片和副本；warm 阶段可以转只读、降低副本、force merge，但必须有磁盘和查询验证；cold/frozen 阶段依赖快照仓库、恢复速度和查询预算；delete 阶段要满足合规保留和备份策略。
每次迁移都可能触发 segment merge、文件复制和 cluster state 更新。节点标签、分配规则、磁盘水位或快照仓库故障会让策略停在某阶段，不能只看策略配置“已启用”就认为数据已移动。
快照与可恢复性
副本解决在线节点故障，不解决误删、错误更新、集群级损坏或勒索。历史索引进入 cold 前应有可验证快照，定期执行恢复演练并测量 RTO。快照仓库、权限、加密和跨区域复制也属于生命周期设计的一部分。
查询成本治理
数据层级降低单位存储成本，但全时间范围搜索仍会扇出所有索引和层级。应用应要求时间范围、默认只查 hot/warm，历史导出走异步任务；聚合和 dashboard 要限制 bucket 数、并发和超时。
Mapping 与模板版本
新索引必须由统一模板创建，避免一个月份的字段是 keyword、下一个月份变成 text。模板变更需要版本化、测试和滚动验证；字段类型一旦写入不可直接修改，通常通过新索引 reindex。动态 mapping 无限制扩张会增大 cluster state 和 fielddata/heap 风险。
监控生命周期
按阶段监控索引年龄、主分片大小、文档增长、ILM step error、分配失败、磁盘水位、快照成功率、查询分层分布和删除延迟。策略失败应自动告警并保留可重试状态，不能静默让热层无限增长。
分层治理
迁移前确认目标层磁盘、快照仓库和查询延迟可接受。历史索引可降低副本或 force merge，但操作应在只读和低峰期执行；删除前确认合规与恢复要求。
容易踩坑的地方
冷热分层不是简单按节点标签搬数据，查询仍可能跨全部历史层扇出。若业务默认搜索全时间范围，再便宜的冷节点也可能频繁被打满，应同时限制查询时间窗口。
常见问题
追问：为什么只按天建索引可能不好？
流量高低会让每日分片大小差异巨大，产生过大或大量小分片；rollover 按实际容量触发，分片规模更稳定。
追问：warm 阶段为什么常设为只读？
只读后可以安全做 merge、降低副本或迁移层级，避免持续写入与数据移动相互竞争。若业务仍需更新，就要重新评估生命周期和一致性成本。
追问：删除旧索引前为什么还要快照？
删除是破坏性操作，副本无法恢复误删和错误写入。可验证快照提供独立恢复来源，还应明确保留周期和恢复时间。
追问：ILM 一直卡在某个 step 怎么办？
查看 step error、节点分配解释、磁盘水位、快照和权限；修复原因后重试 step。不要直接删除策略或强制删除索引掩盖数据未按期迁移。