集群健康接口是什么
_cluster/health 是集群体检的第一个接口：返回健康状态色、节点数、分片计数与主节点待处理任务数。green 表示主分片与副本全部分配完毕，yellow 表示主分片可用但存在未分配副本（单节点集群的常见现象），red 表示至少一个主分片未分配、部分数据无法检索。它只反映分片分配情况，状态为绿也不代表查询都正常。
基本信息
| 接口 | GET /_cluster/health，可加索引或模式限定范围 |
|---|---|
| 关键字段 | status、number_of_nodes、active_shards、unassigned_shards、initializing_shards、relocating_shards |
| 其他字段 | number_of_pending_tasks、task_max_waiting_in_queue_millis、active_shards_percent_as_number |
| 等待参数 | wait_for_status、wait_for_no_relocating_shards、wait_for_nodes、timeout |
| 展开参数 | level=indices 或 level=shards 显示明细 |
典型使用场景
- 集群巡检与监控：把 status 与 unassigned_shards 作为告警指标
- 变更前后校验：滚重启、扩容、改副本数后确认分片是否收敛
- 灾备切换：恢复后等待 wait_for_status=yellow 再放业务流量
- 排障入口：red 时先看未分配分片数，再查 _cat/shards 与 allocation explain
- 定位问题索引：GET /_cluster/health/logs-*?level=indices 逐索引核对
- 容量与均衡评估：对比各节点的分片与磁盘占用，判断是否需要重平衡
示例
示例
GET /_cluster/health?pretty # 集群整体健康
GET /_cluster/health?wait_for_status=yellow&timeout=30s # 最多等 30 秒到 yellow
GET /_cluster/health?wait_for_no_relocating_shards=true # 等迁移结束（重启后常用）
GET /_cluster/health/logs-*?level=indices&pretty # 按索引展开明细
GET /_cat/shards?v&s=state # 哪个分片没分配
GET /_cluster/allocation/explain # 未分配原因诊断核心字段读法
| 字段 | 含义 | 异常信号 |
|---|---|---|
| status | 集群健康色 | red 出现主分片未分配，需立即处理 |
| number_of_nodes | 在线节点数 | 少于预期说明节点掉线 |
| active_shards | 已激活分片数 | 持续低于总数说明分配未完成 |
| unassigned_shards | 未分配分片数 | yellow 时常为副本，red 时含主分片 |
| initializing_shards | 正在初始化的分片 | 长时间不归零说明恢复卡住 |
| relocating_shards | 正在迁移的分片 | 滚重启期间短暂非零正常 |
| number_of_pending_tasks | 主节点待处理任务 | 持续增长说明主节点繁忙或分配被阻塞 |
| active_shards_percent | 活跃分片百分比 | 便于做数值告警阈值 |
单节点集群的 yellow 是预期现象：副本没有第二台机器可放，把 number_of_replicas 设为 0 即可转绿，但那也意味着放弃冗余，先确认没有节点意外掉线再动手。
带 wait_for_* 的请求会一直阻塞到条件满足或 timeout，监控探针与脚本务必设置合理超时，否则集群长期不健康时探针会堆积。
green 不等于服务正常：线程池拒绝、断路器触发、磁盘水位超限时状态仍可能是 green，要配合 _cat/nodes、集群统计与日志一起判断。
巡检命令组合
- 先 GET /_cluster/health 看全局状态色与未分配分片数
- 再 GET /_cat/nodes?v 看节点堆内存、CPU 与磁盘水位是否失衡
- GET /_cat/indices?v&s=store.size:desc 找出体积最大与健康异常的索引
- GET /_cat/shards?v&s=state 定位具体未分配或迁移中的分片
- GET /_cluster/allocation/explain 得到未分配分片的直接原因
- GET /_cluster/stats 或 GET _nodes/stats 观察线程池、缓存与 GC 的长期趋势
一键巡检序列
一键巡检序列
GET /_cluster/health?pretty
GET /_cat/nodes?v&h=ip,name,node.role,master,heap.percent,disk.used_percent,cpu
GET /_cat/indices?v&s=store.size:desc&h=index,health,pri,rep,docs.count,store.size
GET /_cat/shards?v&s=state
GET /_cluster/allocation/explain?pretty把 health 的 status 与 unassigned_shards 一起纳入监控，比只看颜色更早发现问题：分片正在恢复时颜色可能已经转绿，但数据尚未完全就绪。
健康色判定与处置
- green：主分片与副本全部分配，仍需确认待处理任务数不持续增长
- yellow：主分片可用、副本未分配，单节点集群属预期，先确认没有节点掉线
- red：至少一个主分片未分配，先看未分配分片数再做分配诊断
- 常见原因：节点掉线、磁盘水位超过水位线、分片分配被手动关闭
- 临时放开分配开关前先定位根因，反复开关会让分片来回搬迁
- 恢复期间 initializing_shards 非零属正常，重点看它是否单调下降
索引粒度健康用 GET /_cluster/health/logs-*?level=indices 展开：集群整体 green 也可能存在单个索引 yellow（其副本未分配），排障要按索引粒度确认范围。