适用场景

ES 集群最常见的三类问题：分片数过多导致集群元数据压力、磁盘水位触发只读、查询与写入互相影响。治理核心是分片数量规划与生命周期管理（ILM），不是加机器就能解决。

配置步骤（生命周期与容量控制）

// 生命周期策略（示例：7 天热 -> 30 天温 -> 90 天删除）
PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot":    { "actions": { "rollover": { "max_size": "30gb", "max_age": "1d" } } },
      "warm":   { "min_age": "7d",  "actions": { "shrink": { "number_of_shards": 1 } } },
      "delete": { "min_age": "90d", "actions": { "delete": {} } }
    }
  }
}
# 索引模板绑定策略
# 在模板中设置 index.lifecycle.name = logs-policy

# 容量预估
# 日增日志量 × 保留天数 × (1 + 副本数 + 合并开销约 10%)

关键参数与建议

  • 分片规划：单分片 10-50GB 为宜，避免小分片过多
  • 副本策略：日志类可 1 副本，重要数据 2 副本
  • 生命周期：热温冷分层 + 定期删除或归档，控制总量
  • 水位告警：磁盘 75% 预警、85% 关键（默认会触发只读保护）
  • 写入与查询隔离：批量写入与复杂查询错峰，必要时分离集群
  • 慢查询治理：关注慢日志，避免大范围聚合与深分页
  • 主节点稳定：主节点专用，避免混部导致选主异常

容易踩的坑

  • 只做 rollover 不做删除，总量持续增长
  • 删除策略时间太短，故障复盘时日志已被清掉
  • shrink 未考虑分片文档数，缩小后单分片过大
  • 未按业务区分保留期，核心日志与调试日志同策略
  • 容量预估没算副本与合并开销，磁盘提前告急
  • 策略变更未评估，历史索引不受控

验证与巡检

# 策略生效检查
curl -s 'http://es1:9200/logs-*/_ilm/explain?pretty' | head -40

# 索引总量趋势（按天）
curl -s 'http://es1:9200/_cat/indices?v&h=index,store.size,pri,rep' | sort -k2 -hr | head -10
  • 巡检：策略绑定正确、历史索引按龄删除、日增量与预估偏差 < 20%

小结

ES 治理验收：集群 status 绿、分片大小合理、磁盘水位可控、有生命周期策略自动滚动删除，且无大小分片长期不均衡。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。