vlambda博客
学习文章列表

让我们从一个决定开始：云、虚拟或物理机器。如今，这些都是有效的选择，但并非总是如此。以前唯一的选择是为每个环境部分购买新服务器，或者与同一台机器上的其他应用程序共享资源。第二种选择非常有意义，因为它更具成本效益但会带来风险。一个应用程序的问题，尤其是与硬件相关的问题，将导致另一个应用程序出现问题。您可以想象您的一个应用程序使用了物理机的大部分 I/O 子系统，而所有其他应用程序都因此受到大量 I/O 等待和性能问题的困扰。虚拟化承诺应用程序分离和更方便的资源管理方式，但您仍然受到底层硬件的限制。每个意外流量都可能成为问题并影响服务可用性。想象一下，您的电子商务网站突然获得了大量客户。您不会为出现高峰和您拥有更多潜在客户而感到高兴，而是寻找一个可以购买将尽快提供的额外硬件的地方。

另一方面，云计算意味着更灵活的成本模型。我们可以在需要时轻松添加新机器。我们可以在预计负载更大时临时添加它们（例如，电子商务网站在圣诞节前），并且只需为实际使用的处理能力付费。只需在管理面板中单击几下。更重要的是，我们还可以设置自动扩展，即新的虚拟机可以在我们需要的时候自动出现。当我们不再需要它们时，基于云的软件也可以关闭它们。云具有许多优点，例如较低的初始成本、轻松发展业务的能力以及对资源需求的时间波动不敏感，但它也有一些缺陷。云服务器的成本比物理机的成本上升得更快。此外，大容量存储虽然实际上是无限的，但其特性（每秒操作数）比物理服务器更差。这有时对我们来说是个大问题，尤其是对于基于磁盘的存储，例如 Elasticsearch。

在实践中，像往常一样，选择可能很困难，但通过以下几点可以帮助您做出决定：

为了进一步讨论，假设我们想购买自己的服务器。我们现在在电脑商店，让我们买 东西吧！

在大多数情况下，这是最不重要的 部分。您可以选择任何现代 CPU 模型，但您应该知道更多的内核数量意味着更多的并发查询和索引线程。这将导致能够更快地索引数据，尤其是在复杂的分析和大量合并的情况下。

更多 GB 的 RAM 总是比更少 GB 的 RAM 更好。内存是必需的，尤其是对于聚合和排序。现在问题不大了，使用 Elasticsearch 2.0 和 doc 值，但是具有大量聚合的复杂查询仍然需要内存来处理数据。内存还用于索引缓冲区，可以提高索引速度，因为可以在内存中缓冲更多数据，从而减少磁盘的使用频率。如果您尝试使用比可用内存更多的内存，操作系统将使用硬盘作为临时空间（它开始交换），您应该不惜一切代价避免这种情况。请注意，您永远不应尝试强制 Elasticsearch 使用尽可能多的内存。第一个原因是 Java 垃圾收集器——更少的内存对 GC 更友好。第二个原因是操作系统实际上将未使用的内存用于缓冲区和磁盘缓存。实际上，当您的索引可以容纳此空间时，所有数据都是从这些缓存中读取的，而不是直接从磁盘中读取的。这可以极大地提高性能。默认情况下，Elasticsearch 和 I/O 子系统共享相同的 I/O 缓存，这为操作系统本身留出更多内存提供了另一个理由。

实际上，8GB 是对内存的最低要求。这并不意味着 Elasticsearch 永远不会使用更少的内存，但对于大多数情况和数据密集型应用程序来说，这是合理的最小值。另一方面，很少需要超过 64GB 的空间。取而代之的是，考虑水平扩展系统，而不是将如此多的内存分配给单个 Elasticsearch 节点。

我们说过，当整个索引适合内存时，我们处于良好的 状态。在实践中，这可能很难实现，因此良好和快速的磁盘非常重要。如果要求之一是高索引吞吐量，则更为重要。在这种情况下，您可以考虑使用快速 SSD 磁盘。不幸的是，如果您的数据量很大，这些磁盘会很昂贵。您可以通过避免使用 RAID 来改善这种情况（请参阅 https://en.wikipedia.org/wiki/RAID)，RAID 0 除外。在大多数情况下，当您通过拥有多个服务器来处理容错时，额外的安全级别在 RAID 级别上是不必要的。最后 是避免使用外部存储，例如网络附加存储 (NAS) 或 NFS 卷。在这种情况下，网络延迟总是会扼杀这些解决方案的所有优势。

当您使用 Elasticsearch 集群时，每个节点都会打开多个与其他节点的连接以用于各种用途。当你索引时，数据被转发到不同的分片和副本。当您查询数据时，用于查询的节点可以对其他节点运行多个部分查询，并根据从其他节点获取的数据组成回复。这就是为什么您应该确保您的网络不是瓶颈的原因。在实践中，集群中的所有服务器使用一个网络，避免集群中的节点分散在数据中心之间的解决方案。

答案总是一样的，因为 取决于它。它取决于许多因素：每秒请求的数量、数据量、查询的复杂程度、聚合和排序的使用、每单位时间的新文档数量、新数据的搜索速度（刷新时间）、平均文档大小和使用的分析器。在实践中，最方便的答案是 - 测试它并进行近似。

经常被低估的一件事是数据安全性。当您考虑容错性和可用性时，您应该从三台服务器开始。为什么？我们在 Master 选举配置 部分讨论了脑裂的情况>第 9 章，Elasticsearch 集群详解。从三台服务器开始，我们能够在不关闭整个集群的情况下处理单个 Elasticsearch 节点故障。

您进行了一些测试，考虑了 仔细规划的功能、估计的数量和负载，并带着架构草案去找项目所有者。 “它太贵了”，他说，并要求你再考虑一下服务器。我们能做什么？

让我们考虑一下服务器角色并尝试介绍它们之间的一些差异。如果其中一个需求是索引大量与时间相关的数据（可能是日志），那么可能的方法是拥有两组服务器：热节点，当新数据到达时，冷节点，当旧数据移动时。由于这种方法，当快速磁盘不是这样时，与冷节点相反，热节点可能具有更快但更小的磁盘（即固态驱动器） 重要，但空间很重要。您还可以将您的体系结构分成几组，作为主服务器（功能较弱，磁盘相对较小）、数据节点（更大的磁盘）和查询聚合器节点（更多 RAM）。我们将在以下部分讨论这个问题。

除了我们将在本节中讨论的所有 内容外，您还需要记住三个与操作系统相关的主要内容：数字 允许的文件描述符、虚拟内存和避免交换。

请注意，以下部分包含有关 Linux 操作系统的信息，但您也可以在 Microsoft Windows 上实现类似的选项。

bootstrap.mlockall: true

LABEL=cloudimg-rootfs  /   ext4  defaults,discard  0 0
/dev/xvdb swap swap defaults 0 0

sudo swapoff -a

elasticsearch soft nofile 65536
elasticsearch hard nofile 65536

session required pam_limits.so

bin/elasticsearch -Des.max-open-files=true

[2015-12-20 00:22:19,869][INFO ][bootstrap                ] max_open_files [10240]

sysctl -w vm.max_map_count=262144

在考虑 Elasticsearch 配置相关的事情之前，我们应该记住要给 Elasticsearch 提供足够的内存。通常，我们不应将超过 50-60% 的总可用内存分配给运行 Elasticsearch 的 JVM 进程。我们这样做是因为 我们想为操作系统和操作系统 I/O 缓存留出内存。但是，我们需要记住，50-60% 的数字并不总是正确的。您可以想象在这样的节点上有 256GB RAM 的节点和总共 30GB 的索引。在这种情况下，即使将超过 60% 的物理 RAM 分配给 Elasticsearch，也会为操作系统留下大量 RAM。将 Xmx 和 Xms 属性设置为相同的值以避免 JVM 堆大小调整也是一个好主意。

要记住的另一件事 是所谓的压缩 oops (http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance- enhancements-7.html#compressedOop)，普通对象指针。可以通过添加 -XX:+UseCompressedOops 开关来告诉 Java 虚拟机使用它们。这允许 Java 虚拟机使用更少的内存来寻址堆上的对象。但是，这仅适用于小于或等于 31GB 的堆大小。选择更大的堆意味着没有压缩 oops 和更高的内存使用来寻址堆上的对象。

我们知道，默认情况下，Elasticsearch 中的字段数据缓存是无界的。这可能非常危险，尤其是当您对许多分析的字段使用聚合和排序时，因为它们不使用 doc 默认值。如果这些字段是高基数字段，那么您可能会遇到更多麻烦。我们所说的麻烦是指内存不足。

我们可以调整两个不同的因素，以确保我们不会遇到内存不足错误。首先，我们可以限制字段数据缓存的大小，我们应该这样做。第二件事是断路器，我们可以轻松地将其配置为仅抛出异常而不是加载太多数据。将这两件事结合在一起将确保我们不会遇到内存问题。

但是，我们还应该记住，如果数据的大小不足以处理聚合请求或排序，Elasticsearch 将从字段数据缓存中逐出数据。这会影响查询性能，因为加载字段数据信息效率不高，而且是资源密集型的。但是，在我们看来，最好让我们的查询慢一些，而不是因为内存不足错误而让我们的集群崩溃。

字段数据缓存和一般缓存在 Elasticsearch 缓存部分讨论ch09">第 9 章，Elasticsearch 集群详解。

每当您计划大量使用排序、聚合或脚本时，应尽可能使用 doc 值.这不仅可以节省字段数据缓存所需的内存，因为生成的对象更少，而且还可以使 Java 虚拟机以更少的垃圾收集器时间更好地工作。文档值已在 第 2 章的 映射配置 部分中讨论/a>，索引您的数据。

在 Chapter 9 的 Elasticsearch 缓存 部分中， Elasticsearch 集群详解，我们也讨论过。有几件事我们想提一下。首先，索引缓冲区的 RAM 越多，Elasticsearch 能够在内存中保存的文档就越多。因此，我们用于索引的 内存越多，刷新到磁盘的频率就越少，创建的段就越少。因此，您的索引会更快。但当然，我们不希望 Elasticsearch 占用 100% 的可用内存。请记住，RAM 缓冲区是按分片设置的，因此将使用的内存量取决于在给定节点上分配的分片和副本的数量以及您索引的文档数量。您应该设置上限，以便您的节点在分配了多个分片时不会崩溃。

Elasticsearch 使用 Lucene，我们现在已经知道了。 Lucene 的问题是索引视图不会在新数据被索引或创建段时刷新。要查看新索引的数据，我们需要刷新索引。默认情况下，Elasticsearch 每秒执行一次，刷新周期由 index.refresh_interval 属性控制，每个索引指定。刷新率越低，文档对搜索操作可见的速度就越快。但是，这也意味着 Elasticsearch 需要投入更多资源来刷新索引视图，这意味着索引和搜索操作会变慢。刷新率越高，您需要等待的时间就越长，才能在搜索结果中看到数据，但您的索引和查询速度会更快。

直到现在我们还没有讨论过线程池，但现在我们想提一下它们。每个 Elasticsearch 节点 拥有多个线程池，用于控制索引或查询等操作的执行队列。 Elasticsearch 使用多个池来控制线程的处理方式以及允许用户请求的内存消耗量。

有很多线程池（我们可以通过指定 type 属性来指定我们正在配置的类型）。但是，对于性能，最重要的是：

例如，如果我们想将索引操作的线程池配置为具有 100 的大小和 500 的队列，我们将在 elasticsearch.yml 配置文件中设置以下内容：

threadpool.index.size: 100
threadpool.index.queue_size: 500

还要记住，可以使用集群更新 API 更新线程池配置。例如，像这样：

curl -XPUT 'localhost:9200/_cluster/settings' -d '{
 "transient" : {
  "threadpool.index.size" : 100,
  "threadpool.index.queue_size" : 500
 }
}'

通常，您不需要使用线程池及其配置。但是，在配置集群时，您可能希望更加强调索引或查询，在这种情况下，为优先级分配更多线程或更大队列操作可能会导致更多资源用于此类操作。

让我们在副本周围多呆一会儿。 Elasticsearch 允许我们在集群足够大时自动扩展副本。这意味着在将新节点添加到集群时可以自动创建副本。您可能想知道这些功能在哪里可以有用。想象一下这样一种情况，您希望在每个节点上都存在一个小索引，这样您的插件就不必为了从中获取数据而运行分布式查询。除此之外，您的集群是动态变化的，即您可以从中添加和删除节点。实现此类功能的最简单方法是允许 Elasticsearch 自动扩展副本。为此，我们需要将 index.auto_expand_replicas 设置为 0-all，这意味着索引可以有 0 个副本或存在于所有节点上。因此，如果我们的小索引名为 shops，并且我们希望 Elasticsearch 自动将其副本扩展到集群中的所有节点，我们将使用以下命令创建索引：

curl -XPOST 'localhost:9200/shops/' -d '{
 "settings" : {
  "index" : {
   "auto_expand_replicas" : "0-all"
  }
 }
}'

如果该索引已经创建，我们还可以通过运行以下命令来更新该索引的设置：

curl -XPUT 'localhost:9200/shops/_settings' -d '{
 "index" : {
  "auto_expand_replicas" : "0-all"
 }
}'

The Elasticsearch replication mechanism not only gives us ability to handle higher query throughput, but also gives us redundancy and high availability. Imagine an Elasticsearch cluster hosting a single index called library that is built of 2 shards and 0 replicas. Such a cluster would look as follows:

现在当其中一个节点发生故障时会发生什么？最简单的答案是我们丢失了大约 50% 的数据，如果失败是致命的，我们将永远丢失这些数据。即使有备份，我们也需要启动另一个节点并恢复备份，这需要时间。在此期间，您的应用程序或基于 Elasticsearch 的部分应用程序无法正常工作。如果您的业务依赖于 Elasticsearch，停机时间意味着金钱损失。当然，我们可以使用副本来创建更可靠的集群来处理硬件和软件故障。需要记住的一件事是，一切最终都会失败——如果软件不会，硬件也会。例如，前段时间谷歌表示，在他们的每个集群中，第一年至少有 1000 台机器会出现故障（您可以阅读更多关于该主题的信息在 http://www.cnet。 com/news/google-spotlights-data-center-inner-workings/）。因此，我们需要做好处理此类案件的准备。

让我们看看同一个集群，但只有一个副本：

现在失去一个 Elasticsearch 节点意味着我们仍然拥有可用的全部数据，我们可以在不停机的情况下恢复整个集群结构。当然，这只是一个由两个 Elasticsearch 节点集群构建的非常小的集群。集群越大，副本越多，您可以处理的故障就越多，而不必担心数据丢失。当然，性能会降低，具体取决于失败节点的百分比，但数据仍然存在并且集群将正常运行。

这就是为什么在设计您的架构并决定节点和索引的数量以及它们的 架构时，您应该考虑有多少节点，您想要失败生活。当然，你不能忘记等式中的性能 部分，但冗余和高可用性应该是扩展等式的因素之一。

Elasticsearch 的默认分布式特性及其水平扩展能力使我们能够灵活地在运行环境时的性能和成本方面。首先，具有高性能磁盘、众多 CPU 内核和大量 RAM 的高端服务器仍然很昂贵。除此之外，云计算越来越流行，如果您需要很大的灵活性并且不想拥有自己的硬件，您可以选择 解决方案，例如 Amazon (http://aws.amazon.com/），机架空间（http:// www.rackspace.com/), DigitalOcean (https://www.digitalocean.com /) 等等。它们不仅允许我们在租用的机器上运行我们的软件，还允许我们按需扩展。我们只需要添加更多机器，只需点击几下，甚至可以通过一定程度的工作实现自动化。

使用带有一键式机器租赁的托管解决方案可以拥有真正水平可扩展的解决方案。当然，这并不便宜——您需要为灵活性付费。但是，如果成本是我们业务计划中最关键的因素，我们很容易牺牲性能。当然，我们也可以反其道而行之。如果我们能负担得起大型裸机，Elasticsearch 集群可以推送到存储在索引中的数百 TB 数据，并且仍然可以获得不错的性能（当然，需要适当的硬件和分布式属性）。

在讨论 Elasticsearch 的可扩展性方面时，高可用性、成本和性能灵活性以及几乎无限的增长并不是唯一值得讨论的事情。在某个时间点，您可能希望将 Elasticsearch 集群升级到新版本。这可能是由于错误修复、性能改进、新功能或您能想到的任何事情。问题是，当您拥有每个分片的单个实例且没有副本时，升级意味着 Elasticsearch（或至少其部分）不可用，这可能意味着使用 Elasticsearch 的应用程序停机。这是水平缩放如此重要的另一个原因。您可以执行升级，至少到 Elasticsearch 等软件支持的程度。例如，您可以使用 Elasticsearch 2.0 并升级到 Elasticsearch 2.1，只需滚动重启（将一个节点从集群中取出、升级、带回，然后继续使用下一个节点，直到所有节点都完成），从而拥有所有数据仍可同时进行搜索和索引。

拥有具有大量内存和 CPU 内核的大型物理机 具有优势和一些挑战。首先，如果你决定在那台机器上运行一个 Elasticsearch 节点，你迟早会遇到垃圾收集问题，你会有很多单个节点上的分片将需要大量 I/O 操作来进行内部 Elasticsearch 通信（检索集群统计信息），等等。更重要的是，你通常不应该为单个 JVM 进程使用超过 31GB 的堆内存，因为你不能使用压缩的 普通对象指针（https://docs.oracle .com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html）。

在这种情况下，您可以在同一台裸机上运行多个 Elasticsearch 实例，在每个虚拟机中运行多个虚拟机和一个 Elasticsearch，或者在容器中运行 Elasticsearch，例如 作为 Docker (http://www.docker.com/) .这超出了本书的范围，但是，因为我们正在讨论缩放，我们认为提及在这种情况下可以做什么可能是一件好事。

node.server_name: server1

cluster.routing.allocation.awareness.attributes: server_name

我们还想讨论和强调一件事。对于大型集群，为集群中的所有节点分配角色非常重要。这允许一个真正完全容错且高度可用的 Elasticsearch 集群。我们可以分配给每个 Elasticsearch 节点的角色如下：

默认情况下，每个 Elasticsearch 节点都是主节点（它可以作为主节点），可以保存数据，并作为查询聚合器节点工作。您可能想知道为什么需要这样做。让我们举个简单的例子：如果主节点压力很大，它可能无法足够快地处理集群状态相关的命令，集群可能会变得不稳定。这只是一个简单的示例，您可以想到许多其他示例。

因此，大多数大于几个节点的 Elasticsearch 集群通常如下图所示：

可以看到，我们假设的集群包含三个客户端节点（因为我们知道会有很多查询），大量的数据节点因为数据量会很大，并且在 至少三个不应该做任何其他事情的主合格节点。当 Elasticsearch 在任何给定时间只使用一个主节点时，为什么要三个主节点？同样，由于冗余和能够通过将 discovery.zen.minimum_master_nodes 设置为 2 来防止脑裂情况，这将允许我们轻松处理集群中单个符合条件的主节点的故障。

现在让我们为您提供集群中每种类型节点的配置片段。我们已经在章节的了解节点发现部分讨论过这个问题9，详细介绍 Elasticsearch 集群，但我们想再次提及这一点。

node.master: false
node.data: false

node.master: false
node.data: true

node.master: true
node.data: false
http.enabled: false

在本节中，我们将查看有关调整 Elasticsearch 的索引相关建议。每个生产环境数据不同，索引率不同，用户行为不同。考虑到这一点并在您的环境中运行性能测试。这将使您最好地了解预期的内容以及在您的系统中最有效的方法。

Data distribution

众所周知，Elasticsearch 世界中的每个索引都可以分为多个 shard，每个 shard 可以有多个 个副本。如果您有多个 Elasticsearch 节点（并且您可能会在生产中拥有），您应该考虑分片和副本的数量以及这将如何影响您的节点。数据分布对于集群上的负载来说可能是至关重要的，并且不会让某些节点比其他节点做更多的工作。

让我们看下面的例子。假设我们有一个由 4 个节点构建的集群，它有一个名为 book 的索引，由 3 个分片和一个副本构建。这样的部署将如下所示：

如您所见，前两个节点分配了两个物理分片，而后两个节点各分配了一个分片。实际数据分配不均。在发送查询和索引数据时，我们将让前两个节点比其他两个节点做更多的工作——这是我们想要避免的。一种选择是让 book 索引有两个分片和一个副本，所以它看起来如下：

这种架构可以工作，而且非常好。我们不必在所有节点上都有主分片，我们可以 有副本，这取决于我们期望的瓶颈。对于查询，我们可能希望拥有更多的副本，以索引更多的主节点。

我们还可以让我们的主分片平均分割，如下图所示：

不过要记住的是，在这两种情况下，我们最终都会得到均匀分布的分片和副本，并且 Elasticsearch 将在所有节点上做类似的工作量。当然，如果有更多的索引（比如有每日索引），让数据均匀分布可能会更棘手，并且可能不可能有均匀分布的分片，但我们应该尝试达到这一点。

当涉及到数据分布、分片和副本时，要记住的另一件事是，在设计索引架构时，您应该记住要实现的目标。如果您要使用非常高的索引用例，您可能希望将索引分散到多个 分片中，以降低 CPU 和服务器的 I/O 子系统。这对于运行昂贵的查询也是如此，因为使用更多的分片可以降低单个服务器上的负载。但是，对于查询还有一件事——如果您的节点无法跟上查询引起的负载，您可以添加更多 Elasticsearch 节点并增加副本数量，以便将主分片的物理副本放在那些节点。这会使索引速度变慢一些，但会让您有能力同时处理更多查询。

Bulk indexing

这是非常明显的建议，但您会惊讶于有多少 Elasticsearch 用户忘记了批量索引数据而不是逐一发送文档。所以这里的建议是尽可能地做批量而不是一个一个的索引。不过要记住的是 不要用太多的批量请求使 Elasticsearch 过载，并将它们保持在合理的大小（不要将数百万个文档推送到一个要求）。请记住批量线程池及其大小，并尝试调整您的索引器不要超出它，否则您将首先开始对这些请求进行排队，如果 Elasticsearch 无法处理它们，您将很快开始看到被拒绝的执行异常和您的数据不会被索引。

举个例子，我们想展示我们前段时间对两种类型的索引进行的测试结果：一一索引和批量索引。在下图中，我们有一个一个文档运行索引时的索引吞吐量：

在下一张图片中，我们做同样的事情，但我们不是逐个索引文档，而是分批索引它们 10 个文档（这仍然是一个相对批量文档数量少）：

如您所见，在逐个索引文档时，我们每秒可以索引大约 30 个文档，并且非常稳定。这种情况随着批量索引和 10 个文档的批量而改变；我们每秒能够索引超过 200 个文档。所以可以很明显的看出区别。

当然这是索引速度的一个非常基本的比较。为了显示真正的区别，我们应该使用几十个线程并将 Elasticsearch 推到极限。但是，前面的比较应该为您提供使用批量索引时索引吞吐量增益的基本视图。

Elasticsearch 的一大特色是它能够搜索和分析被索引的数据。但是，有时需要调整 Elasticsearch 和我们的查询，以便不仅获得 查询的结果，而且还可以快速（或以合理的数量）获得它们时间）。在本节中，我们将探讨为高查询吞吐量用例准备 Elasticsearch 的可能性，但不仅限于此。我们还将查看查询时的一般性能提示。

{
 "query" : {
  "bool" : {
   "must" : [
    {
     "query_string" : {
      "query" : "mastering AND department:it AND category:book",
      "default_field" : "name"
     }
    },
    {
     "term" : {
      "tag" : "popular"
     }
    },
    {
     "term" : {
      "tag" : "2014"
     }
    }
   ]
  }
 }
}

{
 "query" : {
  "bool" : {
   "must" : [
    {
     "query_string" : {
      "query" : "mastering",
      "default_field" : "name"
     }
    }
   ],
   "filter" : [
    {
     "term" : {
      "tag" : "popular"
     }
    },
    {
     "term" : {
      "tag" : "2014"
     }
    },
    {
     "term" : {
      "department" : "it"
     }
    },
    {
     "term" : {
      "category" : "book"
     }
    }
   ]
  }
 }
}

该工具可作为 Elasticsearch 插件使用，但也可以作为在浏览器中运行的 JavaScript 应用程序单独下载。

Elasticsearch HQ 使用 JavaScript 和 AJAX 技术，定期从集群中获取数据，准备在浏览器端进行可视化，并显示给用户。

该工具允许我们 跟踪特定节点的统计信息。浏览器可以显示有关集群和特定节点的重要信息。以下屏幕截图显示了 Elasticsearch HQ 的图形用户界面：

我们有关于集群、节点数量和 Elasticsearch 运行状况的基本信息。我们还可以看到我们正在查看哪个节点以及有关该节点的一些统计信息，其中包括内存使用情况（堆和非堆）、线程数、Java 虚拟机垃圾 收藏家工作，等等。该插件还提供有关架构和分片的简化信息，并允许执行简单的查询。

为了安装 Elasticsearch HQ，只需运行以下命令：

bin/plugin install royrusso/elasticsearch-HQ

之后，GUI 将在 http://localhost:9200/_plugin/hq/ 上可用。

要记住的一件事 是 Elasticsearch HQ 不会将获取的数据保存在任何地方，因此只有在浏览器运行并打开 Elasticsearch HQ 时才会获取数据.如果过去发生过某些事情，您将无法诊断它。

Marvel 是由 Elasticsearch 团队创建的工具 。在当前版本中，它被构建为一个可视化平台的插件称为Kibana (https://www.elastic.co/products/kibana) .

Marvel 还通过绘制随时间动态更新的漂亮图形来可视化有关集群和节点的基本信息。与 Elasticsearch HQ 的主要区别在于性能数据 存储在服务器端（在同一个或外部的 Elasticsearch 集群中），因此可以使用历史数据。示例 屏幕截图如下所示：

Marvel 的安装过程包含三个步骤：

bin/plugin install license
bin/plugin install marvel-agent

最后，第三步 是通过运行以下命令在 Kibana 中安装 Marvel 插件：

bin/kibana plugin --install elasticsearch/marvel/latest

此工具提供了 与前面提到的工具不同的方法。 SPM 是一种 软件即服务（SaaS) 解决方案，用于监控任何规模的 Elasticsearch 安装，并允许监控多个集群和不同的技术。虽然它的根源是基于 SaaS 的，但它也可以在本地使用，这意味着您可以在自己的机器上运行 SPM，而无需将指标发送到云。

信息通过安装在 Elasticsearch 机器上的简单客户端软件发送到 SPM 服务器。主要优点是可以在更广泛的时间内存储信息并查看过去发生的事情。您可以创建自己的仪表板并将指标与多个应用程序之间的日志相关联（SPM 允许您监控各种应用程序）。

以下屏幕截图显示了 SPM for Elasticsearch 的仪表板：

前面屏幕截图中显示的概览仪表板提供了有关集群节点、请求率和延迟、索引中的文档数量、CPU 使用率、负载、内存详细信息、Java 虚拟机内存、磁盘空间使用情况以及最后网络的信息交通。您可以通过进入专用于它的选项卡来获取有关每个元素的详细信息。

您可以在 有关 SPM 安装和可用选项的其他信息.html" target="_blank">http://sematext.com/spm/index.html。