Elasticsearch正在蓬勃发展。与用于收集和处理日志的Logstash和用于在Elasticsearch中搜索和可视化数据的工具Kibana(又名“ELK”堆栈)一起，Elasticsearch的采用继续成长突飞猛进。实际使用Elasticsearch时，会生成大量指标。在这一篇博客文章中，我没有承担介绍ElasticSearch所有指标的艰巨任务，而是看看10个Elasticsearch重点指标。这对任何Elasticsearch新人都有帮助，对那些希望快速启动Elasticsearch性能监控的有经验的用户也会有所帮助。

这部分组中的大多数图表通过在一个图表中显示多个指标或将它们组织到仪表板中来进行度量。这样做是为了为我们正在探索的每个指标提供上下文。

首先，下面是我们要讨论的10个Elasticsearch指标的仪表板视图：

现在，我们逐一深入研究10个指标中的每一个，并了解如何解释它们。

1.集群健康 – 节点和分片（Nodes and shards）

与服务器的OS指标一样，集群运行状况是Elasticsearch的基本指标。它提供了运行节点的概述以及分发给节点的分片的状态。

将分片分配状态的计数器放在一张图中，可以看出集群如何随时间恢复。特别是在重新启动round-robin的升级过程中，了解群集分配分片所需的时间非常重要。

根据集群的特定设置，重新启动后分配分片的过程可能需要很长时间。集群API给出了对分片分配的一些控制。

2.节点性能 – CPU

和其他服务器一样，Elasticsearch的性能在很大程度上依赖于它所安装的机器。 CPU，内存使用情况和磁盘I/O是每个Elasticsearch节点的基本操作系统度量标准。

在Elasticsearch(或任何其他Java应用程序)的上下文中，建议您在CPU使用率突增时查看Java虚拟机(JVM)指标。在下面的例子中，高峰期的原因是垃圾收集活动较高。它可以被“collection count”识别，因为时间和数量增加了。

3.节点性能 – 内存使用情况

下图显示了一个很好的平衡。有一些备用内存，使用了近60％的内存，这为缓存内存留下了足够的空间(例如文件系统缓存)。你更通常看到的实际上是一张显示没有空闲内存的图表。人们对查看内存指标的新看法常常惊慌失措，认为没有可用内存意味着服务器没有足够的内存。其实并非如此。没有空闲的 memory 是件好事。如果服务器正在使用所有的内存，这很好。问题在于是否存在缓冲和缓存的内存(这是件好事)或者是否全部使用了。如果它全部被使用并且很少或没有缓冲和缓存的内存，那么服务器的RAM确实很低。因为Elasticsearch在Java虚拟机内部运行，所以JVM内存和垃圾收集是Elasticsearch-specific内存使用率需要查看的区域。

摘要仪表板

4.节点性能 – 磁盘I/O

搜索引擎大量使用存储设备，观看磁盘I/O可确保满足这一基本需求。由于减少磁盘I/O的原因有很多，所以它被认为是一个关键指标，是许多问题的一个很好的指标。检查索引和查询性能的有效性是一个很好的指标。读和写操作的区分直接表明了系统在特定用例中最需要的东西。通常情况下，查询的读取次数多于写入次数，尽管Elasticsearch的一个常见用例是日志管理，它通常具有较高的写入和较低的读取次数。当写入高于读取时，对索引的优化比查询优化更重要。这个例子显示了一个写入次数多于读取次数的日志系统

磁盘I/O的操作系统设置是所有其他优化的基础 – 调整磁盘I/O可避免潜在问题。如果磁盘I/O仍然不足，则应根据导致I/O的情况评估诸如优化碎片数量和大小，限制合并，替换慢磁盘，移动到SSD或添加更多节点等应对瓶颈。例如，在搜索时，如果索引不适合OS缓存，则磁盘会被删除。这可以通过多种不同的方式解决：通过添加更多的RAM或数据节点，或者通过减小索引大小(例如，使用time-based索引和别名)，或者更智能地将搜索限制为仅限于特定的分片或索引而不是全部搜索或者通过缓存等。

5. Java – 堆使用和垃圾收集

Elasticsearch在JVM中运行，因此JVM的最佳设置以及垃圾回收器和内存使用情况的监视都非常重要。有关JVM和操作系统内存设置需要考虑几件事情：

• 避免JVM进程交换到磁盘。在Unix，Linux和Mac OS X系统上：通过设置将进程地址空间锁定到RAM中bootstrap.mlockall=true在Elasticsearch配置文件和环境变量中MAX_LOCKED_MEMORY=unlimited(例如在/etc /default /elasticsearch中)。要在Linux中设置全局swappiness，请设置vm.swappiness=1在/etc/sysctl.conf中。在Windows上，可以简单地禁用虚拟内存。
• 定义Elasticsearch的堆内存通过设置ES_HEAP_SIZE环境变量(-Xmxjava选项)并遵循以下规则：  
  • 选择合理的最小堆内存以避免“out of memory”错误。最佳做法是设置最小值(-Xms)等于最大堆大小(-Xmx)，所以在运行时不需要分配额外的内存。例：./bin/elasticsearch -Xmx16g -Xms16g
  • 根据经验，将最大堆大小设置为可用物理RAM的50％。通常，不希望将超过50-60％的RAM分配给JVM堆。 JVM内存调整不是微不足道的，需要监视已使用和缓存的主内存以及JVM内存堆，内存池利用率和垃圾收集。
  • 不要超过32 GB的限制 – 如果您的服务器内存很大，运行更多Elasticsearch节点通常最好比超过32 GB的最大堆大小限制更好。总之，使用-Xmx32g或更高的结果在JVM中使用需要更多内存的更大的64位指针。如果你不走-Xmx31g，JVM将使用压缩的普通对象指针(OOP)使用更小的32位指针。

以下报告对于了解JVM如何管理内存的所有Java开发人员来说都是显而易见的。在这里，我们看到所有内存空间的相对大小及其总大小。如果您正在对JVM的性能(几乎每个Java应用程序都执行哪项操作)进行故障诊断，那么除了查看垃圾回收和内存池利用率报告(参见图“JVM pool utilization”)之外，这是首先检查的关键位置之一。在下面的图表中，我们看到一个健康的锯齿图案清楚地显示大型垃圾收集何时开始。

当我们观察多个Elasticsearch节点的摘要时，由于垃圾收集发生在不同机器上的不同时间，因此锯齿形图案不像平常那​​样尖锐。尽管如此，仍然可以识别该模式，可能是因为此群集中的所有节点都是同时启动的，并且正在遵循类似的垃圾回收循环。

6. Java – JVM池大小

内存池利用率图显示随着时间的推移每个池正在使用的百分比。当这些内存池中的一些(尤其是旧的Gen或Perm Gen)达到100％的利用率并停留在那里时，是时候担心了。其实，那时已经太迟了。你有这些指标设置的警报，对吧？当发生这种情况时，您可能会发现垃圾收集时间增加和CPU使用率增加，因为JVM一直试图释放(几乎)已满的任何池中的一些空间。如果垃圾收集活动太多，可能是由于以下原因之一：

• 一个特定的内存池被压垮，你可以调整(tuning)池子。
• JVM需要比分配给它更多的内存。在这种情况下，您可以降低您的需求或添加更多堆内存(ES_HEAP_SIZE)。理论上可以通过减少字段和过滤器缓存来降低Elasticsearch中使用的堆。在实践中，这样做会对查询性能产生负面影响。一种更好的方法来减少“not_analyzed“字段内存是使用”doc_values“索引映射/类型定义中的格式 – 它减少了查询时的内存占用量。

内存使用量的剧烈变化或长时间的垃圾回收运行可能表明危急情况。例如，在所有节点上的JVM内存的汇总视图中，内存中若干GB的内存可能表示节点离开集群，重新启动或重新配置以减少堆的使用。

摘要仪表板

7.搜索性能 – 请求延迟和请求率

在涉及搜索应用程序时，用户体验通常（typically）与搜索请求的延迟高度相关。例如，简单查询的请求延迟通常低于100.我们说“typically”是因为Elasticsearch经常用于分析查询，人们似乎仍然容忍场景中较慢的查询。有很多事情可能会影响查询的性能 – 构造不佳的查询，Elasticsearch集群配置不当，JVM内存和垃圾收集问题，磁盘IO等等。毋庸置疑，查询延迟是直接影响用户的指标，因此请确保您在其上放置了一些警报。基于查询延迟异常检测的警报在这里会很有帮助。下面的图表说明了这种情况。类似蓝色第95百分位查询延迟峰值的尖峰会使任何异常的基于检测的警报系统跳闸。请注意：Elasticsearch公开的查询延迟实际上是每个分片的查询延迟指标。它们不是整个查询的延迟值。

将请求延迟与请求速率一起放入图形中，立即提供了系统使用量以及响应方式的概述。

8.搜索性能 – 过滤器缓存

Elasticsearch中的大部分过滤器默认都被缓存。这意味着在第一次执行带有过滤器的查询时，Elasticsearch将查找与过滤器匹配的文档，并使用该信息构建名为“bitset”的结构。存储在bitset中的数据非常简单;它包含文档标识符以及给定的文档是否与过滤器匹配。随后执行具有相同过滤器的查询将重新使用存储在位集中的信息，从而通过节省I/O操作和CPU周期来加快查询执行速度。尽管过滤器相对较小，但如果您拥有大量数据和众多不同的过滤器，则它们可占用大部分JVM堆。因此，明智地设置“indices.cache.filter.size“属性来限制用于过滤器缓存的堆的数量。要找出此属性的最佳设置，请关注下图中显示的过滤器高速缓存大小和过滤器高速缓存驱逐度量标准。

9.搜索性能 – 字段数据缓存

如果使用聚合查询，则字段数据高速缓存大小和驱逐对于搜索性能通常很重要。字段数据构造费用昂贵 – 它需要将数据从磁盘提取到内存中。字段数据也用于排序和脚本字段。请记住，默认情况下(由于构建它的代价太大)，字段数据缓存是无限的。这当然会让你的JVM堆爆炸。为了避免令人讨厌的意外，请考虑通过设置“indices.fielddata.cache.size“属性并密切关注它以了解缓存的实际大小。

摘要仪表板

10.索引性能 – 刷新时间和合并时间

Elasticsearch在编制索引过程中发生了几件不同的事情，并且有许多指标可以监控其性能。在运行索引基准时，通常会使用固定数量的记录来计算索引率。不过，在制作过程中，您通常需要关注真正的索引速率。 Elasticsearch本身并不公开速率本身，但它确实暴露了可以计算速率的文档数量，如下所示：

这是另一个值得考虑的警报和/或异常检测指标。索引率突然上升和下降可能表明数据源存在问题。刷新时间和合并时间与索引性能密切相关，并影响整体集群性能。刷新时间随着Lucene索引(分片)的文件操作数量的增加而增加。将刷新间隔设置为较高的值(例如从1秒到30秒)可以实现刷新时间的缩短。当Elasticsearch(实际上是位于Elasticsearch核心的索引/搜索库Apache Lucene)合并很多分段(segments)，或者只是一个非常大的索引分段时，合并时间就会增加。这是正确合并策略，分片和分段设置的好指标。另外，磁盘I/O指示在CPU使用率高峰期间密集使用写入操作。因此，合并应该尽可能快。或者，如果合并太多影响集群，则可以限制合并吞吐量并增加“indices.memory.index_buffer_size“(在小堆上的节点上超过10％)来减少磁盘I/O，并且让并发执行的查询具有更多的CPU周期。

分段合并对于指数表现来说是一个非常重要的过程，但它并非没有副作用。较高的索引性能通常意味着允许存在更多的段，从而使查询稍微慢一些。

摘要仪表板

主要的Elasticsearch度量指标可以帮你发现很多问题！ – 在图表，图形，仪表板等中。Elasticsearch是一个high-powered平台，可以极好地满足您组织的搜索需求，但是，就像一辆速度极快的跑车一样，您必须知道要观看什么拨号以及如何换档让事情顺利进行。持续关注这10个指标并进行相应的分析将使您走上成功的Elasticsearch体验之路。

这篇文章是O’Reilly和Sematext合作的一部分。请参阅我们的编辑独立声明。