面试考察点
- 是否根据访问频率和保留周期划分数据阶段。
- 能否用 rollover 稳定分片大小而非只按固定日期切分。
- 是否理解迁移、只读、删除和快照的顺序。
核心答案
时间序列数据可通过 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。不要直接删除策略或强制删除索引掩盖数据未按期迁移。
总结
ILM 把容量、性能和保留策略变成自动化阶段流转，设计时要同时控制分片规模、查询范围和可恢复性。
机制全景图
下面把「Elasticsearch 索引生命周期和冷热分层怎么设计？」从输入到结果压缩成一条可复述的主链路。面试时先用图建立全局坐标，再进入局部实现，能避免只背零散结论。
flowchart LR
A["写入当前 write index"]
A --> B["按大小/时间 rollover"]
B --> C["迁移 warm/cold tier"]
C --> D["只读压缩与降副本"]
D --> E["过期删除并更新 alias"]
完整链路：从输入到结果
沿着「写入当前 write index → 按大小/时间 rollover → 迁移 warm/cold tier → 只读压缩与降副本 → 过期删除并更新 alias」观察输入、状态与输出，下面每个阶段都对应一个可以在源码、日志或系统表中验证的位置。
1. 写入当前 write index
Data Stream 或 alias 把写入路由到当前 backing index，模板保证新索引 Mapping 和设置一致。
2. 按大小/时间 rollover
rollover 依据 max_primary_shard_size、age 或 docs 创建新索引，按大小通常比固定按天更稳定。
3. 迁移 warm/cold tier
历史索引迁移到不同数据层，节点角色、磁盘和分配规则决定实际移动。
4. 只读压缩与降副本
只读后可 force merge、shrink 或减少副本，但这些操作 I/O 重，需错峰和容量预算。
5. 过期删除并更新 alias
delete 阶段按保留期删除整个索引，失败步骤会重试，策略与执行状态必须持续监控。
源码与实现定位
| 入口 | 阅读重点 |
|---|---|
| _ilm/explain | 当前 phase/action/step |
| _cat/indices/_cat/shards | 滚动后的大小 |
源码或系统表应按上表顺序追踪：先确认入口实际走到哪条路径，再用运行时数据验证，而不是仅凭类名或配置推测。
参数配置与可复现实验
PUT _ilm/policy/logs
{"policy":{"phases":{"hot":{"actions":{"rollover":{"max_primary_shard_size":"40gb"}}},"delete":{"min_age":"30d","actions":{"delete":{}}}}}}
加速时间演练 rollover→warm→delete，故意破坏 alias 验证告警。
验证步骤与预期结果
1. 固定输入和基线
先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「ILM failed step」为主基线，记录值应满足「记录稳态基线」；同时保存 ILM step/失败数、主分片大小，使后续变化能够回到同一时间轴比较。
2. 从实现入口确认路径
在「_ilm/explain」确认请求确实进入「当前 phase/action/step」对应的实现，再沿「_cat/indices/_cat/shards」观察「滚动后的大小」。如果入口路径都未命中，就不应继续调整下游参数，而应先检查调用条件、版本或路由是否与假设一致。
3. 注入本文特有的失败模式
优先复现「只按天滚动产生大小悬殊分片」，并把单一变量逐级放大，直到「ILM failed step」越过「超过基线2倍」。随后再分别验证「force merge 与线上写查询争资源」和「策略卡住没有告警」，三类故障分开执行，避免多个变量同时变化而无法归因。
4. 执行止损和根因修复
第一轮只应用「按大小滚动」，确认它能控制影响范围；第二轮应用「对卡住 step 告警」，验证核心链路恢复；最后落实「force merge 错峰限并发」，消除同类问题再次出现的条件。每一步都保留变更前后数据，不用“感觉变快了”替代测量。
5. 通过退出条件
实验只有同时满足三项才算通过：「ILM failed step」回到「记录稳态基线」、「P99」回到「小于业务预算」、「结果差异」回到「0」，并且业务结果差异为零。若性能恢复但结果不一致，仍应视为失败；若指标恢复后很快再次越线，则说明只完成了临时止损，没有消除根因。
量化基线
| 指标 | 样例基线/口径 | 风险线 | 结论 |
|---|---|---|---|
| ILM failed step | 记录稳态基线 | 超过基线2倍 | 按实现入口定位 |
| P99 | 小于业务预算 | 突破预算 | 停止扩量 |
| 结果差异 | 0 | 任意非零 | 回滚并重建 |
这些数值是实验口径或示例告警线，不是可复制到所有系统的固定答案；上线阈值应由本系统稳态、峰值和故障演练共同确定。
事故复盘：ILM 配了删除策略但磁盘仍持续上涨
索引 alias 未设置 rollover_alias，策略卡在 rollover 步骤，后续删除从未执行。通过 _ilm/explain 定位阻塞原因、修复模板并手动重试后才恢复。
| 失败模式 | 首要证据 | 第一处置动作 |
|---|---|---|
| 只按天滚动产生大小悬殊分片 | ILM step/失败数 | 按大小滚动 |
| force merge 与线上写查询争资源 | 主分片大小 | 对卡住 step 告警 |
| 策略卡住没有告警 | 各 tier 磁盘水位 | force merge 错峰限并发 |
发布与回滚检查点
- 发布前：确认「_ilm/explain」对应实现和上述配置在目标版本仍然有效，并保存「ILM failed step」基线。
- 灰度中：同时观察 ILM step/失败数、主分片大小、各 tier 磁盘水位；任一指标越过表中风险线，就停止继续扩量。
- 回滚时：先执行「按大小滚动」控制影响，再回退代码或参数；涉及持久状态时必须额外核对结果差异。
- 发布后：至少覆盖一个完整峰值周期，确认「只按天滚动产生大小悬殊分片」没有再次出现，才关闭变更观察窗口。
方案对比与选型
| 方案 | 更适合的场景 | 主要收益 | 代价与边界 |
|---|---|---|---|
| Data Stream + ILM | 追加型日志和指标 | 滚动与隐藏 backing index 集成 | 不适合任意原地更新模型 |
| Alias + ILM | 需要自定义索引和更新 | 灵活 | 模板、write alias 配置更易出错 |
| 手工定时管理 | 极少索引或特殊流程 | 完全可控 | 容易遗漏失败、无状态机重试 |
选型至少带上 文档规模、分片数、字段基数、查询并发和写入速率，并用上面的量化基线验证；未知数据应明确为待测假设。
设计边界与工程取舍
生命周期策略必须同时满足保留、分片大小、节点容量和恢复时间；配置策略不等于执行成功，需要对卡住步骤告警。
工程落地遵循：先设计 Mapping 与分片，再优化查询；任何调优都要控制扫描与内存放大。回答时直接引用「_ilm/explain」、配置实验和事故数据，比复述固定模板更有说服力。