Elasticsearch集群_stats API不同节点返回值存在差异问题问询

咱们先来拆解下你遇到的这个问题，其实这要么是正常现象，要么是对API的小误解，具体来看：

核心原因分析 #

首先得明确两个API的区别（怕你可能搞混了）：

• _cluster/stats：返回整个集群的汇总统计数据，理论上不管你请求哪个节点，返回的集群级fs汇总应该一致；
• _nodes/stats：返回单个或多个节点的本地统计数据，每个节点返回的就是自己的fs状态。

从你给出的数据来看，主节点的总磁盘容量约15.8TB，两个热节点约16.2TB，而且热节点之间的空闲量还有细微差异，这更符合单个节点的统计特征，所以大概率是你误把_nodes/{nodeId}/stats的结果当成了_cluster/stats的返回。

如果确实是调用_cluster/stats出现了差异，那可能是这两种情况：

• 节点间状态同步延迟：Elasticsearch节点通过gossip协议同步集群状态，当某个节点的fs统计刚更新（比如刚完成了一批索引写入），还没同步到其他节点时，不同节点返回的集群汇总数据会暂时不一致，等一会儿再请求就会统一；
• 磁盘使用实时波动：热节点一直在处理数据写入/删除，磁盘空闲量是实时变化的，比如analyzer1和analyzer2的free_in_bytes有几百MB的差异，这完全是正常的，毕竟磁盘IO是动态的。

验证小技巧 #

你可以做这几步来确认：

• 计算主节点、analyzer1、analyzer2的total_in_bytes总和，然后调用_cluster/stats，看返回的集群总容量是否和这个总和一致——如果一致，说明之前的差异是单个节点的统计；
• 多次请求同一个节点的_cluster/stats，观察fs数据是否稳定；
• 直接调用_nodes/stats，对比返回的每个节点的fs数据和你之前拿到的结果，就能确认是不是API调用混淆了。

总结 #

如果是不同节点硬件配置不同导致的单个节点fs统计差异，那完全是正常的；如果是集群级汇总的临时差异，那就是同步延迟导致的，不用太担心，过会儿就会统一。

内容的提问来源于stack exchange，提问作者l0calh0st