elastic /_cat/health解读

Posted on Views:

1. 集群状态解读

get /_cat/indices?v

你提供的是 Elasticsearch _cat/health 输出：

status: yellow
node.total: 3
node.data: 3
shards: 1275
pri: 641
relo: 0
init: 6
unassign: 1
active_shards_percent: 99.5%

1.1 关键指标含义

字段 含义 当前值解读
status 集群健康状态 yellow（副本不完整）
node.total 总节点数 3
node.data 数据节点数 3（正常）
shards 总分片数 1275（偏高）
pri 主分片数 641
init 初始化分片 6（正在恢复）
unassign 未分配分片 1（存在问题）
active_shards_percent 活跃分片比例 99.5%（接近正常）

2. 当前状态本质判断

2.1 为什么是 yellow

核心结论：

主分片全部正常，但副本分片存在未分配或未完全恢复

即：

  • ✅ 所有主分片可用 → 数据不丢
  • ⚠️ 副本不完整 → 存在风险（容灾能力下降）

2.2 当前异常点

（1）存在未分配分片

unassign = 1

说明：

  • 至少有 1 个 shard（可能是副本）无法分配
  • 需要进一步定位原因

（2）有初始化中的 shard

init = 6

说明：

  • 正在做 shard recovery / relocation
  • 可能是：
    • 节点刚恢复
    • 索引刚创建
    • rebalance

（3）分片数量异常偏高 ⚠️（重点）

1275 shards / 3 nodes ≈ 425 shards / node

对于生产环境，这是明显偏高的

经验值：

指标 推荐
每节点 shard 数 < 200（理想 <100）
单 shard 大小 20~50GB

当前风险：

  • Heap 压力大（cluster state）
  • GC频繁
  • 查询性能下降
  • 分片调度变慢（你已经出现 init）

3. 问题根因推测

3.1 分片无法分配（导致 yellow）

可能原因：

① 副本数过高

1
"number_of_replicas": 1

但：

  • 节点数不足
  • 或分配策略限制

② 磁盘水位限制（常见）

1
2
cluster.routing.allocation.disk.watermark.high
cluster.routing.allocation.disk.watermark.flood_stage

触发后：

  • shard 不再分配
  • index 可能只读

③ awareness / allocation filtering

例如：

1
2
cluster.routing.allocation.awareness.attributes
cluster.routing.allocation.exclude._ip

④ 同节点副本限制

ES 默认：

副本不能和主分片在同一个节点

如果：

  • 只有3节点
  • shard分布不均

可能导致：

  • 某些副本无法放置

4. 深入诊断步骤

4.1 查看未分配 shard 原因

1
GET _cluster/allocation/explain

重点看：

1
2
"unassigned_info"
"node_allocation_decisions"

4.2 查看分片分布

1
GET _cat/shards?v

关注：

  • UNASSIGNED shard
  • INITIALIZING shard

4.3 查看节点磁盘

1
GET _cat/allocation?v

重点：

字段 意义
disk.percent 使用率
shards 每节点 shard 数

5. 优化建议（架构级）

5.1 降低分片数量（核心优化）

当前问题

  • shard 数过多（1275）
  • 平均每 index shard 太碎

优化方案

方案1：减少 index shard 数
1
"number_of_shards": 1 或 2
方案2：使用 rollover + ILM
  • 控制 shard 大小
  • 自动归档
方案3：Shrink index
1
POST index/_shrink/index_shrink

5.2 调整副本策略

如果是非关键数据：

1
2
3
4
PUT _all/_settings
{
  "number_of_replicas": 0
}

可快速恢复 green（但降低容灾）

5.3 检查磁盘水位

1
GET _cluster/settings

必要时调整：

1
2
cluster.routing.allocation.disk.watermark.low: 85%
cluster.routing.allocation.disk.watermark.high: 90%

5.4 扩容节点（结构性解决）

当前：

3 nodes + 1275 shards

建议：

  • 至少扩到 5~6 data nodes 【x3 倍数来扩容分片数量】
  • 或降低 shard

6. 一句话总结

当前 yellow 不是核心问题，真正的问题是 分片过多 + 分配压力 + 副本无法落地，如果不治理，会逐步演变为 red 或性能雪崩。