集群健康是对集群的所有信息进行高度概述，而节点统计值 API 提供一个让人眼花缭乱的统计数据的数组，包含集群的每一个节点统计值。

节点统计值 API 可以通过如下命令执行：

在输出内容的开头，我们可以看到集群名称和我们的第一个节点：

节点是排列在一个哈希里，以节点的 UUID 作为键名。还显示了节点网络属性的一些信息，这些值对调试诸如节点未加入集群这类自动发现问题很有用。通常你会发现是端口用错了，或者节点绑定在错误的 IP 地址/网络接口上了。

索引部分

索引（indices）部分列出了这个节点上所有索引的聚合过的统计值 ：

● docs 展示节点内存有多少文档，包括还没有从段里清除的已删除文档数量。

● store 部分显示节点耗用了多少物理存储。这个指标包括主分片和副本分片在内。如果限流时间很大，那可能表明你的磁盘限流设置得过低。

● indexing 显示已经索引了多少文档。这个值是一个累加计数器，在文档被删除时，数值不会下降，在发生文档更新等内部索引操作时，值会增加。此外还列出了索引操作耗费的时间，正在索引的文档数量，以及删除操作的类似统计值。

● get 显示通过 ID 获取文档的接口相关的统计值。包括对单个文档的 GET 和 HEAD 请求。

● search 描述在活跃中的搜索（open_contexts）数量、查询的总数量、以及自节点启动以来在查询上消耗的总时间。用 query_time_in_millis / query_total 计算的比值，可以用来粗略的评价你的查询有多高效。比值越大，每个查询花费的时间越多，你应该要考虑调优了。

● fetch 统计值展示了查询处理的后一半流程（query-then-fetch 里的 fetch）。如果 fetch 耗时比 query 还多，说明磁盘较慢，或者获取了太多文档，或者可能搜索请求设置了太大的分页（比如，size: 10000）。

● merges 包括了 Lucene 段合并相关的信息。它会告诉你目前在运行几个合并，合并涉及的文档数量，正在合并的段的总大小，以及在合并操作上消耗的总时间。

● 在你的集群写入压力很大时，合并统计值非常重要。合并要消耗大量的磁盘 I/O 和 CPU 资源。如果你的索引有大量的写入，同时又发现大量的合并数，一定要去阅读索引性能技巧。

● filter_cache 展示了已缓存的过滤器位集合所用的内存数量，以及过滤器被驱逐出内存的次数。过多的驱逐数 可能 说明你需要加大过滤器缓存的大小，或者你的过滤器不太适合缓存（比如它们因为高基数而在大量产生，就像是缓存一个 now 时间表达式）。

● 不过，驱逐数是一个很难评定的指标。过滤器是在每个段的基础上缓存的，而从一个小的段里驱逐过滤器，代价比从一个大的段里要廉价的多。有可能你有很大的驱逐数，但是它们都发生在小段上，也就意味着这些对查询性能只有很小的影响。把驱逐数指标作为一个粗略的参考。如果你看到数字很大，检查一下你的过滤器，确保他们都是正常缓存的。不断驱逐着的过滤器，哪怕都发生在很小的段上，效果也比正确缓存住了的过滤器差很多。

● field_data 显示 fielddata 使用的内存， 用以聚合、排序等等。这里也有一个驱逐计数。和 filter_cache 不同的是，这里的驱逐计数是很有用的：这个数应该或者至少是接近于 0。因为 fielddata 不是缓存，任何驱逐都消耗巨大，应该避免掉。如果你在这里看到驱逐数，你需要重新评估你的内存情况，fielddata 限制，请求语句，或者这三者。

● segments 会展示这个节点目前正在服务中的 Lucene 段的数量。 这是一个重要的数字。大多数索引会有大概 50–150 个段，哪怕它们存有 TB 级别的数十亿条文档。段数量过大表明合并出现了问题（比如，合并速度跟不上段的创建）。注意这个统计值是节点上所有索引的汇聚总数。

● memory 统计值展示了 Lucene 段自己用掉的内存大小。 这里包括底层数据结构，比如倒排表，字典，和布隆过滤器等。太大的段数量会增加这些数据结构带来的开销，这个内存使用量就是一个方便用来衡量开销的度量值。

操作系统和进程部分

OS 和Process 部分基本是自描述的，不会在细节中展开讲解。它们列出来基础的资源统计值，比如 CPU 和负载。OS 部分描述了整个操作系统，而 Process 部分只显示 Elasticsearch 的 JVM 进程使用的资源情况。

这些都是非常有用的指标，不过通常在你的监控技术栈里已经都测量好了。统计值包括下面这些：

● CPU

● 负载

● 内存使用率

● Swap 使用率

● 打开的文件描述符

JVM部分

jvm部分包括了运行 Elasticsearch 的 JVM 进程一些很关键的信息。最重要的，它包括了垃圾回收的细节，这对你的 Elasticsearch 集群的稳定性有着重大影响。

线程池部分

Elasticsearch 在内部维护了线程池。这些线程池相互协作完成任务，有必要的话相互间还会传递任务。通常来说，你不需要配置或者调优线程池，不过查看它们的统计值有时候还是有用的，可以洞察你的集群表现如何。

这有一系列的线程池，但以相同的格式输出： 

每个线程池会列出已配置的线程数量（threads），当前在处理任务的线程数量（active），以及在队列中等待处理的任务单元数量（queue）。

如果队列中任务单元数达到了极限，新的任务单元会开始被拒绝，你会在 rejected 统计值上看到它反映出来。这通常是你的集群在某些资源上碰到瓶颈的信号。因为队列满意味着你的节点或集群在用较高的速度运行，但依然跟不上工作的蜂拥而入。

值得关注的线程池部分有：

● indexing

普通的索引请求的线程池

● bulk

批量请求，和单条的索引请求不同的线程池

● get

Get-by-ID 操作

● search

所有的搜索和查询请求

● merging

专用于管理 Lucene 合并的线程池

文件系统和网络部分

继续向下阅读 /_node/stats API，你会看到一串和你的文件系统相关的统计值：可用空间，数据目录路径，磁盘 I/O 统计值，等等。如果你没有监控磁盘可用空间的话，可以从这里获取这些统计值。磁盘 I/O 统计值也很方便，不过通常那些更专门的命令行工具（比如 iostat ）会更有用些。

显然，Elasticsearch 在磁盘空间满的时候很难运行——所以请确保不会这样。

还有两个跟网络统计值相关的部分：

● transport 显示和 传输地址 相关的一些基础统计值。包括节点间的通信（通常是 9300 端口）以及任意传输客户端或者节点客户端的连接。如果看到这里有很多连接数不要担心；Elasticsearch 在节点之间维护了大量的连接。

● http 显示 HTTP 端口（通常是 9200）的统计值。如果你看到 total_opened 数很大而且还在一直上涨，这是一个明确信号，说明你的 HTTP 客户端里有没启用 keep-alive 长连接的。持续的 keep-alive 长连接对性能很重要，因为连接、断开套接字是很昂贵的（而且浪费文件描述符）。请确认你的客户端都配置正确。

断路有

fielddata 断路器相关的统计值： 

这里你可以看到断路器的最大值（比如，一个请求申请更多的内存时会触发断路器）。这个部分还会让你知道断路器被触发了多少次，以及当前配置的间接开销。间接开销用来铺垫评估，因为有些请求比其他请求更难评估。

主要需要关注的是 tripped 指标。如果这个数字很大或者持续上涨，这是一个信号，说明你的请求需要优化，或者你需要添加更多内存（单机上添加，或者通过添加新节点的方式）。