Elasticsearch 基础知识要点与性能监控

2023-08-30 08:32:46

本文的来源是我翻译国外的一篇技术博客，感谢原作者Emily Chang，原文地址通过如下的知识，我们能大致学到关于ES的一些基本知识，进而对elasticsearch的性能进行监控和调优

注意elasticsearch的版本不同，此处的描述可能会有稍许偏差

一、Elasticsearch 是什么

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

1. Elasticsearch简要组成

在开始探索性能指标之前，让我们来看看Elasticsearch的工作原理，在elasticsearch中，集群由一个或者更多的节点组成，如下图：

每个节点是Elasticsearch的单个运行实例，其“elasticsearch.yml”配置文件指定其所属的集群（“cluster.name”）以及它可以是什么类型的节点。配置文件中设置的任何属性（包括集群名称）也可以通过命令行参数指定。上图中的集群由一个专用主节点和五个数据节点组成。三种最常见的es节点类型有：

master备选节点

默认情况下（不动配置），每个节点均为master备选节点。每个集群都会自动从所有master备选节点中选择一个成为master节点。在当前master节点遇到故障（例如停电，硬件故障或内存不足错误）的情况下，重新选举产生新的master节点。master节点负责协调集群任务，比如跨节点的shards分发、创建和删除索引等。

master节点也能同时作为数据节点，但在比较大的集群中，master节点一般不存储数据（通过设置node.data : false 来设置），以提高可靠性。在高可用环境中，节点任务明确、分离可以保证任务单一可靠。（专人干专事）
data节点

默认情况下（不动配置），每个节点都是数据节点，以shards的形式存储数据并执行与索引，搜索和聚合数据相关的操作。

在大集群中，我们可以通过设置node.master : false来设置该节点为专用数据节点。确保这些节点具有足够的资源来处理与数据相关的请求，而不需要承担与集群相关的管理任务类的工作负载。
client 节点

如果将node.master 和node.data都设置为false。那么该节点就是一个client节点。该client节点被设计为负载均衡器的角色，以帮助路由索引和搜索请求。

client节点有助于承担部分搜索工作量，以便数据和主节点节点可以专注于其核心任务。client节点并不是必须的，因为数据节点能够自己处理请求路由。如果你的search/index workload比较重，可以在集群中配一个client节点。

2. Elasticsearch 如何组织数据

在es中，相关联的数据通常存储在相同的索引中，每个索引包含一组JSON格式的相关联文档。Elasticsearch的全文搜索秘诀是Lucene的倒排索引。在索引（存入）数据的时候，es会自动为每个字段创建一个倒排索引，倒排索引将索引的词（terms）映射(map)到包含该词的文档（document）中。index被存储在一个或多个主副shard中，每个shard都是一个完整的Lucenes实例，是一个完整的迷你搜索引擎。

创建索引时，可以指定主分片的数量以及每个主节点的副本数，默认为五个分片和一个副本。索引创建后，分片数不能被修改。如果要修改可能需要reindex。副本数可以在后期被修改。为了防止数据丢失，主节点的调度机制会确保主副分片不会出现在同一个数据节点上。

二、我们要监控哪些Elasticsearch metric

Elasticsearch提供了大量的Metric，可以帮助您检测到问题的迹象，在遇到节点不可用、out-of-memory、long garbage collection times的时候采取相应措施。一些关键的检测如下：

Search and indexing performance（搜索、索引性能）
Memory and garbage collection
Host-level system and network metrics
Cluster health and node availability
Resource saturation（饱和） and errors

这里提供了一个metric搜集和监控的框架 Monitoring 101 series ，所有这些指标都可以通过Elasticsearch的API以及Elasticsearch的Marvel和Datadog等通用监控工具访问。

1. 搜索性能指标

搜索请求是Elasticsearch中的两个主要请求类型之一，另一个是索引请求。这些请求有时类似于传统数据库系统中的读写请求。 Elasticsearch提供与搜索过程的两个主要阶段（查询和获取）相对应的度量。 下图显示了从开始到结束的搜索请求的路径。

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

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

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

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

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

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

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

搜索性能指标的要点：

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

2. 索引性能指标

索引请求类似于传统数据库系统中的写入请求，如果es的写入工作量很重，那么监控和分析您能够如何有效地使用新数据更新索引非常重要。在了解指标之前，让我们来探索Elasticsearch更新索引的过程，在新数据被添加进索引、更新或删除已有数据，索引中的每个shard都有两个过程：refresh 和 flush Index fresh 新索引的文档不能立马被搜索的。首先，它们被写入一个内存中的缓冲区（in-memory buffer），等待下一次索引刷新，默认情况下每秒一次。刷新是以in-memory buffer为基础创建in-memory segment的过程（The refresh process creates a new in-memory segment from the contents of the in-memory buffer ）。这样索引进的文档才能是可被搜索的，创建完segment后，清空buffer 如下图：

**A special segment on segments **

索引由shards构成，shard又由很多segments组成，The core data structure from Lucene, a segment is essentially a change set for the index. 这些segments在每次刷新的时候被创建，随后会在后台进行合并，以确保资源的高效利用（每个segment都要占file handles、memory、CPU） segments 是mini的倒排索引，这些倒排索引映射了terms到documents。每当搜索索引的时候，每个主副shards都必须被遍历。更深一步说shards上的每个segment会被依次搜索。 segment是不可变的，因此updating a document 意味着如下：

writing the information to a new segment during the refresh process
marking the old information as deleted

当多个outdated segment合并后才会被删除。（意思是不单个删除，合并后一起删）。

Index flush

在新索引的document添加到in-memory buffer的同时，它们也会被附加到分片的translog（a persistent, write-ahead transaction log of operations）中。每隔30分钟，或者每当translog达到最大大小（默认情况下为512MB）时，将触发flush 。在flush 期间，在in-memory buffer上的documents会被refreshed（存到新的segments上），所有内存中的segments都提交到磁盘，并且translog被清空。 translog有助于防止节点发生故障时的数据丢失。 It is designed to help a shard recover operations that may otherwise have been lost between flushes. 这个translog每5秒将操作信息（索引，删除，更新或批量请求（以先到者为准））固化到磁盘上。

Elasticsearch提供了许多指标，可用于评估索引性能并优化更新索引的方式。

索引性能指标的要点：

Indexing latency： Elasticsearch不会直接公开此特定指标，但是监控工具可以帮助您从可用的index_total和index_time_in_millis指标计算平均索引延迟。如果您注意到延迟增加，您可能会一次尝试索引太多的文档（Elasticsearch的文档建议从5到15兆字节的批量索引大小开始，并缓慢增加）。如果您计划索引大量文档，并且不需要立即可用于搜索。则可以通过减少刷新频率来优化。索引设置API使您能够暂时禁用刷间隔

curl -XPUT <nameofhost>:9200/<name_of_index>/_settings -d '{

 "index" : {

 "refresh_interval" : "-1"

 }

}'

完成索引后，您可以恢复为默认值“1s”</name_of_index>

Flush latency: 在flush完成之前，数据不会被固化到磁盘中。因此追踪flush latency很有用。比如我们看到这个指标稳步增长，表明磁盘性能不好。这个问题将最终导致无法向索引添加新的数据。可以尝试降低index.translog.flush_threshold_size。这个设置决定translog的最大值（在flush被触发前）

3. 内存使用和GC指标

在运行Elasticsearch时，内存是您要密切监控的关键资源之一。 Elasticsearch和Lucene以两种方式利用节点上的所有可用RAM：JVM heap和文件系统缓存。 Elasticsearch运行在Java虚拟机（JVM）中，这意味着JVM垃圾回收的持续时间和频率将成为其他重要的监控领域。

JVM heap: A Goldilocks tale

Elasticsearch强调了JVM堆大小的重要性，这是“正确的” - 不要将其设置太大或太小，原因如下所述。一般来说，Elasticsearch的经验法则是将少于50％的可用RAM分配给JVM堆，而不会超过32 GB。您分配给Elasticsearch的堆内存越少，Lucene就可以使用更多的RAM，这很大程度上依赖于文件系统缓存来快速提供请求。但是，您也不想将堆大小设置得太小，因为应用程序面临来自频繁GC的不间断暂停，可能会遇到内存不足错误或吞吐量降低的问题 Elasticsearch的默认安装设置了1 GB的JVM heap大小，对于大多数用例来说，太小了。您可以将所需的heap大小导出为环境变量并重新启动Elasticsearch:

export ES_HEAP_SIZE=10g

如上我们设置了es heap大小为10G，通过如下命令进行校验：

curl -XGET http://:9200/_cat/nodes?h=heap.max

Garbage collection

Elasticsearch依靠垃圾收集过程来释放heap memory。因为垃圾收集使用资源（为了释放资源！），您应该注意其频率和持续时间，以查看是否需要调整heap大小。设置过大的heap会导致GC时间过长，这些长时间的停顿会让集群错误的认为该节点已经脱离。

JVM指标的要点：

JVM heap in use: 当JVM heap 使用率达到75％时，es启动GC。如上图所示，可以监控node的JVM heap，并且设置一个警报，确认哪个节点是否一直超过%85。如果一直超过，则表明垃圾的收集已经跟不上垃圾的产生。此时可以通过增加heap（需要满足建议法则不超过32G），或者通过增加节点来扩展集群，分散压力。
JVM heap used vs. JVM heap committed: 与commit的内存（保证可用的数量）相比，了解当前正在使用多少JVM heap的情况可能会有所帮助。heap memory的图一般是个锯齿图，在垃圾收集的时候heap上升，当收集完成后heap下降。如果这个锯齿图向上偏移，说明垃圾的收集速度低于rate of object creation，这可能会导致GC时间放缓，最终OutOfMemoryErrors。
Garbage collection duration and frequency: Both young- and old-generation garbage collectors undergo “stop the world” phases, as the JVM halts execution of the program to collect dead objects。在此期间节点cannot complete any task。主节点每30秒会去检查其他节点的状态，如果任何节点的垃圾回收时间超过30秒，则会导致主节点任务该节点脱离集群。
Memory usage: 如上所述，es非常会利用除了分配给JVM heap的任何RAM。像Kafka一样，es被设计为依赖操作系统的文件系统缓存来快速可靠地提供请求。许多变量决定了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。

4. es主机的网络和系统

虽然Elasticsearch通过API提供了许多特定于应用程序的指标，但您也应该从每个节点收集和监视几个主机级别的指标。 Host指标要点：

Disk space: 如果数据很多，这个指标很关键。如果disk space 过小，讲不能插入或更新任何内容，并且节点会挂掉。可以使用Curator这样的工具来删除特定的索引以保持disk的可用性。如果不让删除索引，另外的办法是添加磁盘、添加节点。请记住analyzed field占用磁盘的空间远远高于non-analyzed fields。
I/O utilization: 由于创建，查询和合并segment，Elasticsearch会对磁盘进行大量写入和读取,于具有不断遇到大量I / O活动的节点的写入繁重的集群，Elasticsearch建议使用SSD来提升性能。

CPU utilization: 在每个节点类型的热图（如上所示）中可视化CPU使用情况可能会有所帮助。例如，您可以创建三个不同的图表来表示集群中的每组节点（例如，数据节点，主节点，客户端节点），如果看到CPU使用率的增加，这通常是由于搜索量大或索引工作负载引起的。如果需要，可以添加更多节点来重新分配负载。
Network bytes sent/received: 节点之间的通讯是集群平衡的关键。因此需要监控network来确保集群的health以及对集群的需求（例如，segment在节点之间进行复制或重新平衡）。 Elasticsearch提供有关集群通信的指标，但也可以查看发送和接收的字节数，以查看network接收的流量。
Open file descriptors: 文件描述符用于节点到节点的通信，客户端连接和文件操作。如果这个number达到了系统的最大值，则只有在旧的连接和文件操作关闭之后才能进行新的连接和文件操作。如果超过80％的可用文件描述符被使用，您可能需要增加系统的最大文件描述符数量。大多数Linux系统每个进程只允许1024个文件描述符。在生产中使用Elasticsearch时，您应该将操作系统文件描述符计数重新设置为更大，如64,000。
HTTP connections:

可以用任何语言发送请求，但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就会发生。