我不会直接画架构图，会先确认目标、规模和一致性要求。使用 rollover、ILM、数据层级和快照管理时间序列数据成本。时间序列数据可通过 ILM 按条件 rollover，并在 hot、warm、cold、frozen 等阶段迁移到不同性能和成本的节点，逐步执行只读、压缩、降低副本或可搜索快照，最后按保留策略删除。 生命周期设计目标是让热数据满足写入和查询 SLO，同时让历史数据用更低成本保存，并保证迁移和恢复可控。

容量有了以后，再把入口、核心处理和数据落点串起来。沿着「写入当前 write index → 按大小/时间 rollover → 迁移 warm/cold tier → 只读压缩与降副本 → 过期删除并更新 alias」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 写入当前 write index Data Stream 或 alias 把写入路由到当前 backing index，模板保证新索引 Mapping 和设置一致。 ilm/explain：当前 phase/action/step。 cat/indices/cat/shards：滚动后的大小。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

关键参数要从峰值流量和资源上限反推。加速时间演练 rollover→warm→delete，故意破坏 alias 验证告警。

正常链路之外，还要设计失败补偿和可验证的恢复流程。索引 alias 未设置 rolloveralias，策略卡在 rollover 步骤，后续删除从未执行。通过 ilm/explain 定位阻塞原因、修复模板并手动重试后才恢复。 只按天滚动产生大小悬殊分片：ILM step/失败数：按大小滚动。 force merge 与线上写查询争资源：主分片大小：对卡住 step 告警。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「ILM failed step」为主基线，记录值应满足「记录稳态基线」；同时保存 ILM step/失败数、主分片大小，使后续变化能够回到同一时间轴比较。

最后再讲扩容、成本和方案边界。方案：更适合的场景：主要收益：代价与边界。 Data Stream + ILM：追加型日志和指标：滚动与隐藏 backing index 集成：不适合任意原地更新模型。 Alias + ILM：需要自定义索引和更新：灵活：模板、write alias 配置更易出错。 手工定时管理：极少索引或特殊流程：完全可控：容易遗漏失败、无状态机重试。