Elasticsearch：创建自定义 ES Rally tracks 的分步指南

ES Rally 是什么？它有什么用？

ES Rally 是一个用于测试 Elasticsearch® 性能的工具，它可以执行并记录对比测试。

做决策总是困难的，特别是当你没有具体的信息，只能依赖猜测或以往的经验。如果考虑到数据世界的多变性，因为数据世界变化迅速，我们的 Elasticsearch 必须适应这种变化，这时这个工具就能大显神威。它能帮助我们衡量随着时间的推移我们做出的所有改变和发展，以及评估它们的影响。最重要的是，我们最终能够获取做出正确决策所需的信息。

使用 ES Rally

ES Rally 内置了多个“赛道”（tracks）。一个 赛道 描述了一个或多个性能测试场景。

在许多情况下，这些测试可以用来评估不同版本的 Elasticsearch 或底层硬件，以及已经部署的集群。然而，在这个特定案例中，重要的是要记住，如果集群已经在运行并承载流量，由于并行使用会影响结果，所以指标可能不准确。不过，给出的值仍然可以用于后续的评估和比较。

你可能会好奇，是否可以使用你已经在 Elasticsearch 集群中拥有的自己的数据集。答案是肯定的。并非所有的优化或改进都只发生在 Elasticsearch 中。数据模型也可以进行优化或改进，无论是它的演变还是你根据数据使用方式看到的改进。你可以使用 ES Rally 来衡量这些变化的影响。接下来，我们将展示如何创建你自己的“赛道”。

使用你的数据创建自己的赛道

首先，我们来看看先决条件。ES Rally 可以通过几种方式进行 安装，但在我看来，如果我们使用容器发行版，可以节省时间并保持事情简单。

另一方面，我们应该考虑磁盘空间。ES Rally 会下载你告诉它下载的索引，所以如果你打算下载一个 1TB 的索引，你需要记住这一点。在这一点上，大小确实很重要——正如俗话说的，“不多也不少”——因此重要的是要定义一个有代表性的大小。如果太小，摄取速度指标可能不具代表性；但如果太大，创建赛道的时间会很长。

为此，一种准备数据的方法是使用 Elasticsearch 的 Reindex API，配合 max_docs 参数来创建一个大小适合稍后将运行的测试的索引。

示例

1 - 代码块截图

Reindex 的过程可能需要超过 30 秒，因此建议使用 wait_for_completion=false 选项启动它。这将返回一个任务 ID，你可以用它来跟踪过程的进展和完成情况。

注意： 目前，ES Rally 在创建自定义赛道时是单线程的。这是为了避免影响集群或运行任务的机器的性能。因此，这个过程可能需要一些时间才能完成。使用像 screen 或 tmux 这样的虚拟终端将允许你在后台运行该过程。

开始使用

一旦确定了目标索引，并确保我们有足够的空间，让我们启动自定义赛道的创建（请查看并相应调整，为了避免硬编码密码，我们将使用 read -s 在时候输入它）：

export loca_path='/path/where/save/esrally'
export user='user'
export track_name='test'
export ssl='true'
export verify_ssl='true'
export indice='test'
export es_host='es:port'
read -s password

docker run --rm --name esrally \
  -v ${loca_path}:/rally/.rally/ \
  elastic/rally create-track \
  --track=${track_name} \
  --target-hosts=${es_host} \
  --client-options="timeout:60,use_ssl:${ssl},verify_certs:${verify_ssl},basic_auth_user:'${user}',basic_auth_password:'${password}'" \
  --indices="${indice}" \
  --output-path=/rally/.rally/tracks

我们将得到类似于以下输出：

2 - rally 输出

我们可以通过以下方式查看我们创建的自定义赛道：

docker run --rm --name esrally \
  -v ${loca_path}:/rally/.rally/ \
  elastic/rally info --track-path=/rally/.rally/tracks/${track_name}

3 - 自定义赛道

我们得到了什么？

让我们看看在启动 ES Rally 后我们得到了什么。这将对我们了解如何适应和运行未来的测试至关重要。

下图显示了 ES Rally 的 默认配置，我们执行的日志，以及我们创建的自定义赛道。

4 - ES rally 代码

• logging.json：这是我们定义日志文件中事件记录方式的地方。
• logs/rally.log：这是我们执行 ES Rally 的日志被转储的地方。这个文件默认不轮转，所以我们可以配置一个像 logrotate 这样的外部工具来做这件事。
• rally.ini：这是定义 ES Rally 配置的文件。
• tracks/track_name/：这将包含与我们的自定义赛道相关的文件，在这个特定案例中：
  • name-documents-1k.json：前 1,000 个文档
  • name-documents-1k.json.bz2：前 1,000 个压缩文档
  • name-documents.json：所有文档
  • name-documents.json.bz2：所有压缩文档
  • name.json：原始索引的定义（映射和设置）
  • track.json：自定义赛道的配置（索引、语料库、计划、挑战）

通常，我们将使用 rally.ini 和每个自定义赛道内的 name.json 和 track.json 来适应行为和运行 ES Rally 的测试。

既然我们有了自定义赛道，我们如何使用它？

不深入讨论，让我们调整我们已经拥有的，以运行我们将用作基线的第一次测试，以衡量我们集群未来的变更（假设变量保持正确执行）：

docker run --rm --name esrally \
  -v ${loca_path}:/rally/.rally/ \
  elastic/rally race \
  --track-path=~/.rally/tracks/${track_name} \
  --target-hosts=${es_host} \
  --pipeline=benchmark-only \
  --client-options="timeout:60,use_ssl:true,basic_auth_user:'${user}',basic_auth_password:'${password}'"

这将为我们提供执行信息，但不用担心，它正在为以后使用而保存。

我们使用了 benchmark-only pipeline 类型来启动它，因为我们已经在一个正在运行的集群上运行它，这就是为什么我们可以看到警告，告诉我们采取的不同步骤可能会有误导性的指标，除了看到在 track.json 文件的 "schedule" 部分定义的默认步骤。

5 - rally

最后，指标部分将为我们显示每个 metric 的值。

注意： 指标可以通过配置 reporting 保存到 Elasticsearch。

6. - 最终得分

...

7 - 持续代码

为了深入理解每一个指标，我们将不得不查看 官方文档，那里详细解释了每一个指标。然而，许多指标都是不言自明的，我们将在下面找到最相关的案例。

变革时刻

到此为止，我们已经拥有了自定义赛道，并且至少使用 ES Rally 的默认配置执行了一次，并且使用了该索引的原始映射和设置。

让我们定义一个用例，数据模型优化。我特别提出这个，因为我在许多部署中看到了性能的显著提升和资源的显著节省，甚至对底层资源成本（如存储节省）产生了积极影响。

我知道这个用例可能是一个挑战，特别是当我们无法控制数据模型，因为它来自另一个领域或由外部应用程序管理时。但这将允许我们将数字放在桌面上，这些数字转化为性能和成本，因此 Elasticsearch 的使用更加高效、有利可图和优化。

我的同事 Mattias Brunnert 写了一篇关于 Elasticsearch 中分析和优化存储 的博客文章，你可以在那里看到一个映射（或数据模型）在这方面的影响示例。我想强调的是，一个优化的数据模型不仅会节省磁盘空间，它还会提高摄取和查询的速度。

因此，利用我们现在的位置，探索以下 api field_usage_stats，它将显示你如何使用你的数据。从那里你可以看出来，例如，从一个有 n_ 个字段的索引映射中，你使用了哪些字段，哪些没有。基于此，你可以定义一个新的、更符合你需求和实际使用的映射。

嗯，我们已经拥有了用例，我们已经分析了我们的数据，并发现我们可以改进自定义赛道中使用的索引的映射，所以我们继续编辑 name.json 文件以适应我们的分析结果。

我们可以找到类似这样的东西，其中我们看到了一个默认行为，当推断出文本数据类型时，会生成 Text 和 Keyword 字段，但在这个例子中显然是错误的。

8 - 默认行为

所以我们调整了映射并保存了更改，然后重新运行了相同的测试。

我们将得到像之前一样的输出：

9. - 输出

评估时刻

现在我们已经两次执行了我们的自定义赛道，其中的区别是映射的优化，我们将比较结果。

首先，正如我们之前提到的，结果存储在我们赋予它们的持久性中：

10 - 基准测试

在这些 JSON 文件中，我们可以看到每个测试单独获得的结果，但 ES Rally 还允许我们比较执行的操作。为了做到这一点，我们首先列出执行的操作：

docker run --rm --name esrally -v ${loca_path}:/rally/.rally/ elastic/rally esrally list races

11 json 文件

通过获得 Race ID，我们将执行以下操作以进行比较：

docker run --rm --name esrally -v ${loca_path}:/rally/.rally/ \
elastic/rally esrally compare \
--baseline=ID_WITHOUT_CHANGES \
--contender=ID_WITH_CHANGES

这将为我们提供两次执行的比较：

12

注意： 这些数据是示例，并不代表真实值；它们在实验室中执行，数据样本由 100 个文档组成。

使用 ES Rally 优化 Elasticsearch

我们已经看到了如何使用 ES Rally 与我们自己的数据集，如何修改它们以适应代表当前或未来情况的场景，以及如何比较和评估它们。这将帮助我们衡量可能的未来或计划中的变更，并确定是否获得了积极或消极的影响。它还有助于衡量集群的性能，如果我们定期执行负载测试，并确定我们距离达到 Elasticsearch 性能的操作或 SLA 限制有多远或多近。

ES Rally 可以以多种方式进行配置，甚至可以以分布式方式执行，以测试大型 Elasticsearch 环境——例如，当单个节点 ES Rally 执行的地方不够用或代表执行中的瓶颈时。

虽然我们已经看到了如何从 Docker 运行它，我留给你一个额外的 如何从 K8s 作为 Job 运行它的示例：

13 k8s job

想要了解更多关于 ES Rally 及其用例的信息？

我鼓励你查看 官方文档，以帮助你以最优化的方式在组织中使用它，以增加最大的价值。

记住，数据是决策的关键。