创建自定义 ES Rally Tracks 的分步指南

09-road.jpeg

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

ES Rally 是一款用于测试 Elasticsearch® 性能的工具，能够运行和记录对比测试。

决策往往很困难，尤其是当你没有所需的信息，只能依靠猜测或过去的经验时。

此外，数据世界发展迅速，因此我们的 Elasticsearch 也必须随之适应。这款工具能帮助我们衡量随时间变化所做的所有更改和演变，并评估其影响。最重要的是，我们可以获得所需的信息，以做出正确的决策。

使用 ES Rally

ES Rally 自带几个 "tracks"。一个 track 描述一个或多个性能测试场景。

在许多情况下，这些测试可以用来评估不同版本的 Elasticsearch 或底层硬件，以及已经部署的集群。然而，如果集群已经在运行并提供流量服务，测试结果可能不准确，因为并行使用会影响结果。但这些数值仍可用于后续的评估和比较。

此时，你可能会想：是否可以使用已经在 Elasticsearch 集群中存在的数据集？答案是肯定的。并非所有的优化或改进都仅发生在 Elasticsearch 中。它也可以在数据模型中进行，无论是演变还是基于数据使用方式的改进。你可以使用 ES Rally 来衡量这些变化的影响。接下来我们将展示如何创建你自己的 "track"。

使用你的数据创建自己的 Track

首先，让我们看看前提条件。ES Rally 可以通过多种方式安装，但为了节省时间并简化操作，建议使用容器分发版本。

另外，需要考虑磁盘空间。ES Rally 会下载你指定的索引，如果你打算下载一个1TB的索引，需要提前考虑这一点。因此，定义一个具有代表性的大小很重要。过小的话，摄入速度指标可能不具有代表性；过大的话，track 的创建时间会很长。

一种准备数据的方法是使用 Elasticsearch 的 Reindex API 及其 max_docs 参数来创建一个适合将来测试的索引大小。

示例

1 - code block screenshot

由于重索引过程可能超过30秒，建议使用 wait_for_completion=false 选项启动。这将返回一个任务ID，你可以用它来跟踪进度和完成情况。

注意： 目前，ES Rally 在创建自定义 tracks 时是单线程的，以避免影响集群或任务运行机器的性能。因此，这个过程可能需要一些时间。使用虚拟终端如 screen 或 tmux 可以让你在后台运行这个过程。

开始

一旦确定目标索引并确保有足够的空间，就可以启动自定义 track 的创建（请根据需要进行调整，以避免硬编码密码。我们将使用 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 output

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

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

3 - custom track

我们得到了什么？

让我们看看启动 ES Rally 后我们得到了什么。这对于知道如何调整和运行未来的测试目标至关重要。

下图展示了 ES Rally 的默认配置、我们执行的日志以及我们创建的自定义 track。

4 - ES rally code

• logging.json：定义如何在日志文件中记录事件。
• logs/rally.log：存储 ES Rally 执行日志的文件。默认情况下不会轮换此文件，因此我们可以配置一个外部工具如 logrotate 来处理。
• rally.ini：ES Rally 的配置文件。
• tracks/track_name/：包含与我们自定义 track 相关的文件，具体包括：
  • name-documents-1k.json：前1,000个文档
  • name-documents-1k.json.bz2：前1,000个压缩文档
  • name-documents.json：所有文档
  • name-documents.json.bz2：所有压缩文档
  • name.json：原始索引的定义（映射和设置）
  • track.json：自定义 track 的配置（索引、语料库、计划、挑战）

通常，我们将使用 rally.ini 以及每个自定义 track 中的 name.json 和 track.json 来调整行为和运行测试。

现在我们有了自定义的 track，如何使用它？

在不深入探讨的情况下，让我们调整现有配置，运行第一个测试，作为衡量未来集群变化的基准（假设变量已正确设置）：

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

最后，metrics 部分将显示每个 metric 的值。

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

6. - final score

...

7 - continued code

要深入了解每一个指标，我们需要查看官方文档，其中详细解释了每个指标。然而，许多指标是自解释的，我们会在接下来的例子中找到最相关的。

改变的时刻

此时，我们已经有了自定义 track，并且至少用 ES Rally 的默认配置以及该索引的原始映射和设置执行了一次。

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

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

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

因此，利用我们目前的位置，探索以下 api _field_usage_stats，它将显示你如何使用数据。例如，你可以从一个包含 n 个字段的索引映射中看到哪些字段在使用，哪些没有。基于此，你可以定义一个新的、更优化的映射，符合你的需求和实际使用情况。

好了，我们已经有了用例，分析了数据，并发现可以改进自定义 track 中使用的索引映射，于是我们编辑 name.json 文件，使其适应我们的分析结果。

我们可能会发现如下所示的内容，默认情况下，当推断出文本数据类型时，会生成 Text 和 Keyword 字段，但在这个例子中显然是不正确的。

8 - default behavior

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

我们将得到类似之前的输出：

9. - output

评估时刻

现在我们有了两个自定义 track 的执行结果，区别在于映射的优化，我们将比较结果。

首先，如前所述，结果被存储在我们指定的持久存储中：

10 - benchmark

在这些 JSON 文件中，我们可以看到每个测试的结果，但 ES Rally 也允许我们比较执行结果。首先，我们将列出已执行的任务：

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

11 json files

获得 Race ID 后，我们将执行以下命令进行比较：

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

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

12

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

使用 ES Rally 优化 Elasticsearch

我们已经了解了如何使用 ES Rally 处理自己的数据集，如何修改数据以适应当前或未来场景，以及如何比较和评估它们。这将帮助我们衡量未来或计划中的变化，并确定其是否会产生积极或消极的影响。它对于衡量集群性能也很有用，如果我们定期执行负载测试，可以确定我们距离操作或 SLA 限制有多远。

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

尽管我们展示了如何通过 Docker 运行它，作为额外的内容，我将提供一个 如何从 K8s 作为 Job 运行的示例：

13 k8s job

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

我鼓励你查看 官方文档 或 联系我们的咨询团队，以帮助你在组织中以最优的方式使用它，从而增加最大的价值。

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