Elasticsearch：实践指南

Posted 2021-12-06 Elastic 中国社区官方博客

Elasticsearch 用户知道在设置和配置系统时出错是多么容易，以及如果在问题开始对你的性能产生负面影响之前你没有注意到问题会发生什么。超过 10 个节点的集群比较小的集群有更多的问题。 这与较小的集群更易于管理的事实一致。 然而，人们通常会认为集群越大，它对公司就越重要，因此会有更多的资源用于维护它并防止问题发生。

更重要的是，Elastic 的文档非常适合小规模运营，但规模越大，你对运营的了解和了解就越多。 你需要知道何时遵循最佳实践，以及何时根据你的需要定制您自己的解决方案。

我们将最常见的配置错误和系统疏忽分解为你在下面看到的类别。

最佳实践

最佳实践涵盖了一些小的、建议的更改，这些更改可能会对你的系统性能产生很大的影响。 跟踪和实施最佳实践并不总是那么容易，因为信息通常在互联网上的不同论坛中传播，并且根据 Elasticsearch 版本而有所不同。

一项重要的最佳实践是更改默认集群名称（“elasticsearch”），这可以防止将来发现问题，甚至防止意外删除数据。 很多用户没有为他们的集群分配名称，而是使用默认名称，这给他们带来了不必要的风险。

另一个重要的最佳实践，只有很少的用户，是限制使用通配符进行破坏性（删除）操作。 使用通配符可能会导致你的所有数据意外删除——然而，超过 90% 的人并没有通过轻松禁用通配符删除索引来避免这种风险。我们可以使用如下的命令来禁止这一操作：

PUT _cluster/settings
{
  "persistent": {
    "action.destructive_requires_name": true
  }
}

当我们尝试来删除一个如下的索引时：

DELETE twitter*

我们会得到如下的错误信息：

{
  "error" : {
    "root_cause" : [
      {
        "type" : "illegal_argument_exception",
        "reason" : "Wildcard expressions or all indices are not allowed"
      }
    ],
    "type" : "illegal_argument_exception",
    "reason" : "Wildcard expressions or all indices are not allowed"
  },
  "status" : 400
}

有关删除索引，可以参阅官方文档。

Scripts

Elasticsearch 脚本对于分析n 的数据非常强大和有用，但是它们可能会给n 的集群带来沉重的负载，特别是如果脚本编写时没有仔细考虑它们可能使用的资源。出于这个原因，建议限制可以在集群上运行的脚本类型，以及可以运行脚本的上下文。

除了性能方面的考虑之外，限制脚本访问也是出于安全考虑的好习惯。

惊人的将近 90% 的用户没有限制脚本上下文和脚本类型。如果脚本不受限制，它们可能会因重载而意外破坏集群。尽管某些应用程序可能需要脚本才能使它们正确运行，但许多用户根本不考虑实施这些限制来确保将资源集中到正确的位置。我们可以通过 filter 等让脚本在一个比较小的数据集上运行，从而减少脚本的运算量。

还有少了的用户在他们的 painless 脚本中启用了正则表达式。 Regex 是正则表达式的缩写，是指使用定义搜索模式的字符序列进行搜索的技术。在 painless 脚本中必须小心使用正则表达式，因为某些表达式可能非常慢并且需要大量资源才能运行。这就是默认情况下禁用正则表达式的原因。如果你选择启用正则表达式，请确保正确实施它、测试性能并密切监控您的资源。

如果你想了解详情，请参阅我之前的文章：

• Elasticsearch：避免不必要的脚本 - scripting

• Elasticsearch：正确使用 regexp 搜索

• Kibana：如何在 Kibana 中禁止查询中使用前置通配符查询

集群架构

Elasticsearch 部署服务于许多不同的用例，每个用例都需要不同的架构。

对于足够大的集群，强烈建议拥有专用的主节点和专用的协调节点——它们对于提高性能至关重要。

在集群版本低于 7.x 的用户中，有一部分用户在他们的 minimum_master_nodes 设置中错误地配置了该值，从而冒着脑裂的风险。 当该值设置为小于仲裁所需的值时，由于任何原因断开连接的节点可能会形成一个独立于主集群的单独集群。 幸运的是，这个问题从 v7 开始就解决了。

集群性能

影响集群性能的因素有很多。这就是通过密切监控集群来掌握所有实时统计数据如此重要的原因之一。检查涵盖集群性能的许多方面，检查 CPU 的利用率、断路器、堆大小、各种队列等。

有些 Elasticsearch 用户有很高的断路器跳闸次数，导致搜索或索引请求被中止并导致应用程序抛出异常。断路器用于保护节点免受因资源不足而导致其崩溃的情况，特别是当内存使用量接近操作限制时。

还有一些用户的节点上的 CPU 利用率很高，这会导致高搜索和索引延迟、拒绝请求和可能的超时。随之而来的，会发现用户具有较高的搜索拒绝队列，并且当搜索被拒绝时，客户端应用程序当然不会按预期运行。

当我们查看索引队列时，我们发现  Elasticsearch 用户有高队列，这表明没有足够的资源来处理所有索引操作。这可能会导致索引操作被拒绝和搜索操作变慢，从而全面影响客户。

大多数用户对他们的堆大小配置很小心。建议最多使用总可用 RAM 的 50%，但在任何情况下堆大小都不应超过 32GB 的限制。最好是小于 26GB。这就是对象指针不再基于零并且性能下降的点。通过正确配置他们的堆大小限制，这些用户成功地保持了他们的 Elasticsearch 性能。

关于针对集群的监控，请参阅文章 “Elastic：开发者上手指南” 中的 “监视及管理” 章节。

磁盘使用

当涉及到 Elasticsearch 部署时，你永远不想占用整个磁盘。好消息是 Elasticsearch 有 “watermark”，以保护你免于到达那个点。坏消息是，大多数人不知道 watermark 是什么以及当它们被越过时会发生什么。

每个 Elasticsearch 集群上的各种 “watermark” 阈值用于监控磁盘使用情况。当节点上的磁盘空间填满时，要跨越的第一个阈值将是 “low disk watermark”。一旦超过了该阈值，这意味着 Elasticsearch 不会将副本分片分配给那些超过阈值的节点。这可能导致集群变得不平衡并将状态更改为黄色，甚至红色。

第二个阈值将是 “high disk watermark”。 一旦用户拥有超过此阈值的节点，这意味着 Elasticsearch 将主动开始将分片从有问题的节点重新定位到集群中的其他 Elasticsearch 节点。这可能会导致额外的负载并导致集群变得不平衡。

最后，“disk flood stage” 是当没有可用磁盘空间时达到的最后一个 watermark。一旦超过此阈值，集群将阻止写入已超过 watermark 的节点上的所有索引（无论是主分片还是副本），这可能会导致许多索引异常。读取（搜索）仍然是可能的。

建议阅读：

• Elasticsearch：Low disk watermark

• Elasticsearch：High disk watermark