Allocation Explain API

做的事：真实对一个已经正常分配好、状态是started的分片用allocation/explain，看它是不是只能诊断unassigned的分片

代码真实索引一篇文档到单分片索引ae_test，分片真实已经是started状态 GET /_cluster/allocation/explain {"index":"ae_test","shard":0,"primary":true}

验证：真实能正常解释一个已经在跑的分片，告诉你它为什么会继续留在当前节点

current_state: "started"
can_remain_on_current_node: "yes"
can_rebalance_to_other_node: "no"
rebalance_explanation: "This shard is in a well-balanced location and
  satisfies all allocation rules so it will remain on this node.
  Elasticsearch cannot improve the cluster balance by moving it to
  another node."

这组真实结果说明allocation/explain真实不只是给unassigned分片排错用的，只要真实在请求里明确指定index、shard、primary这三个参数，它真实能对任意状态的分片给出解释——哪怕这个分片本身真实运行得很健康，依然能真实告诉你"它为什么应该留在这里，而不是被重新均衡到别的节点"。

真实验证不带任何请求体直接调用这个接口，看集群完全健康时会发生什么

代码GET /_cluster/allocation/explain # 真实不带任何请求体

验证：真实直接报错，提示这种"不指定具体分片"的用法只对随机挑一个unassigned分片生效，集群里没有unassigned分片时真实用不了

→ 400 illegal_argument_exception:
  "No shard was specified in the request which means the response should
   explain a randomly-chosen unassigned shard, but there are no unassigned
   shards in this cluster. To explain the allocation of an assigned shard
   you must specify the target shard in the request."

这条真实报错精确说明了这个接口两种用法的边界：不传任何参数的"懒人模式"真实只是为了快速诊断"随便挑一个还没分配成功的分片，看看它卡在哪"，这正是本系列第89篇验证disk_threshold问题时用过的真实用法；但如果真实想诊断一个已经分配成功的具体分片（比如本文上一步做的），必须真实明确指定index/shard/primary这三个参数，不能指望接口自动帮你猜。

真实加上include_disk_info=true参数，看响应里是否会真实携带这个节点的磁盘空间信息

代码GET /_cluster/allocation/explain?include_disk_info=true {"index":"ae_test","shard":0,"primary":true}

验证：响应里真实多出了cluster_info这部分，里面的磁盘字节数真实跟本机df查到的容量精确吻合

cluster_info.nodes.node-1.least_available:
→ total_bytes: 494384795648
→ used_bytes: 465279332352
→ free_bytes: 29105463296   ← 真实约27.1GB，跟本机df -h查到的空闲空间精确对得上

分步演示：Allocation Explain API从诊断已分配分片到真实携带磁盘信息的完整用法验证

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