如何检查Elasticsearch集群健康状态？

Question

如何通过Elasticsearch REST API检查集群健康状态？常用命令返回结果中`status`、`number_of_nodes`、`active_shards`等关键字段分别代表什么含义？当集群状态为yellow或red时，应如何快速定位问题根源，例如主分片与副本分片的分配情况、节点是否离线、磁盘空间是否不足等？

Answer 1

一、通过Elasticsearch REST API检查集群健康状态

Elasticsearch 提供了丰富的 RESTful API 接口，其中 /_cluster/health 是最常用的接口之一，用于获取集群的实时健康状态。该接口返回 JSON 格式的数据，包含多个关键字段，帮助运维人员快速判断集群运行状况。

GET /_cluster/health

执行上述请求后，将返回如下结构的响应：

{
  "cluster_name": "elasticsearch-cluster",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 3,
  "number_of_data_nodes": 3,
  "active_primary_shards": 5,
  "active_shards": 8,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 3,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 72.72727272727273
}

1. 关键字段解析

• status：表示集群整体健康状态，可能值为 green、yellow 或 red。
  - green：所有主分片和副本分片均已正确分配。
  - yellow：主分片已分配，但部分副本分片未分配（常见于单节点集群）。
  - red：存在未分配的主分片，数据不可用。
• number_of_nodes：当前连接到集群的节点总数，包括主节点、数据节点和协调节点等。
• active_shards：当前已成功分配并处于活动状态的分片总数（含主分片和副本分片）。
• active_primary_shards：已激活的主分片数量，应等于索引中定义的主分片总数。
• unassigned_shards：未被分配的分片数，是诊断 red/yellow 状态的关键指标。
• number_of_data_nodes：专门承担数据存储职责的节点数量。
• relocating_shards：正在迁移中的分片数量，过高可能说明负载不均或节点加入/退出频繁。

2. 集群状态异常时的排查流程

当 status 显示为 yellow 或 red 时，需立即进行问题定位。以下是系统化的排查路径：

1. 首先确认是否存在节点离线：
   GET /_cat/nodes?v
   检查输出中是否缺少预期节点，或标记为关闭状态。
2. 查看未分配分片详情：
   GET /_cluster/allocation/explain
   该 API 可解释为何某一分片未能分配，例如磁盘空间不足、节点过滤策略限制等。
3. 检查各节点磁盘使用情况：
   GET /_cat/allocation?v
   输出包含每个节点的 shard 数量、磁盘使用率及可用空间。
4. 验证索引设置是否合理：
   若副本数设为 2，但仅有 1 个数据节点，则副本无法分配，导致 yellow 状态。
5. 排查网络分区或 JVM 崩溃日志：
   查阅 Elasticsearch 日志文件（如 logs/elasticsearch.log），寻找 disconnected from master 或 out of memory 错误。
6. 检查集群设置中的分片分配策略：
   如启用了 cluster.routing.allocation.enable 为 none，会导致分片无法自动分配。

3. 常见问题与对应现象对照表

问题类型	典型表现	诊断命令	解决方案建议
节点宕机	number_of_nodes 减少，unassigned_shards 增加	GET /_cat/nodes	恢复节点或临时降低副本数
磁盘空间不足	unassigned_shards 持续存在，allocation explain 提示 disk threshold	GET /_cat/allocation	清理数据或扩容磁盘
副本数超过节点数	status=yellow，active_primary_shards 正常	GET /_cluster/settings	调整 index.number_of_replicas
主分片丢失且无法恢复	status=red，active_primary_shards 少于预期	GET /_cluster/allocation/explain	尝试从备份恢复或手动强制分配
分片分配被禁用	大量 unassigned_shards，无明显硬件问题	GET /_cluster/settings	启用分配：cluster.routing.allocation.enable: all

4. 故障排查流程图（Mermaid）

graph TD
    A[获取集群健康状态] --> B{status == green?}
    B -- 是 --> C[集群正常]
    B -- 否 --> D[检查 number_of_nodes 是否减少]
    D --> E{节点是否离线?}
    E -- 是 --> F[检查节点日志与网络]
    E -- 否 --> G[查看 unassigned_shards 数量]
    G --> H[调用 allocation/explain 分析原因]
    H --> I{原因: 磁盘/副本/配置?}
    I --> J[针对性处理: 清理/调整副本/修改设置]
    J --> K[观察状态是否恢复]

此流程图清晰展示了从发现问题到定位根源的完整逻辑链路，适用于生产环境应急响应。

5. 进阶监控建议

对于拥有五年以上经验的工程师，建议结合以下实践提升集群可观测性：

• 部署 Prometheus + Exporter 实现指标采集，重点关注 elasticsearch_cluster_health_status、elasticsearch_indices_shards_unassigned 等指标。
• 配置告警规则：当 status != green 或 unassigned_shards > 0 持续超过5分钟时触发通知。
• 定期执行 _cluster/reroute 手动干预分片分布，避免热点节点。
• 利用 Kibana Stack Monitoring 功能可视化节点资源消耗趋势。
• 对关键索引启用慢查询日志，并分析其对分片稳定性的影响。
• 实施滚动重启策略，确保升级过程中集群始终保持 green 状态。
• 在多可用区部署中，使用 zone-aware 配置防止跨区故障引发级联失效。