【Elasticsearch】集群监控：分片和节点-CSDN博客

本文链接：https://blog.csdn.net/be_racle/article/details/148806749

集群监控：分片和节点

1.分片对集群健康的影响
2.节点维度对集群健康的影响
3.分片与节点关联影响
- 3.1 分片-节点分布关系
- 3.2 资源竞争模型
4.最佳实践建议

1.分片对集群健康的影响

1.1 分片分配状态

未分配分片：直接导致集群状态变为 RED / YELLOW。
- 案例：当 5 个主分片中有 1 个无法分配时，集群变 RED，数据写入会部分失败。
- 常见原因：节点离线、磁盘空间不足、分配规则限制。
重定位分片：影响集群性能但保障数据安全。
- 监控指标：cluster_health.relocating_shards。
- 案例：节点重启时触发的分片重平衡会导致短暂性能下降。

1.2 分片数量配置

过度分片
- 增加集群元数据管理开销。
- 导致搜索性能下降（需要合并更多分片结果）。
- 案例：一个 100GB 的索引分成 1000 个分片，查询延迟增加 $300\%$ 。
分片不足
- 限制水平扩展能力。
- 导致热点节点问题。
- 案例：单个 100GB 分片无法利用多节点并行处理能力。

1.3 分片数据均衡

数据倾斜
- 监控指标：indices.docs.count 和 indices.store.size 的分片间差异。
- 影响：热点节点 CPU / 内存压力过大。
- 案例： $30\%$ 的请求集中在 $10\%$ 的分片上，导致节点负载不均衡。

2.节点维度对集群健康的影响

2.1 节点角色失衡

主节点过载
- 监控指标：主节点 node_stats.process.cpu.percent $70\%$ 。
- 风险：集群元数据更新延迟，可能引发脑裂。
- 案例：3 节点集群中 1 个主节点同时承担数据职责，导致集群状态更新延迟。
数据节点资源争用
- 监控指标：thread_pool.{bulk,search}.rejected
- 影响：写入/查询请求被拒绝。
- 案例：批量导入期间大量 bulk 请求被拒绝。

⭐ 集群节点数达到一定规模后，建议采用 独立主节点角色。主节点通过监视集群管理活动（例如跟踪集群中的所有节点、索引和分片）来提高集群的稳定性。主节点还监视集群的运行状况，以确保数据节点不会过载，并使集群具有容错能力。

⭐ 针对集群规模大的场景，建议至少设置三个主节点。这样可确保在发生故障期间，可以在集群中选举新的主节点。

⭐ 一般来说，主节点专注于维护集群状态，因此通常不需要过高的 CPU 和内存资源，这样一个具备适度 CPU 和内存资源的计算机，便足以承担主节点的任务。

⭐ 与主节点相比，数据节点是文档落地存储的载体，同时数据节点还接收并处理客户端请求，执行搜索和聚合有关的所有数据操作。数据节点往往需要具有较高 CPU 内存资源的服务器。文档增、删、改、查以及搜索操作会占用大量 CPU 和 IO。因此监视数据节点利用率指标很重要，从 CPU、内存的角度来看，应确保数据节点平且不会过载。

2.2 节点资源瓶颈

JVM 内存压力
- 监控指标：jvm.mem.heap_used_percent $>75\%$
- 影响：频繁 GC 导致请求延迟飙升。
- 案例：字段数据缓存未限制导致 OOM，节点退出集群。
磁盘 I/O 瓶颈
- 监控指标：fs.io_stats.io_time.total 持续高位。
- 影响：段合并和刷新延迟。
- 案例：SSD 磁盘 IOPS 达到上限，索引速率下降 $50\%$ 。

2.3 节点故障场景

节点离线连锁反应
- 监控指标：cluster_health.number_of_nodes 变化
- 影响流程：
  - 主节点重新选举。
  - 分片重分配。
  - 副本分片提升为主分片。
- 案例：3 节点集群中 1 节点宕机，触发分片重平衡导致查询延迟增加。
滚动重启影响
- 监控重点：分片恢复速度和资源占用。
- 典型问题：大量分片同时恢复导致网络带宽打满。

3.分片与节点关联影响

3.1 分片-节点分布关系

分片分布不均
- 监控指标：cat/shards?v 查看分片分布。
- 影响：部分节点承担过多分片管理责任。
- 案例： $10$ 节点集群中 $3$ 个节点承载了 $40\%$ 的分片。
机架感知失效
- 监控指标：cluster.routing.allocation.awareness.attributes
- 风险：同一机架节点同时故障导致数据丢失。
- 案例：未配置机架感知，一个机柜断电导致数据不可用。

3.2 资源竞争模型

分片恢复资源争用
- 监控指标：indices.recovery.current_as_source 和 ...as_target。
- 影响：正常业务请求资源被挤占。
- 案例：节点重启后恢复分片占满网络带宽，导致搜索超时。
冷热数据干扰
- 监控指标：indexing_pressure.memory.current（7.10+）
- 问题：历史数据归档影响实时索引性能。
- 解决方案：通过冷热分离架构解决。

4.最佳实践建议

分片监控策略
- 设置 _cluster/health?level=shards 级别监控。
- 对 UNASSIGNED_SHARDS 设置实时告警。
- 定期检查 _cat/shards?v&h=index,shard,prirep,state,node,store。
节点容量规划
- 每个数据节点建议承载的分片数：每 1GB 堆内存对应 $20 - 25$ 个分片。
- 设置集群分片分配平衡策略：
```
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.balance.shard": "0.45",
    "cluster.routing.allocation.balance.index": "0.55"
  }
}
```
关键告警阈值
- 单个节点分片数 $> 1000$
- 分片恢复速度持续 $< 10$ MB/s
- 节点 JVM 内存使用率 $> 80$ 持续 $5$ 分钟