bigywater.tech
Elasticsearch · 153

Elasticsearch 健康检查接口

本机真实在健康状态下查_health_report，发现它把集群健康拆解成8个独立的indicator（master_is_stable、disk、shards_availability等），每个都带着人话描述的symptom；真实建一个默认1副本的索引制造yellow状态后，shards_availability这个indicator真实给出了完整的diagnosis，包含cause、action、help_url和具体受影响的索引名；同一时刻对比老的_cluster/health，真实只给出unassigned_shards:1这个干巴巴的数字，完全没有任何解释，直接展示了新旧健康检查接口在诊断能力上的真实差距。

健康状态下查_health_report
真实看到8个独立indicator都带人话描述
制造一次yellow后查diagnosis
真实给出cause、action、help_url和受影响索引
对比_cluster/health
真实只给unassigned_shards:1没有任何解释

做的事：本机真实在完全健康的状态下查一次_health_report，看这个接口真实会给出哪些信息

代码GET /_health_report

验证：真实看到8个独立的indicator，每一个都带着symptom这句人话描述，不是单纯的技术数字

实测 · 本机 Elasticsearch 8.15.0 执行输出 
真实的8个indicator: master_is_stable, repository_integrity, disk,
  shards_capacity, shards_availability, data_stream_lifecycle, slm, ilm

每一个indicator真实都长这样:
{"status":"green", "symptom":"The cluster has a stable master node", "details":{...}}

这组真实数据说明_health_report真实是把集群健康状况拆解成了好几个真实独立的维度分别汇报，每个维度真实都配了一句人能直接读懂的symptom描述，而不是像老的_cluster/health那样把所有信息都压缩成几个单纯的数字，需要人自己去解读这些数字背后真实意味着什么。

真实建一个默认1副本的索引，在单节点上制造一次真实的yellow，看_health_report会不会给出比数字更有用的信息

代码PUT /health_test # 真实不带settings，用默认的1副本 GET /_health_report

验证：shards_availability这个indicator真实立刻给出了一整段diagnosis，包含cause、action、help_url和具体受影响的索引名

实测 · 本机执行输出 
shards_availability.status: "yellow"
shards_availability.symptom: "This cluster has 1 unavailable replica shard."

真实的diagnosis:
→ cause: "Elasticsearch isn't allowed to allocate some shards from these
   indices to any of the nodes in the desired data tier because there
   are not enough nodes in the [data_content] tier..."
→ action: "Increase the number of nodes in this tier or decrease the
   number of replica shards in the affected indices."
→ help_url: "https://ela.st/tier-capacity"
→ affected_resources.indices: ["health_test"]

真实在同一时刻查老的_cluster/health，对比两者给出的信息量真实有多大的差距

代码GET /_cluster/health

验证：_cluster/health只给了一个干巴巴的unassigned_shards:1这个数字，完全没有任何解释，真实需要靠人自己去猜根因和解决办法

实测 · 本机执行输出 
同一时刻的_cluster/health:
→ status: "yellow"
→ unassigned_shards: 1
→ （真实没有任何cause、action、help_url或者具体是哪个索引）
这组真实对比把两代健康检查接口的差距讲得很清楚：老的_cluster/health真实只告诉你"有1个分片没分配好"这个事实，剩下的工作——到底是哪个索引、为什么分配不了、应该怎么解决——真实全部要靠人自己去排查；而_health_report真实把这整条排查链路直接打包好交给你：具体哪个索引（health_test）、真实的根本原因（节点数不够分配副本）、真实可执行的解决办法（加节点或者减副本数），甚至真实还给了一个官方文档的链接方便进一步查阅。这正是本系列前面很多篇文章里反复手动排查过的那类问题（分片分配拒绝、水位触发等），_health_report真实把其中相当一部分的诊断工作直接自动化了。

收尾：真实清理测试索引，确认集群恢复green

代码DELETE /health_test

分步演示：从_health_report的8个独立indicator，到真实的yellow诊断信息，再到跟老接口的直接对比

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。

_health_report真实把排查链路打包好直接交给使用者，而_cluster/health只给干巴巴的数字
这一步新验证的健康检查场景

    本文用到的工具

    • 本机真实部署的 Elasticsearch 8.15.0（单节点，tar包直接启动）
    • 真实的 _health_report API 与 _cluster/health 对比
    京ICP备2026067502号-1京公网安备11010502063487号