ES 海量日志检索架构演进：
分片规划、冷热分离与聚合查询性能优化

1复合现场：聚合超时与分片失衡

上述场景折射出一个普遍误区：把 ES 日志集群可用性等同于「集群 green + 写入无拒绝」。 在海量日志场景里，分片 fan-out 与聚合 heap 才是查询 SLA 的交汇点： 每个搜索请求会被协调节点广播到所有目标分片，分片数越多，协调开销与 merge 结果集越大； ILM 阶段迁移会在同一时刻改变分片拓扑与磁盘 IO 曲线，与查询高峰形成时间竞争。 7.x 时代常用的「按天建 index + alias」在 8.x 仍可行，但官方推荐 Data Stream + ILM 一体化， rollover 语义与 TSDB 模式（8.7+）让「索引生命周期」与「查询窗口」绑定更紧—— 不理解这层绑定，容易在 green 集群里做出加剧查询恶化的运维动作。

doc values 是 agg 的物理基础：keyword、date、numeric 字段在 indexing 时构建 columnar 存储， text 字段默认不可 agg。现场常见 mapping 把 user_id 配成 text 并带 keyword sub-field， Dashboard 却误对 text 做 agg 导致内存爆炸或 fielddata 禁用错误。 8.x 动态 mapping 对 string 仍可能双字段，模板层应默认禁用 text 字段 agg，仅暴露 keyword 给 Kibana。

版本说明：本文默认 Elasticsearch 8.11+（Elastic Stack 8.x）， 节点角色采用 master / data_hot / data_warm / data_cold / coordinating 分离部署。 涉及 7.x 差异处会标注：例如 7.x 无内置 searchable snapshots 冷层默认集成、 Data Stream 需 7.9+、Frozen tier 在 7.12+ 才逐步成熟。 性能数字若无特别说明均为合成示例，机制与参数边界适用于 Elastic 8.x 官方文档描述的行为。

阅读前提：你已理解 inverted index、shard/replica、协调节点与 data 节点分工 （《Elasticsearch 权威指南》索引与搜索部分）。本文不再解释「什么是倒排索引」， 而是聚焦海量日志场景下分片规划、ILM 冷热分离与聚合优化如何协同、如何用架构手段规避复合超时。 全文 45% 篇幅用于体系架构（Data Stream、Tier、容量模型），35% 用于决策框架与检查表训练， 20% 留给问题现场与排障信号。目标读者为已在生产环境处理过 ES 查询超时或 ILM 迁移事故的 P6-P7+ 工程师。

与消息中间件容灾不同，ES 日志集群的「可用」往往是查询 SLA 分层： Trace 点查要求亚秒级，SRE 大盘可接受秒级，合规抽检可接受分钟级。 三类 SLA 混在同一 index pattern 上是 composite 场景的制度性根源。 架构评审应强制三类 workload 绑定不同 data view 或 Transform 输出，而非共用一个「全量 logs-*」面板。

合成示例对照：Trace 点查 trace.id:xxx 仅命中 1～2 shard，P99 800 ms； 同一 data stream 上 7 天 terms agg 扫 98 primary，P99 38 s—— 两者共存于 green 集群并不矛盾。值班口诀：慢的是 agg 还是 query？扫了多少 shard？ILM 是否在跑？ 三问答不全则不应提交扩容工单。

1.1 告警时间线：三类信号交织

复合查询恶化的识别特征是三类信号在同一时间窗重叠，而非单一慢查询。 下表按压测时间线整理（数字为合成示例，用于排障顺序训练）：

上表刻意把 ILM 列与查询列并列：许多 runbook 只写「写入失败怎么办」，忽略 ILM 阶段任务对 search thread pool 的间接占用。 shrink 与 forcemerge 使用 indices.admin 与 merge 线程，与 search 共享 disk IO queue； 在 NVMe 带宽打满时，search latency 上升但 indexing_rate 仍正常，极易误判为「纯查询问题」。 合成示例中 T+8 min 的 warm shrink 与 T+0 写入尖刺重叠，磁盘 queue depth 从 4 升至 19，是 agg P99 恶化的物理层证据之一。

1.2 与单次慢查询的边界区分

并非每次聚合变慢都需要集群扩容。值班分级有助于避免「盲目加 data 节点」或「盲目减分片」：

若仅满足左列特征，值班可在业务低峰改 DSL 或加 coordinating；若满足右列，必须升级架构师并冻结 ILM。 右列还有一个识别信号：同一 Dashboard 在 staging 集群（数据量小）正常，生产超时—— 说明 DSL 本身不是根因，fan-out 规模才是。staging 与生产 backing index 数量不一致时， 不应以 staging 压测结果签署大促通过书。

1.3 现场应急：有序恢复而非「加机器」

复合场景下，架构师在 war room 的第一职责是划定冻结变更窗口： 禁止在 peak 窗口执行 shrink/force merge、禁止缩短 refresh、禁止为 agg 临时关闭 replica。 恢复顺序应为：暂停非关键 ILM 阶段动作 → 确认 coordinating 节点 heap 与 breaker → 收窄 Dashboard 时间范围与索引模式 → 再讨论 data 节点扩容。 顺序颠倒，往往把一次可控压测变成需要 reindex 的生产事故。 7.x 环境中若仍使用 curator 删除旧 index，同样需要在 peak 窗口冻结 delete 任务—— 8.x ILM 只是把同一类风险内置进了集群调度器。

子工单拆分建议与 Kafka 容灾篇同构：A 线（ILM/拓扑）负责 _ilm/explain 与 suspend policy； B 线（查询）负责 Kibana 时间窗临时收窄、composite 替代 terms、关闭非关键 Dashboard； C 线（业务）负责风控规则降级与批次补偿。三线汇于：分片 fan-out 未降之前扩容 coordinating 只能买时间。 复盘时必须记录「active shards 峰值」「agg P99 峰值」「ILM 任务重叠分钟数」三字段，否则无法证明下次大促前该改 rollover 还是改 Dashboard。

还有一个易被忽略的细节：Logstash pipeline 在 peak 窗口若同步扩 worker， 会在 ES 侧表现为 bulk 批大小变小、请求数上升，协调节点连接数先于 data 节点 CPU 触顶。 业务方以为是「ES 扛不住写入」，实际是客户端并发模型与集群背压不匹配。 架构师应要求 ingest 侧先调 bulk 再调 ES refresh，而不是反过来。

Kibana 侧临时降级手段应与 ES 层动作并列写入 runbook：将 Lens 默认时间窗从 7 天改为 24 小时、 把 TSVB interval 从 1 分钟改为 5 分钟、对非关键 Dashboard 显示 maintenance 提示。 8.x unified search 对 data view 绑定多个 backing index 时，改 saved search 时间范围可立即减少 fan-out， 无需重启集群。7.x 需在 index pattern 层面临时去掉 cold index 别名，操作不同但目标一致。

业务方常要求「大促期间零日志丢失」与「大盘实时」同时满足——架构上应事前签字接受查询降级 SLA： 写入与点查保 hot，agg 允许 5～10 分钟延迟或读 Transform summary。未签字则 composite 场景必然在 peak 窗口爆发， 因为 ILM 与 refresh 没有任何魔法能在不增 shard 的前提下同时提升写入实时性与全局 agg 性能。

2海量日志集群架构演进（ES 8.x Data Stream）

日志集群的架构演进，本质是在写入吞吐、保留周期、查询模式三者之间找平衡点。 8.x 推荐路径是：Beats/Agent → Kafka（可选缓冲）→ Ingest Pipeline → Data Stream（logs-*-* 命名）→ ILM 驱动 backing index rollover → 按 Tier 下沉至 warm/cold/frozen。与 7.x「手工创建 logstash-2026.08.08」相比， Data Stream 把「追加写语义」与「生命周期策略」绑在模板层，减少 alias 误配导致的写入失败。

Elastic Common Schema（ECS）字段规范与 8.x Fleet integration 深度集成： 统一 service.name、error.code 等命名可跨数据源 agg。 若各业务线自行命名 svc、app、module 混用， Transform 与 Dashboard 需维护多套 mapping，fan-out 无法通过技术 alone 收敛—— 这是组织治理问题，但会在 ES 层表现为「同一概念多个 keyword 字段」。

节点角色上，8.x 官方鼓励专用 coordinating 节点承担 search fan-out， 避免 data 节点既做 indexing 又扛高并发 agg。hot tier 使用 SSD、较高 indexing_pressure 限额；cold tier 可挂载 searchable snapshot 或 replica=0 的 frozen 层。 7.x 集群常见「混合角色节点」在中小规模可行，但当 daily shard 数超过数百、 并发 Dashboard 超过数十块时，协调开销会先于磁盘打满——这正是第 1 章 composite 场景的架构背景。

2.1 逻辑拓扑：写入路径与查询路径分离

写入路径关心 segment flush、translog、refresh；查询路径关心 segment 数量、cache、 doc values 与 agg 桶合并。同一 backing index 上两者竞争 thread pool： write 与 search 在 data 节点上并行，但共享 page cache 与 disk IO。 架构上应让「重 agg 的 SRE 大盘」与「高 QPS 点查的 Trace 系统」尽量使用不同 index pattern 或 不同 replica 组，必要时为查询密集型 workload 配置 search replica（8.x 仍通过增加 replica 实现读扩展）。

物理拓扑上，hot data 节点与 coordinating 节点应分机架或分可用区，避免 coordinating OOM 触发 cascading failure。 master 节点仅承担 cluster state，不参与 search；7.x 小集群常把 master 与 data 混部， 当 active shards > 2000 时 master 更新 metadata 的 latency 会成为 hidden bottleneck。 8.x 支持 dedicated master + voting_only 节点，大规模日志集群应尽早拆分，而非等 master 选主超时再补救。

2.2 8.x 与 7.x 关键差异速查

上表用于迁移评审 checklist，不是版本优劣对比。7.x 生产集群若已稳定运行 daily index 模式， 不必为追新而强行切 Data Stream——迁移收益应量化 fan-out 降幅与 ILM 运维工时节省， 而非「8.x 更新所以迁」。若 daily primary 数已失控，迁移窗口是收敛分片的唯一低成本时机； 若分片健康，可仅升级版本保留 index 模式，待下次 retention 策略变更时再引入 Data Stream。

架构师在方案评审时应明确：Data Stream 不是免费午餐。 rollover 频率由 max_primary_shard_size 或 max_age 决定， 设置过 aggressive 会在 hot 层制造过多小分片，恶化 fan-out； 设置过 conservative 则单 shard 过大，recovery 与 merge 时间过长。 8.x 文档建议单 primary shard 目标体积 10～50 GB（日志型，合成示例区间）， 需结合 daily 数据量与 retention 反推。

多租户日志平台常见架构是「按业务域拆 Data Stream」：支付、订单、网关各一条 stream， 共享同一 hot tier 但 ILM delete 周期可不同。好处是某域流量尖刺不会拖垮全局 agg； 代价是 Kibana index pattern 需维护 logs-{domain}-* 多套，且 cross-domain 关联查询变贵。 7.x 用 alias 合并多 index 的做法在 8.x 可用 data_view 替代，但 fan-out 仍是各 backing index 之和—— 合并视图不合并分片开销。

ingest pipeline 层建议统一 trace.id、service.name 为 keyword， 避免 text 字段参与 agg；message 正文可 index: false 仅 store 供点查。 8.x 的 ignore_above 与 dynamic mapping 默认更保守，但仍需在模板层显式关闭 动态字符串字段的 doc_values，否则高基数 agg 会在 mapping 看似正确时仍 OOM。

TSDB mode（8.7+）通过 index.mode: time_series 与 dimension 排序降低 metrics 存储与 agg 成本， 适合 nginx QPS、JVM gc 次数等高频率数值指标，不适合全文 message 检索。 混合部署时常见架构是：文本日志走标准 Data Stream，metrics 子集走 TSDB data stream，Kibana 用不同 data view 组合面板。 7.x 无 TSDB，metrics 与 logs 混在同一 index 是 fan-out 与 mapping 冲突的常见来源。

3分片规划与容量估算

分片数是 ES 日志架构里创建时最难逆转的参数之一。 primary shard 数量在 index 创建后只能 shrink（有条件）或 reindex 变更； 复合场景里 active shards 飙升，往往源于「初始 primary 过多 + rollover 过频 + ILM shrink 未及时执行」的叠加。 容量规划的核心不是「节点能存多少 TB」，而是每个查询要扫多少分片、每个分片承载多少 segment。

3.1 分片数估算公式（框架）

对 daily 28 TB（合成示例）的日志流，若目标单 primary shard 30 GB、副本数 1， 则 daily primary 约 933 个——这显然过高。正确方向是放大 rollover 粒度： 例如 max_primary_shard_size: 50gb 且 max_age: 1d 取先触达者， 使 daily backing index 仅 4～6 个 primary（合成示例）， 全集群 active primary 控制在「每 TB 数据 20～40 个 primary」的经验区间内（生产经验，非官方硬指标）。 7.x 时代「每 index 5 primary」若叠加 365 天 retention 且未 delete，会在一年内积累 1,825 个 primary—— 任何跨 30 天以上的 agg 都会变成灾难。

Elastic 官方「Size your shards」指南强调：分片是 Lucene 索引的容器，过多分片增加 heap 与 coordination 开销， 过少分片导致单 shard 过大、recovery 慢。日志型 workload 还受segment 合并策略影响： 高写入使 segment 数快增，查询需遍历更多 segment 即使 doc 数不变。 因此分片规划必须与 refresh、merge 策略联合评审，不能只看磁盘 TB 数。

3.2 容量估算输入表

输出侧应文档化三类硬指标：集群 active shards 上限（例如 < 3,000，合成示例）、 单次查询命中 backing index 数上限（通过 Kibana 时间 picker 与 ILM delete 对齐）、 单 coordinating 节点 heap 中 agg 占比（通过 slow log 与 profile 抽样）。 7.x 用户若仍维护 _cat/indices?v&bytes=b 手工表格，建议迁移到 Elastic Agent + Stack Monitoring， 否则容量评审缺乏历史趋势，容易在大促前误判 headroom。

3.3 Worked example：从日增量反推 primary 数

假设合成场景：日增 28 TB 原始 JSON，best_compression 后约 7 TB/天落盘； 目标单 primary 40 GB，则 daily 需要约 175 个 primary——仍然过高。 正确做法是提高单 backing index 承载天数或增大 rollover 阈值： 若 max_age: 3d 且 shard 体积上限 120 GB，则 3 天 21 TB 压缩数据约需 175 primary 分摊到 3 个 backing index， 每个 backing 约 58 primary——依旧偏高。架构上应继续合并至「每 backing ≤ 6 primary」， 即约 12 天一个 backing index（合成示例），ILM hot 阶段 7 天内仅 1～2 个 backing 参与查询。 这一算术题应在立项时用 spreadsheet 算清，而非上线后靠 shrink 补救。

replica 数也影响 active shards：hot 层 replica=1 使 shard 数翻倍，但提供读扩展与 HA； cold 层 replica=0 可减半 shard 开销，但查询只能命中 primary。 7.x 关闭 replica 的 closed index 不参与 search；8.x cold tier 用 searchable snapshot 时 replica 语义不同—— 迁移时需重算 active shards 公式，不能直接照搬 7.x 表格。

分片规划还应考虑故障恢复时间：单 shard 越大，recovery 从 peer 或 snapshot 回放越久。 合成示例：500 GB 单 primary 在 10 Gbps 网络下 recovery 可能超过 1 小时，期间 query 可能 partial。 因此「大 shard 减 fan-out」与「小 shard 快 recovery」存在张力；日志场景通常优先控 fan-out， 通过 Tier 把 recovery 限制在 hot 层小 shard，cold 层接受高延迟。架构文档应写明这一权衡，避免 SRE 既要求 7 天秒级大盘又要求单 shard 500 GB。

4ILM 冷热分离与 Tier 设计

ILM（Index Lifecycle Management）把 index 从 hot → warm → cold → delete 的阶段迁移自动化。 8.x 与 node role data_hot、data_warm、data_cold 绑定， allocation filter 由 ILM 自动写入，减少 7.x 手工 index.routing.allocation.require.box_type 的人为错误。 设计 Tier 的核心不是「多少天进 cold」，而是查询窗口与数据温度对齐： SRE 大盘若只查 7 天，则 8～90 天数据应处于查询代价更低的 tier（更少 replica、更大 shard、或 searchable snapshot）。

对象存储成本模型：hot 层 NVMe 每 TB 月成本远高于 S3/OSS cold（合成比例约 8～15 倍，视云厂商而定）。 ILM 的经济账是「7 天后 replica 降为 0 + shrink + snapshot」，而非无限堆 hot 磁盘。 7.x 仅 close index 而不 snapshot 时，恢复查询需 reopen 并承受 recovery，RTO 小时级； 8.x searchable snapshot 可在分钟级 mount，但首次查询延迟高——产品需分层 SLA。

4.1 shrink 与 forcemerge 的失败窗口

warm 阶段的 shrink 会把多个 primary 合并为更少 shard，长期看降低 fan-out； 但 shrink 执行期间需要额外磁盘与 segment rewrite，与 traffic spike 重叠时会拖慢 search。 forcemerge 到 1 segment 有利于读性能，但在 hot 层执行是经典反模式—— 它会长时间占用 merge thread 并阻塞新 segment 产生。 7.x 运维脚本里「每晚 forcemerge 昨日 index」的习惯，迁移到 8.x ILM 后应改为仅在 warm 阶段、 且通过 allocate 把任务限制在低峰节点。

searchable snapshot 进入 cold tier 时，数据在对象存储，本地 cache 有限； 首次查询可能触发 fetch，延迟可达数十秒（合成示例）。Dashboard 若默认 30 天且含 cold backing， 每次打开面板都会对 cold 层发起 fan-out——这是产品配置问题，不是 ES bug。 8.x 可在 Kibana data view 用 @timestamp 与 tier preference 限制，7.x 需靠 index pattern 手工排除 cold index 别名。

8.x 的 frozen tier 适合极少访问的合规留存：查询延迟秒级甚至更高，但存储成本最低。 7.x 无等价一体化 frozen 时，常见替代是 snapshot 到 S3 后 delete index—— 恢复查询需 restore snapshot，RTO 与 8.x searchable snapshot 不同，迁移方案需单独评估。

4.2 ILM policy 骨架（8.x）

典型 logs-90d-policy 四阶段：hot（rollover）→ warm（min_age: 7d，shrink + allocate warm tier） → cold（min_age: 21d，searchable snapshot）→ delete（min_age: 90d）。 各阶段 min_age 从 rollover 时刻起算，而非 index 创建时刻—— 与 7.x curator 按 index 名称日期删除的 mental model 不同，排障时必须看 _ilm/explain 的 phase 字段。 若 delete 未启用，90 天 retention 会在磁盘曲线上表现为线性增长直至打满，且 agg 时间窗越大超时越频繁。

allocation filter 由 ILM 写入 index.routing.allocation.include._tier_preference， 运维手工改 box_type 会被下一阶段覆盖。大促前可对整个 policy 执行 POST _ilm/stop， 恢复后再 start——比逐个 kill merge 任务更安全。7.x 需靠 curator pause，8.x 内置 stop 降低 runbook 复杂度。

warm 阶段 forcemerge 的 max_num_segments 设为 1 可极大减少 agg 扫描 segment 数， 但会生成超大 segment，后续删除与 snapshot 上传变慢。生产更常见折中是 merge 到 1～5 segment，并在 shrink 后再 merge。 7.x curator 的 optimize action 等价 forcemerge，同样不应在 hot 层 peak 执行。 对象存储快照仓库应独立于 hot 节点磁盘，避免 snapshot 与 indexing 争用 NVMe—— 8.x SLM（Snapshot Lifecycle Management）可与 ILM 串联：ILM 进 cold 前触发 snapshot，失败则 block cold transition。

5写入路径优化（Bulk / refresh / rollover）

写入路径优化目标是在不牺牲查询稳定性的前提下撑住 traffic spike。 三杠杆是 Bulk 批大小、refresh_interval、rollover 条件—— 它们共同决定 segment 产生速率与 near-real-time 可见性。 复合场景里「refresh 从 30 s 改为 5 s」之所以雪上加霜， 是因为 refresh 会打开新 segment 供搜索，增加 agg 需要扫描的 segment 数， 同时 indexing 线程池压力上升，与 ILM shrink 争用 disk IO。

合成示例量化：单 backing index 在 30 s refresh 下每天约 2,880 次 refresh（不含 merge）， 改为 5 s 后约 17,280 次——segment 数可增 5～6 倍，7 天 agg 扫描 segment 总量线性上升。 这不是说 refresh 应调到 5 分钟以上，而是说peak 窗口禁止临时改 refresh， 常态值应在容量规划时与 agg SLA 一并签字，而非 incident 中拍脑袋。

5.1 Bulk 与背压

Logstash / Fluent Bit 侧应启用 Bulk 且控制单批 5～15 MB（合成示例区间）， 避免「单文档一条 HTTP」打满 coordinating 连接。 8.x 提供 indexing_pressure 与 breaker 保护 data 节点 heap； 当 indexing_pressure.memory.limit 触发时，集群会对写入背压—— 此时加 data 节点不如先降 refresh 频率或临时扩 Kafka 消费 lag 容忍度。 7.x 同样存在 circuit breaker，但 indexing pressure 统计粒度在 8.x 更细。

文档 id 策略影响 overwrite 与版本冲突：日志场景推荐 auto-generated id，避免客户端指定相同 id 导致 heavy delete。 若从 Kafka 消费，应保证 at-least-once 语义下 ES 侧幂等（如 external version 或 ingest pipeline fingerprint）。 否则 replay 会在 peak 窗口制造 duplicate doc，agg 计数虚高，风控规则误报。

PUT _index_template/logs-app-template
{
  "index_patterns": ["logs-app-*"],
  "data_stream": {},
  "template": {
    "settings": {
      "index.refresh_interval": "30s",
      "index.codec": "best_compression",
      "index.number_of_replicas": 1,
      "index.lifecycle.name": "logs-90d-policy",
      "index.lifecycle.rollover_alias": "logs-app"
    },
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "trace.id": { "type": "keyword" },
        "service.name": { "type": "keyword" },
        "message": { "type": "text", "index": false }
      }
    }
  }
}

5.2 refresh 与 near-real-time 权衡

日志平台常见误解是「refresh 越短越好」。对风控 5 分钟窗口而言，30 s refresh + 1～2 分钟 ingest lag 通常可接受；强行 1 s refresh 会使 segment 数暴涨，损害第 6 章所述 agg 性能。 若业务强依赖秒级可见，应优先缩小查询时间窗与专用 hot stream， 而不是全局改 refresh。8.x TSDB mode 对 metrics 类字段有 downsample 路径， 与文本日志 pipeline 分离部署更清晰。

translog durability 与写入延迟亦相关：index.translog.durability 为 async 可换吞吐， 但节点 crash 可能丢最后若干秒文档——支付类日志需 request 并与业务 RPO 对齐。 Bulk 客户端应实现 exponential backoff 并识别 429 / 503； 8.x 返回的 EsRejectedExecutionException 常先于 OS oom killer 出现，是正确背压信号。 7.x Logstash elasticsearch output 的 retry 参数需与 Kafka consumer lag 联动，避免 ES 恢复后双倍灌入造成二次尖刺。

5.3 ingest pipeline CPU 与 GC

grok/dissect 在 coordinating 或 ingest node 上消耗 CPU。高 QPS 下 pipeline 应前置到 Logstash/Flink 做解析， ES ingest 仅做轻量 rename。否则会出现「索引速率正常但 coordinating CPU 高」的假象， 误扩容 data 节点。profile 应用可对比「带 pipeline bulk」与「预解析 bulk」的 indexing 延迟差（合成示例可差 30%～50%）。

rollover 触发后旧 backing index 仍接受查询，新写入只进新 backing。若 hot 阶段 min_age 过短， 多个小 backing 并存，7 天 agg 会扫全部 hot backing——与「单 backing 大 shard」设计目标相反。 因此 ILM hot 阶段不仅定义 rollover，还应定义何时 shrink 合并 hot backing（部分团队放在 warm 第一天执行）， 8.x 可在 policy 的 warm action 里 shrink 至 1 primary，7.x 需 curator shrink action 等价实现。

6聚合查询性能优化

点查快、agg 慢，几乎总是fan-out 规模与桶数量问题，而非「磁盘不够快」。 协调节点需要接收每个分片的 intermediate aggregation，再在内存中 merge。 当 Dashboard 使用 date_histogram 1 分钟粒度跨 7 天 + terms size 1000 嵌套时， 桶数量轻松突破 search.max_buckets（默认 65535）—— 即使调大该值，也只是把失败从「拒绝」推迟到「OOM」。

7.x 与 8.x 在 agg 执行引擎上均基于 Lucene doc values；8.x 对 date_histogram 的 calendar 对齐与 fixed_interval 语义更清晰，误用 calendar_interval: 1M 跨时区 Dashboard 会产生边界 off-by-one。 国际化业务若按 UTC 存储 @timestamp，Kibana 浏览器时区转换只影响展示，不影响 agg 桶边界—— 但运维 cron 与 ILM min_age 必须统一 UTC，否则「第 7 天进 warm」与「Dashboard 默认 7 天」错一天就会 fan-out 到 warm shrink 中的 index。

6.1 DSL 优化示例

对高基数 terms，8.x 推荐 composite 聚合分页拉全量，避免一次性 size: 10000。 对 Trace 点查，使用 routing 或 ids query 限制分片；对 SRE 大盘，改为 5 分钟 date_histogram 而非 1 分钟。以下示例展示 composite 替代 terms 分页（字段名 synthetic）：

除 composite 外，sampler 与 diversified_sampler 适用于「近似 TopN」， 在亿级 doc 上可降 10～100 倍 merge 成本（合成示例量级），但结果是统计采样，不可用于财务对账类 Dashboard。 7.x 与 8.x 语法一致。架构上应标注哪些面板是 exact、哪些是 sampled，避免 sampled 面板 SLA 被误用为 exact。

POST logs-app/_search
{
  "size": 0,
  "query": {
    "range": { "@timestamp": { "gte": "now-7d/d", "lte": "now" } }
  },
  "aggs": {
    "by_service": {
      "composite": {
        "size": 500,
        "sources": [
          { "svc": { "terms": { "field": "service.name" } } }
        ]
      }
    }
  }
}

6.2 预聚合与 Rollup / Transform

跨 30 天以上的错误码趋势，不应直接扫 raw logs。 8.x Transform 可按 service.name + status_code 每分钟汇总 doc_count， 写入独立 summary index（仅 2 primary shard，合成示例），Dashboard 绑 summary index。 7.x Rollup job 仍可用，但 8.x Transform 与 ILM 集成更顺。 架构评审应问：「这个 Dashboard 是否必须读 raw？」——若否，预聚合是降 fan-out 最稳手段。

Transform continuous 模式有 lag，通常 1～5 分钟（合成示例）；风控规则若要求硬实时，应读 hot raw 小窗 + Transform 长窗组合。 pivot 语法与 Painless 脚本会增加维护成本，应在 summary index mapping 冻结维度字段，禁止动态映射引入高基数 keyword。 7.x Rollup 索引与 raw index 需手工维护 alias；8.x Transform 目标 index 可绑同一 ILM 但 delete 周期更短。

对「错误码 Top10」类固定维度大盘，甚至可在 ingest 时用 pipeline 增加 error.category 枚举字段（低基数），避免对高基数 error.message 做 terms。 这是 mapping 层减负，与 Transform 互补。7.x/8.x 均适用，且比事后调 search.max_buckets 更根本。

filter 聚合先于 terms 可显著降桶数：先 filter 错误级别 ERROR， 再对子集 terms service.name。避免 post_filter 与 agg 语义混淆—— post_filter 不影响 agg 范围，是新手常见误配。8.x 的 runtime fields 便于临时维度， 但每条 doc 运行时计算，高 QPS agg 慎用；7.x 同样支持 runtime field，性能特征类似。

request_cache 对重复 agg 有效，但 time-based index 每 rollover 失效； Dashboard 自动刷新间隔若小于 rollover 周期，缓存命中率低于预期。 合成示例：15 s 自动刷新 + 5 min rollover 的 backing index，cache 命中率可能 < 10%， 不应把 cache 当作 agg 慢的首要优化手段。更稳的是 Transform 物化结果。

最后强调nested 与 join 类型在日志场景应尽量避免：nested agg 对每个 nested doc 独立建桶， fan-out 与内存开销远高于 flat keyword。若业务把 JSON 日志整包打入 object 且开启 dynamic， 极易意外产生 nested 或 multi-field 爆炸。8.x index.mode: logsdb（实验/演进中）面向日志压缩与查询优化， 落地前需评估与现有 ECS mapping 兼容性；7.x 无等价模式，迁移需单独 POC。

7监控最小集与排障信号

ES 日志集群最常见误判是「cluster health green 等于查询健康」。 green 只表示 primary/replica 分配完成，不表示 search thread pool 无 reject、 不表示 coordinating breaker 未 trip、更不表示 ILM 任务不在 peak 窗口执行。 监控最小集应能回答三个问题：写入是否背压、查询 fan-out 是否异常、ILM 是否与大促重叠。

8.x Stack Monitoring 提供 index-level indexing rate 与 search latency 分位，但默认保留较短； 长期趋势应导出至 Prometheus/Grafana 或 Elastic Agent integration。 关键告警应用「持续 5 分钟」而非单次尖刺，避免 ILM shrink 触发误页。 合成示例：active shards 5 分钟内上升 > 15% 且 ILM explain 有 shrink 阶段 → 自动通知 ES 运维暂停 policy。

7.1 集群级指标

• cluster.routing_allocation.active_shards：持续攀升通常是 rollover 过频或 delete 未执行。
• indices.segments.count：segment 过多拖慢 agg，关联 refresh 与 merge 策略。
• thread_pool.search.rejected 与 write.rejected：分节点、分 tier 看。
• jvm.mem.heap_used_percent on coordinating：agg merge 尖刺先于 data 节点。
• indexing_pressure（8.x）：写入背压早于 bulk 客户端报错。
• search.query_time_in_millis 分位：按 index pattern 拆分，避免集群均值掩盖大盘超时。

建议为日志集群单独建「ILM 任务看板」：展示当前 execute phase、shrink/merge 进度、预计完成时间。 Elastic Agent 8.x 可采集 ILM step 指标；7.x 需通过 _ilm/explain 定时脚本_exporter。 当 shrink 预计与大促重叠时，提前 24 小时 adjust min_age 或 suspend—— 这比 incident 中 kill task 风险低，且可审计。

7.2 排障顺序（框架）

收到 agg 超时告警时，建议固定顺序：① 确认查询时间窗与 index pattern ② 数 active shards 与 backing index 个数 ③ 看 ILM 当前 execute 任务 ④ profile 一次慢查询 ⑤ 再讨论扩容。 第 1 章 composite 场景若在步骤 ③ 就发现 warm shrink 与 peak 重叠，正确动作是 suspend ILM policy 而非加 coordinating。 7.x 环境用 curator 时，等价检查 _cat/tasks 中的 merge/shrink 任务。

profile API 输出 collect、rewrite、build_aggregations 各阶段耗时， 若 build_aggregations 在 data 节点占比高而 coordinating merge 占比低，说明桶数或 doc values 是瓶颈； 若 coordinating 占比高，优先减 shard 或加 coordinating。不要跳过 profile 直接调 search.max_buckets—— 那是掩盖症状。8.x profile 与 7.x 结构类似，可脚本化对比压测前后 profile diff。

GET _cat/tasks?v&actions=*forcemerge*,*shrink*,*migrate*
GET _ilm/explain/logs-app-000042
GET _nodes/stats/thread_pool?filter_path=**.search,**.write
POST logs-app/_search?request_cache=false
{ "profile": true, "size": 0, "aggs": { ... } }

Elastic Stack Monitoring 或 Prometheus exporter 应采集 elasticsearch_cluster_health_status 与 elasticsearch_jvm_memory_used_bytes 分角色标签。告警路由建议：ILM 任务堆积 → ES 运维； search reject → 查询 owner + 架构；indexing_pressure → ingest owner。 7.x X-Pack monitoring 基本等价，但 8.x security 默认开启后需配置 API key 给监控系统。

慢查询日志应包含 index、took、total_shards 字段， 便于统计「哪条 Dashboard 一次扫 800 分片」。将 slowlog 与 Kibana saved object id 关联是进阶做法， 可在复盘时直接点名可视化面板而非泛泛说「ES 慢」。

Circuit breaker 类型需分而视之：parent trip 常因 agg 合并过大； fielddata trip 常因对 text 误 agg；request trip 常因单查询过大。 8.x 默认 breaker 限额与 heap 比例相关，盲目调大 indices.breaker.total.limit 只会推迟 OOM。 7.x fielddata 默认禁用 on text，但 dynamic mapping 仍可能引入 keyword 高基数字段—— 监控 jvm.mem.pools.old 与 breaker trip 日志应分角色采集，data 与 coordinating 不可混看。

8架构决策树与演进路线

日志 ES 集群的演进通常经历三阶段：① 能写入 ② 能查询 ③ 成本与 SLA 可预测。 多数团队卡在 ②→③：点查与 Trace 已可用，但 SRE 大盘与 ILM 成本在 peak 窗口同时爆雷。 决策树的核心分叉不是「上不上 Kafka」，而是单次查询允许 fan-out 到多少分片、多少天 raw 数据对 Dashboard 可见。

RACI 建议：架构 owner 对 fan-out 上限与 ILM 日历负责；SRE owner 对 Dashboard 默认时间窗负责； 业务 owner 对风控/合规 retention 负责。三者不一致时，技术层必出 composite 事故。 评审会上应用一页纸写出「最大查询窗 × 最大 backing 数 × 单 backing primary 数 = 最大 shard fan-out」， 合成示例：7 天 × 7 个 backing × 6 primary = 294 primary，再加 replica=1 → 588 shard 副本，协调节点需按此 sizing。

8.1 决策树（文字版）

若 daily 数据量 < 2 TB 且 retention < 30 天，可维持较小集群、Data Stream rollover 1～2 primary/day（合成示例）， 重点监控 segment 与 refresh。若 daily > 10 TB，必须先算 primary 上限，再选 Tier 与 Transform； 此时「加 3 台 data 节点」若不改 rollover，只是推迟超时。 若合规要求 180 天 raw 可查，必须引入 cold/searchable snapshot 并接受独立 SLA， 或强制 Dashboard 读 Transform summary——不能假设 hot 层能扛 180 天 agg。

第二个分叉：Trace 点查 QPS 是否 > 500（合成示例）？若是，应为 traceId 建独立小分片 stream 或 routing partition， 避免与 SRE agg 共享 coordinating。第三个分叉：是否多地域写入？ 8.x CCR 可做 read follower，但写入仍单主；跨地域日志合并查询 fan-out 翻倍，需 federated search 或 centralized hot tier 设计。 7.x 跨集群 search 用 tribe/node 模式已废弃，迁移方案应直接规划 centralized observability 集群。

成本维度：hot 层节点占集群 CAPEX 大头，cold/searchable snapshot 把 80% 以上历史数据（合成比例）转到对象存储， 可释放 hot 磁盘给更长的 hot 查询窗——不是把 cold 当免费午餐，而是把 fan-out 与存储成本一起优化。 决策树在「daily > 10 TB」分支上应同时输出查询 SLA 分层表与存储 CAPEX 曲线， 避免只优化查询却使 90 天 retention 磁盘预算翻倍。合成示例：28 TB/天 × 90 天 raw 全 hot 需约 2.5 PB 磁盘（含副本）， 经 ILM 7 天热 + 83 天 cold 可降至约 0.6 PB 热存储 + 对象存储——具体数字随压缩比与副本策略变化，但数量级差异是架构决策依据。

8.2 演进路线

短期（1～2 迭代）：对齐 ILM 与 Dashboard 时间窗、调 rollover、加 coordinating、开 slowlog。 中期：Transform 汇总、warm shrink 错峰、cold snapshot。 长期：按业务域拆 Data Stream、评估 TSDB 用于 metrics 子集、与 T09 全链路可观测统一 traceId 规范。 7.x 遗留 index 通过 reindex + shrink 收敛分片，避免「双轨运行」超过两个大版本。

8.3 与周边系统的边界

Kafka 缓冲层可吸收 ES 短暂背压，但 lag 过大时 restart consumer 会造成写入尖刺—— 与第 1 章 traffic spike 叠加。架构上应约定：ES indexing_pressure 持续 > 80%（合成阈值）时， Kafka consumer 降 concurrency 而非升 concurrency。ClickHouse 等 OLAP 适合长周期分析， 不应与 ES 争抢「90 天全量 agg」职责；ES 保留 7～14 天 hot 查询 + trace 点查，历史趋势下沉 OLAP 是常见分层。

安全与多租户：8.x 默认启用 security，Kibana space 与 index privilege 需按域隔离。 误配 read 跨域 pattern 会导致一次 agg 扫全公司日志，fan-out 与合规风险双爆。 7.x 迁移时常因「内网可信」而忽略 RBAC，上线 8.x 后 Dashboard 共享链接可能触发意外跨域查询。

硬件层补充：coordinating 节点 heap 建议 31 GB 封顶（Compressed Oops 边界）， 超过则未必线性受益；data hot 节点优先 NVMe 与充足 page cache，cold 节点可 HDD。 合成示例中 coordinating 32 GB heap、16 vCPU 可支撑约 500 shard 副本 merge（视 agg 复杂度而定）—— 应通过 quarterly load test 校准，勿照搬厂商 generic sizing。

9上线检查表、总结与延伸阅读

9.1 上线与大促前检查表

9.2 核心结论

ES 8.x 海量日志架构的本质不是「堆节点存日志」，而是在分片 fan-out、ILM 阶段任务、聚合桶合并 三条线上同时建立可观测、可冻结、可预测的顺序。 分片数在创建时基本锁死查询失败窗口；ILM 迁移是必要优化，但与 peak 重叠会变成查询杀手； coordinating 节点 heap 是 agg SLA 的隐形闸门。 任一闸门失控，都会表现为「cluster green 但 Dashboard 全红」——与第 1 章 composite 场景同构。

7.x 升级到 8.x 不应仅做版本 uplift：Data Stream、默认 security、searchable snapshot 会改变运维 runbook。 双轨运行期间最容易出现「7.x index 与 8.x data stream 并存，Dashboard 扫两者导致 fan-out 叠加」—— 迁移窗口应设 hard cutoff，旧 index 只读 frozen 并尽快 delete 或 snapshot。

带走三句话：第一，点查快不等于 agg 快，先看 fan-out 与桶数。 第二，ILM shrink 是低峰动作，不是 peak 急救包。 第三，Dashboard 默认时间窗必须与 ILM hot 阶段对齐，否则架构设计未闭环。

演练建议：每季度做一次「只读压测」——复制生产 Dashboard 查询 against staging 集群， 人为 suspend ILM 后对比 active shards ±20% 场景下 agg P99 变化（合成示例阈值）。 比单纯 ping 集群更能暴露 fan-out Debt。7.x 环境可用 snapshot restore 到 staging 复现 backing index 拓扑， 8.x 可用 searchable snapshot mount 降低成本。

Postmortem 模板应固定三问：本次 agg 超时扫描了多少 primary？ILM 是否在 peak 执行 shrink/merge？ coordinating heap 峰值与 search reject 是否同步？缺任一答案的复盘不能关闭。 与 Kafka 容灾篇「ISR 抖动幅度、Producer 错误率、Rebalance 总时长」三字段对照， 形成系列统一的复盘语言，便于架构委员会横向比较中间件风险。

若你仅能记住一条公式：单次 agg 的 shard 副本数 ≈ 时间窗内 backing 数 × 每 backing primary 数 × (1 + replica)。 任何架构改动（rollover、ILM delete、replica 策略）都应先更新此公式再上线。 7.x 与 8.x 机制不同，但 fan-out 算术不变——这是跨版本最稳定的架构锚点。

文档维护：上述检查表应随每次大促复盘更新阈值（active shards 上限、coordinating 规格、ILM 日历）。 无 owner 的静态 checklist 会在三次大促后与实际集群漂移，失去签字的约束力—— 这与 Kafka 容灾篇强调 RACI 的原因相同，只是对象从 ISR 换成 shard fan-out。 建议将本检查表链接到内部 runbook 首页，作为 Batch2 T08 交付物长期维护。 每次 ILM 或 rollover 策略变更须 diff 检查表阈值并重新签字。 未更新版本的大促签字视为无效，不得作为上线依据或演练通过凭证。

边界说明：本文不提供万能 elasticsearch.yml 模板，也不讨论 Elastic Cloud 与自建集群的定价差异—— 不同组织的合规要求可能强制 180 天 raw 可查或禁止 delete。 你要带走的是复合场景下的决策顺序、8.x Data Stream/ILM 机制边界、以及大促前可执行的检查表。 全链路 Kafka+ES 可观测见系列 T09；JVM 低延迟见 GC 篇；Kafka 容灾见 T07。

附录式心算：大促前 10 分钟快速自检——(1) GET _cat/shards?v&h=index,shard,prirep,state 行数是否较基线增 20% 以上； (2) GET _ilm/status 是否 RUNNING 且 explain 中有 shrink；(3) 随机 pick 3 块 Kibana 面板执行 profile 是否 total_shards > 200。 任一命中且处于 peak 窗口，先执行 ILM suspend 与 Dashboard 缩窗，再通知业务查询降级。此流程不替代第 9.1 检查表，但可作为值班口头口诀。

9.3 延伸阅读

1. BOOKClinton Gormley 等《Elasticsearch 权威指南》—— 分片、聚合、Index Lifecycle 章节
2. DOCElasticsearch 8.x · Data streams
3. DOCElasticsearch 8.x · Index lifecycle management
4. DOCElasticsearch 8.x · Tune for search speed
5. DOCElasticsearch 8.x · Size your shards
6. SERIES同系列 T09《可观测性 Kafka+ES 全链路》—— ingest 背压与 traceId 规范，与本篇查询 SLA 互补