赞
踩
作者:来自 Elastic Philipp Kahr
Rally 也称为 ES Rally,是 Elastic® 用来识别 Elasticsearch® 性能改进、回归等的基准测试工具。 它每晚针对 Elasticsearch 的每晚构建运行。 你还可以使用它来对你的 Elasticsearch 集群进行基准测试,并识别与你的设置相关的任何性能问题。 如果你想每天摄取 5TB 的数据,请关注此博文和整个系列,了解如何确保你的硬件能够实现这一目标。 如果你的工作量更多在搜索方面,我们也会涵盖这一点!
Elastic 不建议针对生产中的集群运行 Rally。 Rally 轨道 (tracks) 具有破坏性行为,可能导致数据丢失。 此外,对从其他地方接收负载的集群进行基准测试并不是那么有用,因为无法充分解释 Rally 指标。
Rally 官方文档中描述了所有安装步骤。 不对源代码构建进行基准测试时,你不需要安装 Java。 本博文系列重点关注对在我们的云中运行的 Elasticsearch 进行基准测试。
或者,你可以使用官方 Docker 映像,而不是在本地安装。
你需要:
Pbzip2
一旦安装了所有这些先决条件,你就可以在 Python 中使用或不使用虚拟环境来继续前进。 为了让事情更简单,我们不会走那条路。
使用以下命令安装 Rally:
pip3 install esrally
现在它将安装所有必需的软件包,你就快准备好了。 就我而言,我没有以 root 身份安装 Rally,因此,我的安装路径不是 $PATH 的一部分。
有两种不同类型的离线安装。 我们将离线安装称为没有公共互联网连接的服务器。 要安装的第一个变体涉及托管你自己的 PiPy。 另一种方法是使用代理。 另一种不涉及互联网连接,也不涉及本地 PiPy。 对于第一种情况,你可以在安装 Rally 时按照上面的说明进行操作。 有关所有步骤的更多信息可以从官方文档中获取。
无论采用哪种安装方法,我们都必须在运行第一个基准测试之前配置 Rally。 让我们执行 esrally 命令。 我们应该会收到一条有关所有选项的消息。
- $ esrally
- usage: esrally [-h] [--version] {race,list,delete,info,create-track,compare,build,download,install,start,stop,add} ...
-
- ____ ____
- / __ \____ _/ / /_ __
- / /_/ / __ `/ / / / / /
- / _, _/ /_/ / / / /_/ /
- /_/ |_|\__,_/_/_/\__, /
- /____/
-
- You Know, for Benchmarking Elasticsearch.
-
- options:
- -h, --help show this help message and exit
- --version show program's version number and exit
- subcommands:
- {race,list,delete,info,create-track,compare,build,download,install,start,stop,add}
- race Run a benchmark
- list List configuration options
- delete Delete records
- info Show info about a track
- create-track Create a Rally track from existing data
- compare Compare two races
- build Builds an artifact
- download Downloads an artifact
- install Installs an Elasticsearch node locally
- start Starts an Elasticsearch node locally
- stop Stops an Elasticsearch node locally
- add Add records
- Find out more about Rally at https://esrally.readthedocs.io/en/2.10.0/
如果我们运行任何命令(例如 race),那么我们将收到如下所示的错误,这是预期的。
- $ esrally race
-
- ____ ____
- / __ \____ _/ / /_ __
- / /_/ / __ `/ / / / / /
- / _, _/ /_/ / / / /_/ /
- /_/ |_|\__,_/_/_/\__, /
- /____/
-
- usage: esrally [-h] [--version] {race,list,delete,info,create-track,compare,build,download,install,start,stop,add} ...
- esrally: error: argument --track is required
- [ERROR] Cannot race. 2.
-
- Getting further help:
- *********************
- * Check the log files in /home/philippkahr/.rally/logs for errors.
- * Read the documentation at https://esrally.readthedocs.io/en/2.10.0/.
- * Ask a question on the forum at https://discuss.elastic.co/tags/c/elastic-stack/elasticsearch/rally.
- * Raise an issue at https://github.com/elastic/rally/issues and include the log files in /home/philippkahr/.rally/logs.
-
- -------------------------------
- [INFO] FAILURE (took 0 seconds)
- -------------------------------
我们即将配置我们需要的一切。 我们要配置什么? 让我们从一个图表开始,这样可以更直接地理解我们的设置。
我们有一个要进行基准测试的目标集群和一个堆栈监控集群。 在 Rally 中,有两种方法来配置指标收集。 正如你从堆栈监控中了解到的那样,这并不意味着围绕 Elasticsearch 的指标。 其指标是在基准测试期间收集和生成的。 Rally 跟踪每个任务需要多长时间、延迟等。这可以导出到 Elasticsearch,使我们能够将其可视化。
由于我们还有堆栈监控数据,因此我们可以进行叠加并查看集群的 CPU 使用率与每个调用的延迟。 我们不鼓励将指标发送到您正在进行基准测试的同一集群,因为你在此集群上添加了额外的不受控制的负载。 查看官方文档。
要更改指标导出器,我们需要更改位于已安装用户主目录中的 Rally 配置文件。 就我而言,它是/home/philippkahr/.rally/rally.ini。 空白配置如下所示:
- [meta]
- config.version = 17
-
- [system]
- env.name = local
-
- [node]
- root.dir = /home/philippkahr/.rally/benchmarks
- src.root.dir = /home/philippkahr/.rally/benchmarks/src
-
- [source]
- remote.repo.url = https://github.com/elastic/elasticsearch.git
- elasticsearch.src.subdir = elasticsearch
-
- [benchmarks]
- local.dataset.cache = /home/philippkahr/.rally/benchmarks/data
-
- [reporting]
- datastore.type = in-memory
- datastore.host =
- datastore.port =
- datastore.secure = False
- datastore.user =
- datastore.password =
-
-
- [tracks]
- default.url = https://github.com/elastic/rally-tracks
-
- [teams]
- default.url = https://github.com/elastic/rally-teams
-
- [defaults]
- preserve_benchmark_candidate = false
-
- [distributions]
- release.cache = true
重要的配置部分是报告部分。 这里我们要放置堆栈监控集群。 我们将创建一个名为 “rallymetrics” 的新超级用户。 我们使用此超级用户,因为 Rally 可以更改任何版本中所需的权限。
- [reporting]
- datastore.type = elasticsearch
- datastore.host = monitoring.elastic.cloud.com
- datastore.port = 443
- datastore.secure = True
- datastore.user = rallymetrics
- datastore.password = abc
对于使用 OnPremise 集群并因此而拥有自签名证书和错误的任何人,有一个可用的设置:“datastore.ssl.verification_mode”。 你可以通过将其设置为 none 来禁用此功能,或者将本地证书添加到证书存储并将其指向此设置:“datastore.ssl.certificate_authorities”。 了解有关这些设置的更多信息。
首先,有许多现成的轨道 (tracks) 可用,但并非所有轨道都适合你的用例。 你要运行的第一个命令是 esrally list track。 这将显示所有可用的 tracks。 该列表包含 track 名称、压缩和未压缩的大小以及 challenges。 大小至关重要,因为这是你将下载的内容,并且本地磁盘上需要未压缩的文件。 我们没有修改 Rally 放置 track 数据的配置。 运行 esrally list track 命令后,你会在 ls ~/.rally 中看到一个名为 benchmarks 的文件夹。 在其中,我们将数据存储在 track 内,并为每个 track 创建一个文件夹。 这只是 GitHub 存储库的副本。
Race 是在 track上进行的。 每条 track 都需要至少一项 challenge。 Challenge 描述了 API 调用方面的特定工作负载。ingest-only challenge 将仅执行与摄取相关的 API 调用。 配置默认 challenge。 我们希望将 http_logs 轨道与挑战 append-no-conflicts-index-only 一起使用。
你要使用的命令是这样的:
- esrally race --user-tags={"benchmark_id": "1.1-http_logs-w20p1r1"} --track=http_logs --kill-running-processes --target-hosts=https://to-benchmark.elastic.co:9200 --pipeline=benchmark-only --client-options="verify_certs:false,basic_auth_user:'rally',basic_auth_password:'rally123'" --track-params='{"bulk_indexing_clients":20,"number_of_shards":1,"number_of_replicas":1}'
- --challenge=append-no-conflicts-index-only
我会一步步分解它。
esrally race
只需调用 esrally 并告诉它执行 race 即可。
--user-tags={"benchmark_id": "1.1-http_logs-w20p1r1"}
用于唯一标识任何 race,而不是每次执行。 我希望同一个 race,具有相同的设置,具有相同的标签。 在本例中,我只是将其命名为 1.1-http_logs-w20p1r1。 根据我所做的事情,我使用了无数不同的命名。 当你创建基准测试手册时,你可以使用该数字。 不同 race 之间的比较必须是独一无二的。 像 1.1-http_logs-w20p1r1 这样的东西很好。 你从基准测试手册、track 以及 10 个工作线程的主要副本和副本数量中运行 task 1.1。 你可以在类似于 client-options 参数的键值对中指定它们。 阅读更多。
--track=http_logs
那就是你正在运行的 track。 该跟踪称为 HTTP 日志,是 1998 年足球世界杯 Web 服务器的日志。 对原始日志进行了一些修改,所有这些修改都在 GitHub 上的轨道上进行了描述: http_logs 。 快速浏览一下我们正在摄取的示例文档:
- {
- "@timestamp": 898459201,
- "clientip": "211.11.9.0",
- "request": "GET /english/index.html HTTP/1.0",
- "status": 304,
- "size": 0
- }
--kill-running-processes
通常不需要这个。 有时,当你因为遇到问题而取消 track 时,esrally 可能无法正常退出,并且你周围有一些 esrally 进程。 在你终止所有正在运行的进程之前,Rally 将拒绝启动。 如果指定此标志,Rally 将自行终止这些进程。
--target-hosts=https://to-benchmark.elastic.co:9200
这就是你设置目标主机的地方。 它可以是一个或多个,具体取决于你的设置。 始终测试真实的数据流; 如果前面有负载均衡器,请使用负载均衡器端点对其进行测试。 请提醒你的负载均衡器团队。
--pipeline=benchmark-only
在这里,你可以告诉 Rally 为你启动一个集群,或者只是对你指向的集群进行基准测试。 在大多数情况下,你只想使用 benchmark-only。
--client-options="verify_certs:false,basic_auth_user:'rally',basic_auth_password:'rally123'"
如果没有示例,客户端选项总是很难弄清楚。 它需要采用 key:value 的形式,当需要更多设置时,可以用 , 分隔它们。 由于这是一个命令行参数,因此不要忘记转义 ! 等特殊字符。 verify_certs 是一个很好的小工具,可以告诉 Rally 忽略证书,这可能有助于本地测试。 在这种情况下,我只是在命令中以明文形式写入用户+密码。 如果你愿意,还可以使用环境变量。 有关此内容的更多信息,请参见:https://esrally.readthedocs.io/en/stable/command_line_reference.html#client-options。
--track-params='{"bulk_indexing_clients":20,"number_of_shards":1,"number_of_replicas":1}'
最后一项是任何赛道的主要内容。 你可以像上面的客户端选项一样指定跟踪参数。 选择 JSON 并熟悉它的原因是因为更复杂的 track(例如 Elastic 日志或安全 track)有大量选项。 根据 track,可以设置更多或更少的参数。 所有可能的参数均在此处描述:https://github.com/elastic/rally-tracks/tree/master/http_logs。 任何默认设置都有解释。 它需要采用 json 的形式。 它可以是像这样的命令行参数或本地参数文件。
在表格表示中,我们使用以下设置。 这里必须描述更多设置,因为它们不适用于我们。
Parameter name | Default value | Overwritten value |
bulk_indexing_clients | 8 | 20 |
number_of_shards | 5 | 1 |
number_of_replicas | 0 | 1 |
bulk_size | 5000 | Not altered |
ingest_percentage | 1000 | Not altered |
--challenge=append-no-conflicts-index-only
我们明确定义了从 esrally 列表 track 输出中获取的挑战。 否则,Rally 将完成 track 上的所有 challenges。 此 challenge 是 append-no-conflicts-index-only,因此是纯粹与摄取相关的任务。
第一次运行完成后,你可以在控制台输出中看到 Rally 执行的所有任务。 此输出和更多详细信息也收集在 .rally/logs 中配置文件旁边的 Rally 日志文件中。 在这篇博文中,我们不会详细介绍每个输出并解释如何解释它们。 有关所有步骤的更多信息可以在官方文档中找到。
我们在上面很快谈到了这个主题,并解释说每条 track 都有一个默认的 challenge。 在没有任何 challenge 命令行参数的情况下运行 http_logs 跟踪,我们运行append-no-conflicts-index-only。 这是 rallt 命令的第二个输出 [INFO] Racing on track [http_logs], challenge [append-no-conflicts-index-only] and car ['external'] with version [8.12.1].
每个 challenge 背后的目的都是编写基准测试规范。 因此,如上所述,每个挑战都可以具有不同的参数,并分配不同的任务。 使用 Jinja 增强的 JSON 文件中描述了 challenge。 GitHub 中详细介绍了 append-no-conflicts-index-only 以及与之相关的每个任务。
让我们抓住这个文件,看看我们需要什么来了解正在发生的事情。
- {
- "operation": "delete-index"
- },
- {
- "operation": {
- "operation-type": "create-index",
- "settings": {{index_settings | default({}) | tojson}}
- }
- },
- {
- "name": "check-cluster-health",
- "operation": {
- "operation-type": "cluster-health",
- "index": "logs-*",
- "request-params": {
- "wait_for_status": "{{cluster_health | default('green')}}",
- "wait_for_no_relocating_shards": "true"
- },
- "retry-until-success": true
- }
- },
- {%- if runtime_fields is defined %}
- {
- "operation": "create-timestamp-pipeline"
- },
- {
- "operation": "index-append-with-timestamp-pipeline",
- "warmup-time-period": 240,
- "clients": {{bulk_indexing_clients | default(8)}},
- "ignore-response-error-level": "{{error_level | default('non-fatal')}}"
- },
- {%- else %}
- {
- "operation": "index-append",
- "warmup-time-period": 240,
- "clients": {{bulk_indexing_clients | default(8)}},
- "ignore-response-error-level": "{{error_level | default('non-fatal')}}"
- },
- {%- endif %}
- {
- "name": "refresh-after-index",
- "operation": "refresh"
- },
- {
- "operation": {
- "operation-type": "force-merge",
- "request-timeout": 7200
- }
- },
- {
- "name": "refresh-after-force-merge",
- "operation": "refresh"
- },
- {
- "name": "wait-until-merges-finish",
- "operation": {
- "operation-type": "index-stats",
- "index": "_all",
- "condition": {
- "path": "_all.total.merges.current",
- "expected-value": 0
- },
- "retry-until-success": true,
- "include-in-reporting": false
- }
- },
- ...
原始文件比此摘录长得多,但这有助于我们了解正在发生的情况以及如何处理它。
每个 track 中的第一个任务是 delete-index。 我们想要删除任何现有的索引 —— 否则,我们无法正确计算所有文档是否都已成功索引,任何段、强制合并持续时间等都不是可表示的值。 如果你愿意的话,请将此作为第一步而不是在基准测试 “作为清理” 阶段结束时执行的原因。 也许你想在运行后检查集群中的数据,如果我们将其作为最后一步删除,则无法执行此操作。 或者,当你取消正在运行的基准测试时,这可以确保我们始终重新开始。
第二个任务通常是创建与之关联的索引。 我们只是做了一个 PUT indexname。
第三个任务非常重要,因为它是 check-cluster-health,它等待集群变为绿色,表明所有分片都已分配并且集群处于良好的健康状态。 如果你对单节点集群进行基准测试,则该集群永远不会呈绿色,除非你进行一些更改以将所有副本设置为 0。
这部分:{{cluster_health | default('green')}} 向你显示有一个名为 cluster_health 的参数,你可以像我们对 bulk_indexing_clients 所做的那样覆盖该参数。 如果你想对黄色状态集群进行基准测试,请传递 cluster_health: ‘yellow’。 不过我不会推荐它。 此任务也将重试,直到达到成功标准。
接下来会发生一些有趣的事情,那就是 if 条件。 在这种情况下,当我们使用 runtime_fields 参数运行时,我们运行一个不同的 index-append 任务,更具体地说:index-append-with-timestamp-pipeline。 我们还没有使用这个参数,因此我们进入 else 部分并运行正常的 index-append。 这就是这些 track 文件的构建方式及其工作方式。
在气隙环境中,运行赛道会稍微复杂一些,因为 Rally 不能仅从 GitHub 中提取并下载所需的文件。 让我们一步一步地看一下。 我们想要运行相同的 http_logs 轨道。 此轨道是此 GitHub 存储库的一部分。 运行 esrally list track,它会出错并告诉你它无法克隆这个存储库。
当下载器不起作用时可以使用后备变体方法。 你可以在有互联网的机器上使用你想要的赛道运行 ES Rally。 运行该轨道,并等待它以 DELETE index 或类似索引开始。 这意味着所有数据均已下载并提取。 你现在可以转到 ES Rally 的数据文件夹并将其复制,因为它已转移到离线主机。 但我不推荐这种方法!
在这个博客中,我们共同取得了很多成就! 我们安装了 Rally,进行了第一场比赛,并获得了第一个基准测试输出。 在下一篇博客中,我们将查看 Rally 的输出,以了解这对我们的 Elasticsearch 性能意味着什么。
接下来阅读:创建自定义 ES Rally tracks 的分步指南
本文中描述的任何特性或功能的发布和时间安排均由 Elastic 自行决定。 当前不可用的任何特性或功能可能无法按时交付或根本无法交付。
原文:Rally installation and air-gapped setup to benchmark Elasticsearch performance | Elastic Blog
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。