elasticsearch 性能监控基础(转)

原文转自：https://www.cnblogs.com/smail-bao/p/7448392.html

非常好的文章，感谢作者的总结分享。

一、Elasticsearch 是什么

Elasticsearch是一款用Java编写的开源分布式文档存储和搜索引擎，可以用于near real-time存储和数据检索。

 Monitoring 101 series 
所有这些指标都可以通过Elasticsearch的API以及Elasticsearch的Marvel和Datadog等通用监控工具访问。

数据库系统中的读写请求。 Elasticsearch提供与搜索过程的两个主要阶段（查询和获取）相对应的度量。 下图显示了从开始到结束的搜索请求的路径。

1.客户端向Node 2 发送搜索请求

2.Node 2（此时客串协调角色）将查询请求发送到索引中的每一个分片的副本

3.每个分片（Lucene实例，迷你搜素引擎）在本地执行查询，然后将结果交给Node 2。Node 2 sorts and compiles them into a global priority queue.

4.Node 2发现需要获取哪些文档，并向相关的分片发送多个GET请求。

5.每个分片loads documents然后将他们返回给Node 2

6.Node 2将搜索结果交付给客户端

节点处理，由谁分发，就由谁交付

如果您使用Elasticsearch主要用于搜索，或者如果搜索是面向客户的功能。您应该监视查询延迟和设定阈值。 监控关于查询和提取的相关指标很重要，可以帮助您确定搜索随时间的变化。 例如，您可能希望跟踪查询请求的尖峰和长期增长，以便您可以做好准备。

Metric description	Name	[Metric type][monitoring-101-blog]
Total number of queries	indices.search.query_total	Work: Throughput
Total time spent on queries	indices.search.query_time_in_millis	Work: Performance
Number of queries currently in progress	indices.search.query_current	Work: Throughput
Total number of fetches	indices.search.fetch_total	Work: Throughput
Total time spent on fetches	indices.search.fetch_time_in_millis	Work: Performance
Number of fetches currently in progress	indices.search.fetch_current	Work: Throughput

搜索性能指标的要点：

• Query load:监控当前正在进行的查询数量可以让您了解群集在任何特定时刻处理的请求数量。您可能还想监视搜索线程池队列的大小，稍后我们将在本文中进一步解释链接。
• Query latency: 虽然Elasticsearch没有明确提供此度量标准，但监控工具可以帮助您使用可用的指标来计算平均查询延迟，方法是以定期查询总查询次数和总经过时间。 如果延迟超过阈值，则设置警报，如果触发，请查找潜在的资源瓶颈，或调查是否需要优化查询。
• Fetch latency: 搜索过程的第二部分，即提取阶段通常比查询阶段要少得多的时间。 如果您注意到这一指标不断增加，可能是磁盘性能不好、highlighting影响、requesting too many results的原因。

操作系统的文件系统缓存来快速可靠地提供请求。 
许多变量决定了Elasticsearch是否成功读取文件系统缓存，如果segment file最近由es写入到磁盘，它已经in the cache。然而如果节点被关闭并重新启动，首次查询某个segment的时候，数据很可能是必须从磁盘中读取，这是确保您的群集保持稳定并且节点不会崩溃的重要原因之一。 
总的来说，监控节点上的内存使用情况非常重要，并且尽可能多给es分配RAM，so it can leverage the speed of the file system cache without running out of space。

Linux系统每个进程只允许1024个文件描述符。 在生产中使用Elasticsearch时，您应该将操作系统文件描述符计数重新设置为更大，如64,000。

HTTP connections:

Metric description	Name	[Metric type][monitoring-101-blog]
Number of HTTP connections currently open	http.current_open	Resource: Utilization
Total number of HTTP connections opened over time	http.total_opened	Resource: Utilization

可以用任何语言发送请求，但Java将使用RESTful API通过HTTP与Elasticsearch进行通信。 如果打开的HTTP连接总数不断增加，可能表示您的HTTP客户端没有正确建立持久连接。 重新建立连接会在您的请求响应时间内添加额外的毫秒甚至秒。 确保您的客户端配置正确，以避免对性能造成负面影响，或使用已正确配置HTTP连接的官方Elasticsearch客户端。

5、集群健康和节点可用性

指标要点：

• Cluster status: 如果集群状态为黄色，则至少有一个副本分片未分配或丢失。 搜索结果仍将完成，但如果更多的分片消失，您可能会丢失数据。 
  红色的群集状态表示至少有一个主分片丢失，并且您缺少数据，这意味着搜索将返回部分结果。 您也将被阻止索引到该分片。 Consider setting up an alert to trigger if status has been yellow for more than 5 min or if the status has been red for the past minute.

• Initializing and unassigned shards: 当首次创建索引或者重启节点，其分片将在转换到“started”或“unassigned”状态之前暂时处于“initializing”状态，此时主节点正在尝试将分片分配到集群中的数据节点。 如果您看到分片仍处于初始化或未分配状态太长时间，则可能是您的集群不稳定的警告信号。

6、资源saturation and errors

es节点使用线程池来管理线程如何消耗内存和CPU。 由于线程池设置是根据处理器数量自动配置的，所以调整它们通常没有意义。However, it’s a good idea to keep an eye on queues and rejections to find out if your nodes aren’t able to keep up; 如果无法跟上，您可能需要添加更多节点来处理所有并发请求。Fielddata和过滤器缓存使用是另一个要监视的地方，as evictions may point to inefficient queries or signs of memory pressure.

Thread pool queues and rejections 
每个节点维护许多类型的线程池; 您要监视的确切位置将取决于您对es的具体用途，一般来说，监控的最重要的是搜索，索引，merge和bulk，它们与请求类型（搜索，索引，合并和批量操作）相对应。 
线程池队列的大小反应了当前等待的请求数。 队列允许节点跟踪并最终服务这些请求，而不是丢弃它们。 一旦超过线程池的maximum queue size，Thread pool rejections就会发生。

指标要点：

• Thread pool queues: 大队列不理想，因为它们耗尽资源，并且如果节点关闭，还会增加丢失请求的风险。如果你看到线程池rejected稳步增加，你可能希望尝试减慢请求速率（如果可能），增加节点上的处理器数量或增加群集中的节点数量。 如下面的截图所示，查询负载峰值与搜索线程池队列大小的峰值相关，as the node attempts to keep up with rate of query requests。 
  

• Bulk rejections and bulk queues: 批量操作是一次发送许多请求的更有效的方式。 通常，如果要执行许多操作（创建索引或添加，更新或删除文档），则应尝试以批量操作发送请求，而不是发送许多单独的请求。 
  bulk rejections 通常与在一个批量请求中尝试索引太多文档有关。根据Elasticsearch的文档，批量rejections并不是很需要担心的事。However, you should try implementing a linear or exponential backoff strategy to efficiently deal with bulk rejections。

• Cache usage metrics: 每个查询请求都会发送到索引中的每个分片的每个segment中，Elasticsearch caches queries on a per-segment basis to speed up response time。另一方面，如果您的缓存过多地堆积了这些heap，那么它们可能会减慢速度，而不是加快速度！ 
  在es中，文档中的每个字段可以以两种形式存储：exact value 和 full text。 
  例如，假设你有一个索引，它包含一个名为location的type。每个type的文档有个字段叫city。which is stored as an analyzed string。你索引了两个文档，一个的city字段为“St. Louis”，另一个的city字段为“St. Paul”。在倒排索引中存储时将变成小写并忽略掉标点符号，如下表

  Term	Doc1	Doc2
  st	x	x
  louis	x
  paul		x

分词的好处是你可以搜索st。结果会搜到两个。如果将city字段保存为exact value，那只能搜“St. Louis”, 或者 “St. Paul”。 
Elasticsearch使用两种主要类型的缓存来更快地响应搜索请求：fielddata和filter。

• Fielddata cache: fielddata cache 在字段排序或者聚合时使用。 a process that basically has to uninvert the inverted index to create an array of every field value per field, in document order. For example, if we wanted to find a list of unique terms in any document that contained the term “st” from the example above, we would: 
  1.扫描倒排索引查看哪些文档（documents）包含这个term（在本例中为Doc1和Doc2） 
  2.对1中的每个步骤，通过索引中的每个term 从文档中来收集tokens，创建如下结构：

  Doc	Terms
  Doc1	st, louis
  Doc2	st, paul

  3.现在反向索引被再反向，从doc中compile 独立的tokens(st, louis, and paul)。compile这样的fielddata可能会消耗大量堆内存。特别是大量的documents和terms的情况下。 所有字段值都将加载到内存中。

  对于1.3之前的版本，fielddata缓存大小是无限制的。 从1.3版开始，Elasticsearch添加了一个fielddata断路器，如果查询尝试加载需要超过60％的堆的fielddata，则会触发。

• Filter cache: 过滤缓存也使用JVM堆。 在2.0之前的版本中，Elasticsearch自动缓存过滤的查询，最大值为堆的10％，并且将最近最少使用的数据逐出。 从版本2.0开始，Elasticsearch会根据频率和段大小自动开始优化其过滤器缓存（缓存仅发生在索引中少于10,000个文档的段或小于总文档的3％）。 因此，过滤器缓存指标仅适用于使用2.0之前版本的Elasticsearch用户。 
  例如，过滤器查询可以仅返回年份字段中的值在2000-2005范围内的文档。 在首次执行过滤器查询时，Elasticsearch将创建一个与其相匹配的文档的位组（如果文档匹配则为1，否则为0）。 使用相同过滤器后续执行查询将重用此信息。 无论何时添加或更新新的文档，也会更新bitset。 如果您在2.0之前使用的是Elasticsearch版本，那么您应该关注过滤器缓存以及驱逐指标（更多关于以下内容）。

  Metric description	Name	[Metric type][monitoring-101-blog]
  Size of the fielddata cache (bytes)	indices.fielddata.memory_size_in_bytes	Resource: Utilization
  Number of evictions from the fielddata cache	indices.fielddata.evictions	Resource: Saturation
  Size of the filter cache (bytes) (only pre-version 2.x)	indices.filter_cache.memory_size_in_bytes	Resource: Utilization
  Number of evictions from the filter cache (only pre-version 2.x)	indices.filter_cache.evictions	Resource: Saturation

• Fielddata cache evictions: 理想情况下，我们需要限制fielddata evictions的数量，因为他们很吃I/O。如果你看到很多evictions并且你又不能增加内存。es建议限制fielddata cache的大小为20%的heap size。这些是可以在elasticsearch.yml中进行配置的。当fielddata cache达到20%的heap size时，es将驱逐最近最少使用的fielddata,然后允许您将新的fielddata加载到缓存中。 
  es还建议使用doc values，因为它们与fielddata的用途相同。由于它们存储在磁盘上，它们不依赖于JVM heap。尽管doc values不能被用来分析字符串， they do save fielddata usage when aggregating or sorting on other types of fields。在2.0版本后，doc values会在文档被index的时候自动创建，which has reduced fielddata/heap usage for many users。

• Filter cache evictions: 如前所述，filter cache eviction 指标只有在es2.0之前的版本可用。每个segment都维护自己的filter cache eviction。因为eviction在大的segment上操作成本较高，没有的明确的方法来评估eviction。但是如果你发现eviction很频繁，表明你并没有很好地利用filter，此时你需要重新创建filter，即使放弃原有的缓存，你也可能需要调整查询方式（用bool query 而不是 and/or/not filter）。

• Pending tasks:

  Metric description	Name	[Metric type][monitoring-101-blog]
  Number of pending tasks	pending_task_total	Resource: Saturation
  Number of urgent pending tasks	pending_tasks_priority_urgent	Resource: Saturation
  Number of high-priority pending tasks	pending_tasks_priority_high	Resource: Saturation

  pending task只能由主节点来进行处理，这些任务包括创建索引并将shards分配给节点。任务分优先次序。如果任务的产生比处理速度更快，将会产生堆积。待处理任务的数量是您的群集运行平稳的良好指标，如果您的主节点非常忙，并且未完成的任务数量不会减少，我们需要仔细检查原因。

• Unsuccessful GET requests: GET请求比正常的搜索请求更简单 - 它根据其ID来检索文档。 get-by-ID请求不成功意味着找不到文档ID

• 原文转自：https://www.cnblogs.com/smail-bao/p/7448392.html