Skip to content

Latest commit

 

History

History
294 lines (171 loc) · 21.2 KB

11.md

File metadata and controls

294 lines (171 loc) · 21.2 KB
Raw

十一、设计 ELK 栈

设计符合要求规格的弹性叠层需要特别注意。每个组件Elasticsearch、Logstash 和 Kibana ( ELK )都有特定的要求。正确的规模对于最佳性能和功能至关重要。

本章介绍了部署弹性栈时的设计考虑事项，同时考虑了每个组件的需求以及具体的设置细节。在本章中，我们将描述每个组件如何受到不同资源的影响，我们如何处理资源限制，以及如何为不同的场景进行规划和调整。

在本章中，我们将讨论以下主题:

  • Elasticsearch 中央处理器尺寸要求
  • 内存大小如何影响 Elasticsearch 性能
  • 数据如何存储在 Elasticsearch 中，以及如何根据性能调整大小
  • 对 Logstash 和 Kibana 的要求

技术要求

虽然在https://www . elastic . co/guide/en/elastic search/guide/current/hardware . html找到的文档已经过时，但硬件要求可以作为 CPU 规模调整的起点。有关更多有用的文档，请访问以下链接:

Elasticsearch 中央处理器要求

与任何软件一样，确定合适的 CPU 需求决定了应用的整体性能和处理时间。错误的中央处理器配置可能会导致应用不可用，因为处理需要太长时间才能完成，这让用户感到沮丧，更不用说缓慢的处理时间会导致应用完全失败。

虽然 Elasticsearch 并不严重依赖于中央处理器进行索引和搜索，但是在设计一个性能良好并及时返回结果的弹性栈时，需要考虑几个因素。

尽管 Elastic 没有公布对 CPU 的硬性要求，但有几件事可以作为经验法则来应用。

中央处理器计数

通常，拥有更多内核会更好，这可能是大多数工作负载的情况。Elasticsearch 通过跨多个 CPU 调度任务，利用系统上有多个可用内核；但是，它不需要大量的 CPU 处理能力，因为大多数操作都是在已经索引的文件上执行的。

大多数云提供商(如果您正在云上部署)都提高了高 CPU 数量虚拟机的速率，以避免不必要的成本，虚拟机类型的大小平衡了比 CPU 更多的内存。

在确定足够的 CPU 资源时，您应该考虑到一些增长，而不必中途更改设置。对于小型设置，至少有两个 CPU 就足够了。出于测试目的和少量的索引/源，即使一个 CPU 也足够了，但是性能会受到影响，尤其是如果所有的组件——Elasticsearch、Logstash 和基巴纳——都部署在同一个系统上。

中央处理器速度

虽然没有关于最低中央处理器速度(时钟速度)要求的硬文档，但现在要找到一个低于 2 千兆赫的中央处理器有些困难。这个低水位线似乎是 Elasticsearch 避免问题的最低要求。

任何高于 2 千兆赫的都可以接受，即使只有一个中央处理器；这对于测试目的来说是足够的。对于生产环境，寻找高于 2 千兆赫或 2.3 千兆赫的中央处理器时钟速度以避免问题。

中央处理器性能影响

如果在中央处理器方面配置了不正确的大小，Elasticsearch 将主要在以下三个方面受到影响:

  • 启动时间
  • 每秒索引数
  • 搜索延迟

启动

在启动期间，随着 JVM 启动和 Elasticsearch 从集群中读取数据，CPU 使用率可能会激增。CPU 配置较慢会导致 Elasticsearch 启动时间较长。

如果 Elasticsearch 节点要不断重启，拥有正确的中央处理器配置将有助于减少达到运行状态所需的时间。

每秒索引数

CPU 配置直接影响 Elasticsearch 每秒能够处理的索引数，因为一旦有更多的文档被索引，它就会耗尽周期。理想情况下，Elasticsearch 利用多个处理器上的索引，允许更多客户端发送数据，而不会丢失任何指标或事件。

搜索延迟

搜索返回结果所需的时间可能对性能影响最大。请记住，Elasticsearch 的主要功能之一是它检索和显示数据的速度。

CPU 配置过小会导致搜索时间比预期的长，这可能会导致令人沮丧的用户体验。

在下面的截图中，我们可以看到搜索延迟峰值几乎达到 80 毫秒，并徘徊在 20 毫秒左右:

Monitoring latency in Kibana  Note that the preceding screenshot was taken from an undersized system with just one CPU running at less than 2 GHz. The latency could be worse, but this was taken from a system running on a fast NVMe drive, which can have latency as low as 100 microseconds.

推荐

为了获得最佳结果，需要实施正确的中央处理器设置。以下两种主要情况会影响 CPU 规模:

  • 测试/开发
  • 生产

测试/开发

对于测试来说，超过一个中央处理器和 2 千兆赫的任何东西对于一个小测试来说都足够了，两个客户端向 Elasticsearch 发送数据。搜索结果返回的速度可能有点慢，但它会毫无问题地工作。

生产

对于生产，请确保使用至少 2.3 千兆赫或以上的中央处理器。中央处理器数量不会对性能产生很大影响，但至少有两个中央处理器可以确保最佳运行。添加更多客户端后，可能需要修改 CPU 数量以满足额外需求；如果 CPU 成为限制，可以添加更多的 Elasticsearch 节点。

最后，在内核数量和时钟速度之间进行选择时，Elasticsearch 利用了多个内核。更少但更快的内核带来的性能优势不如拥有更多更慢的内核那么令人印象深刻。

When deploying on Azure, you can use a DS2v3 VM type for a small setup, as it offers two CPUs and enough RAM for basic needs.

一旦我们正确确定了中央处理器的大小，我们就可以关注系统内存如何影响 Elasticsearch 的性能和可用性。

Elasticsearch 的内存大小

为 Elasticsearch 分配足够的内存可能是要考虑的最重要的资源因素，以避免问题和性能不佳的设置。

内存是一种资源，拥有大量内存从来都不是问题。作为一名架构师，在确定内存大小时，您需要记住几件事。与 CPU 资源类似，对于最低内存要求没有硬文档。

文件系统缓存

拥有大量内存总是一个好主意，因为有文件系统缓存或 Linux 页面缓存。

内核通过为输入/输出请求分配部分内存来使用空闲的系统内存来缓存、读取或写入请求，从而大大加快了 Elasticsearch 的搜索或索引速度。

从下面的截图中可以看到，内核分配了大约 1.2 GB 的页面缓存:

利用页面缓存有助于减少搜索或传入索引时的响应时间；请确保尽可能多地调整内存大小。有一点是缓存使用率将会平衡，不再有内存用于页面缓存。在这一点上，值得监控这个过程，尝试并确定这个阈值，以避免遇到不必要的费用。从长远来看，如果一个虚拟机 ( 虚拟机)的内存大小为 32 GB，但只使用了大约 10 GB 的缓存，并且从未超过这个数字，那么调整到一个更小的虚拟机可能是值得的，因为剩余的内存将被闲置。

正如您在下面截图中的 Kibana 仪表板中看到的，您可以监控 Elasticsearch 的缓存使用情况，这可能有助于识别资源是否未使用:

Monitoring cache usage for Elasticsearch

禁用交换

交换是一种机制，允许内核在不频繁访问或内存压力大(即系统内存不足)时将内存页面移动到磁盘。交换的一个主要问题是，当一个内存页面被移动到磁盘时，它的访问时间会比在内存中慢得多。

DDR4 内存的平均传输速率约为 10 GB/s，更令人印象深刻的是，平均响应时间(或延迟)仅为 13 ns(纳秒)。相比之下，即使是市场上最快的 NVMe 固态硬盘也只能达到 3.5 GB/s，延迟约为 400 微秒。您可以很快开始了解这是如何成为一个问题的:并非所有云提供商或内部安装都使用 NVMe 驱动器，并且换用速度更慢的旋转介质可能会产生非常糟糕的结果。

因此，Elasticsearch 建议禁用所有形式的交换，转而依赖正确的系统内存大小。

内存不足

内存配置错误会导致不同的行为。它可以归结为两种不同的情况:没有足够的内存，但有足够的内存来运行系统，以及没有足够的内存，以至于 Elasticsearch 甚至无法启动。

对于第一种情况，内存有限制，但刚好足够 Elasticsearch 启动和运行，主要问题是没有足够的内存用于页面缓存，这导致搜索速度慢，每秒索引减少。在这种情况下，Elasticsearch 能够运行，但整体性能下降。

另一种情况可以分为两种不同的情况:一种是没有足够的内存来启动 Elasticsearch，另一种是 Elasticsearch 可以启动，但是一旦添加了一些索引，它就会耗尽内存。为了避免系统崩溃，Linux 有一个机制叫做内存不足杀手 ( OOM 杀手)。

无法启动

Elasticsearch 使用 JVM，默认情况下，它被设置为使用至少 1 GB 的堆内存。这意味着 Java 需要为 JVM 分配至少 1 GB 的内存，所以对于 Elasticsearch 来说，从最小的内存开始，它需要大约 2.5 GB 的内存。

判断此问题何时发生的最简单方法是使用systemctl status elasticsearch验证 Elasticsearch 服务的状态；它将返回类似如下的错误消息:

在进一步检查错误日志时，我们可以清楚地看到 JVM 如何未能分配必要的内存，如以下代码所示:

# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 899284992 bytes for committing reserved memory.
# Possible reasons:
#   The system is out of physical RAM or swap space
#   In 32 bit mode, the process size limit was hit
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Use 64 bit Java on a 64 bit OS
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
#  Out of Memory Error (os_linux.cpp:2760), pid=933, tid=0x00007f1471c0e700

Testing using the default heap of 1 GB is sufficient. For production, make sure that you increase the heap to at least 2 GB and adjust as necessary.

要增加堆，编辑/etc/elasticsearch/jvm.options文件并找到以下选项:

-Xms1g
-Xmx1g

将这两个选项更改为以下选项:

-Xms2g
-Xmx2g

The -Xms2g phrase indicates that Java should have a minimum heap of 2 GB and -Xmx2g indicates the maximum heap of 2 GB.

OOM 杀手

内存不足杀手 ( OOM 杀手)机制的主要目的是通过杀死正在运行的进程来避免整个系统崩溃。每个过程都有一个oom_score值。OOM 杀手根据这个分数决定杀死哪个进程；分数越高，在内存不足的情况下，进程被终止的可能性就越大。这个分数是根据进程被终止时释放的内存来计算的。

如果我们以前面的场景为起点，如果 Elasticsearch 能够从最低 2.5 GB 开始，一旦有更多的索引/源添加到 Elasticsearch，它将开始需要越来越多的系统内存，直到没有更多内存，系统接近完全崩溃。在那一刻，OOM 杀手跳了进来，杀死了消耗最多内存的进程——在我们的例子中，是 Elasticsearch。

在查看/var/log/messages下的事件时，我们可以看到 OOM killer 是如何启动并杀死 Java 进程，然后 Elasticsearch 服务失败的，如下图截图所示:

推荐

理想情况下，应该为 Elasticsearch 分配足够的内存。对内存的最低要求约为 2.5 GB，但这将导致系统内存很快耗尽的情况。

出于测试的目的，2.5 GB 对于一些源/索引来说可能已经足够了。性能无疑会受到影响，但它仍将保持一定的可用性。

对于生产环境，请确保至少有 4 GB 或更多的系统内存。这应该允许 Elasticsearch 在没有问题的情况下启动，并在配置了多个源/索引的情况下正常运行。确保 JVM 的堆大小相应增加，并考虑为页面缓存留出一些内存，以便在与文件系统交互时加快响应速度。

接下来，我们将了解 Elasticsearch 所需的存储配置。

Elasticsearch 的存储配置

Elasticsearch 的存储要求相对简单，可以分为两大类:

  • 存储容量
  • 存储性能

让我们仔细研究一下这两个问题，看看在这里做出的决策会如何影响整体性能。

容量

存储容量直接影响 Elasticsearch 能够存储的数据量。与许多其他情况一样，这是一个需要考虑的大而复杂的要求，因为它取决于影响空间利用率的许多其他变量。

主要变量是发送到 Elasticsearch 的日志/指标的大小。这取决于每天(或每月)生成的日志数量。例如，如果每日日志速率为 100 MB，那么这意味着，为了能够存储一个月的日志，至少需要 3 GB 的可用空间(100 MB x 30 天= 3 GB)。

请注意，这是单个源所需的最小空间。理想情况下，应该考虑一些开销，因为数据会定期变化，并且 100 MB/天的数字可能不是一个月中的所有日子都是恒定的，或者其他月份由于负载较高而具有较高的速率。此外，一旦添加了更多的源(或客户端)，数据使用量也会相应增加。

By default, Elasticsearch will store its data under the /var/lib/elasticsearch directory.

表演

Elasticsearch 的一个主要特点是它能够快速检索数据。虽然这是使用将文档存储为 JSON 文件的增强机制来完成的，但是拥有正确的性能设置肯定有助于实现几乎实时的搜索结果。

Elastic 没有为存储需求提供硬编号，但是使用固态硬盘 ( 固态硬盘)作为/var/lib/elasticsearch目录有助于减少执行搜索时的延迟，因为与硬盘相比，固态硬盘的延迟要低得多。固态硬盘在接收数据时也有所帮助，因为写入会得到更快的确认，从而允许更多的并发传入索引。这反映在每秒的索引中，可以在基巴纳监控仪表板上看到。

在为云调整规模时，这实际上取决于提供商，因为有些提供商将磁盘的性能基于其大小，但有些提供商允许手动配置性能(如 IOPS 和吞吐量)。

由于不可靠、较慢的磁盘设置，较慢的设置将导致搜索时间比预期的长，并且数据接收速度较慢。

考虑

对于空间，请考虑一个能为意外数据增长留出足够空间的规模。例如，如果整个月的预期数据使用量为 500 GB，请考虑至少 700 GB 的大小；这样做可以给你一个缓冲区，避免 Elasticsearch 索引没有足够空间的情况。一个好的起点是 500 GB，因为它为测试/生产提供了足够的空间，同时计算了实际的数据使用和数据变化(如果以前不知道的话)。

对于性能，考虑使用更快的存储解决方案，如固态硬盘，以实现低延迟搜索和更快的索引速度。对于云，大多数提供商都有某种固态硬盘产品，可以与 Elasticsearch 一起使用。确保至少配置了 500 个 IOPS 以获得最佳性能。

For Azure, you can use a P10 disk—which is an SSD that can provide up to 500 IOPS—or an E10 as a lower cost alternative that delivers the same result.

我们现在来看看 Logstash 和 Kibana 需要考虑什么。

Logstash 和 Kibana 要求

对 Logstash 和 Kibana 没有具体的要求，但是在设计弹性栈时记住几件事总是一个好方法。

logstash(日志记录)

Logstash 对 CPU 和 RAM 的要求都不高，但这完全取决于有多少源在提供 Logstash 数据，因为对于 Logstash 解析的每个事件，都需要一些开销来完成这个过程。如果 Logstash 要独立安装(同一系统上没有其他组件)，那么一个 vCPU 和 2gb 内存以上的任何东西都应该足以满足小型/测试部署。理想情况下，应该监控实际使用情况，并相应地调整系统。默认情况下，Logstash 具有用于临时存储事件的内存队列；处理事件时，可以更改此行为以使用持久队列。这允许持久的一致性，并避免停机期间的数据丢失。此外，拥有持久队列有助于通过充当客户端和 Logstash 之间的缓冲区来吸收突发事件。

当使用持久队列存储容量时，/var/lib/logstash目录需要能够存储由 Logstash 处理的事件。空间大小取决于两个因素:将数据发送到 Elasticsearch 时的出口速度和发送到 Logstash 的事件数量。最小值为 1 GB，当源数量增加时，空间需要相应增加。

姆纳人

对 Kibana 的要求完全取决于同时访问仪表板的用户数量。分配给基巴纳的资源量需要基于预期的使用情况，例如，预期的用户基础是什么？这些用户中有多少人会同时访问基巴纳？

对于小型部署/测试，最低要求由 JVM 决定。一个 vCPU 和 2 GB 的 RAM 对于几个用户来说已经足够了，但是一旦更多的用户开始使用仪表盘，RAM 将成为第一个成为瓶颈的资源。

In general, an Elastic Stack has pretty loose requirements that are mostly dictated by the usage and the number of sources. Regarding software, the primary requirement is Java; since all of the components use the JVM, either the open JDK or the official JDK can be used.

摘要

在这一章中，我们讨论了使用 Elasticsearch、Logstash 和 Kibana 设计弹性栈时所需的需求。对于 Elasticsearch，我们确定小型设置的最低 CPU 要求是两个虚电路，CPU 速度应该保持在 2 千兆赫以上。如果不满足这些最低要求，Elasticsearch 将需要更长的启动时间，并且执行速度会更慢。这表现为每秒索引数量的减少和搜索延迟的增加，这两者都是需要避免的事情，以便我们能够充分利用 Elasticsearch 提供的近即时搜索。

设计 Elasticsearch 设置时，内存大小可能是最重要的规格。系统内存的一部分将用于文件系统缓存(也称为页面缓存)，这有助于每秒的搜索和索引。不建议交换，因为与实际的内存访问相比，交换被认为非常慢，因此应该在 Elasticsearch 节点上禁用交换。如果不满足正确的内存要求，Elasticsearch 将无法完全启动，因为没有足够的内存供 JVM 启动。另一方面，如果有足够的内存来启动 JVM，但是负载会随着时间的推移而增加，并且系统内存不足，那么 OOM 或内存不足杀手就会介入，以避免导致应用失败的系统崩溃。所需的最小内存量是 2.5 GB，但资源限制会相对较快地显现出来。

存储容量和性能在设置 Elasticsearch 时起着重要作用。容量取决于需要保留的数据量和配置的源数量。为了让我们的搜索更快，需要将延迟保持在最小。理想情况下，应该使用固态硬盘。

最后，对于 Logstash 和 Kibana，每个组件的最低要求是一个 vCPU 和 2 GB 内存。对于 Logstash，持久队列需要空间。

在下一章中，我们将利用本章中所学的知识，使用 Elasticsearch、Logstash 和 Kibana 跳转到部署弹性栈。

问题

  1. Elasticsearch 推荐多少个 CPU？
  2. Elasticsearch 推荐的最低 CPU 速度是多少？
  3. 错误的中央处理器配置如何影响 Elasticsearch 性能？
  4. 什么是页面缓存？
  5. 为什么建议您禁用 Elasticsearch 节点上的交换？
  6. 内存不足如何影响 Elasticsearch？
  7. Elasticsearch 所需的最小内存是多少？
  8. 默认情况下，Elasticsearch 将数据存储在哪里？
  9. 为什么建议 Elasticsearch 使用固态硬盘？
  10. Logstash 的最低要求是什么？
  11. 什么是持久队列？
  12. 什么影响了基巴纳的资源使用？

进一步阅读

有关更多信息，您可以阅读以下书籍: