作者：Alejandro Sánchez

按照這個綜合教程學習如何制作個性化的 Rally tracks

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

ES Rally 是一個用于在 Elasticsearch? 上測試性能的工具，允許你運行和記錄比較測試。

做出決策可能很困難，尤其是當你沒有所需的信息并且只能根據過去積極或消極的變化進行猜測或經驗時。

如果我們補充一點，數據世界必須是靈活的，因為它發(fā)展迅速，因此我們的 Elasticsearch 必須適應它，這個工具將幫助我們能夠衡量我們隨著時間的推移所做的所有變化和演變，并評估它們的影響 。 最重要的是，我們可以獲得做出正確決策所需的信息。

使用 ES Rally

ES Rally 附帶了幾條開箱即用的 “tracks”。 track?描述一個或多個性能測試場景。

在許多情況下，這些測試可用于評估不同版本的 Elasticsearch 或底層硬件，以及已部署的集群。 然而，在這種特殊情況下，請務必記住，如果集群已經運行并提供流量，則由于并行使用會影響結果，因此指標可能不準確。 然而，給定的值仍然可以用于以后的評估和比較。

此時，你可能想知道是否可以使用 Elasticsearch 集群中已有的自己的數據集。 答案是肯定的。 并非所有優(yōu)化或改進都只發(fā)生在 Elasticsearch 中。 它也可以在數據模型中完成，無論它是不斷發(fā)展的還是你根據數據使用方式看到的改進。 你可以使用 ES Rally 來衡量這些更改的影響。 接下來我們將展示如何創(chuàng)建你自己的 “track”。

使用你的數據創(chuàng)建你自己的 track

首先，我們來看看先決條件。 ES Rally 可以通過多種方式安裝，但以我的拙見，如果我們使用容器發(fā)行版，我們將節(jié)省時間并使事情變得簡單。

另一方面，我們應該考慮磁盤空間。 ES Rally 將下載你指定其下載的索引，因此，如果你正在考慮下載 1TB 索引，則需要牢記這一點。 在這一點上，數據大小確實很重要 —— 俗話說，“不多也不少” —— 所以定義一個有代表性的數據大小很重要。 如果它太小，攝取速度指標可能不具有代表性，但如果它太大，track 的創(chuàng)建時間將會很長。

為此準備數據的一種方法是使用 Elasticsearch Reindex API 和 max_docs 參數來創(chuàng)建一個索引，該索引的大小適合稍后運行的測試。

比如：

Reindex 索引過程可能需要 30 秒以上，因此建議使用 wait_for_completion=false 選項啟動它。 這將返回一個任務 ID，你可以使用該 ID 來跟蹤流程的進度和完成情況。

注意：目前，ES Rally 在創(chuàng)建自定義賽道時是單線程的。 這是為了避免影響集群或運行任務的計算機的性能。 因此，此過程可能需要一些時間才能完成。 使用 screen 或 tmux 等虛擬終端將允許你在后臺運行該進程。

入門

一旦確定了目標索引并且我們確保有足夠的空間，讓我們開始創(chuàng)建自定義 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 passworddocker 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

我們將得到類似于以下內容的輸出：

我們可以通過以下方式看到我們創(chuàng)建的自定義 track：

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

我們得到了什么？

我們來看看ES Rally上線后有什么。 這對于了解要適應什么以及如何有目標地運行未來的測試至關重要。

下圖顯示了 ES Rally 的默認配置、我們執(zhí)行的執(zhí)行日志以及我們創(chuàng)建的自定義 track。

• logging.json：這是我們定義事件如何記錄在日志文件中的地方。
• logs/rally.log：這是我們執(zhí)行 ES Rally 的日志被轉儲的地方。 默認情況下，該文件不會旋轉，因此我們可以配置一個外部工具（例如 logrotate）來執(zhí)行此操作。
• rally.ini：這是定義 ES Rally 配置的文件。
• track/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 的配置（索引、語料庫、時間表、challenges）

通常，我們將用來調整 ES Rally 運行的行為和測試的最相關文檔是 rally.ini 以及每個自定義 track name.json 和 track.json。

現在我們有了自定義 track，我們該如何使用它呢？

在不深入討論的情況下，讓我們調整我們已經運行的第一個測試，我們將使用該測試作為基線來衡量集群中未來的變化（假設保留變量以正確執(zhí)行）：

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}'"

這將為我們提供有關執(zhí)行的信息，但不用擔心，它會被保存以供以后使用。

我們使用 benchmark-only 的 pipeline 類型在已經運行的集群上啟動它，這就是為什么我們可以看到警告，告訴我們所采取的不同步驟可能具有誤導性的指標，此外還可以看到在 track.json 文件的 “schedule” 部分。

最后，指標部分將向我們顯示每個 metric 的值。

注意：可以通過配置 reporting 將指標保存到 Elasticsearch。

[...]

要深入了解每一項，我們必須查看官方文檔，其中對每一項都有詳細解釋。 然而，其中許多都是不言自明的，我們將找到與下面的案例最相關的內容。

改變的時刻

此時，我們已經有了自定義 track，并且已經使用 ES Rally 的默認配置以及該索引的原始映射和設置執(zhí)行了至少一次。

讓我們定義一個用例，數據模型優(yōu)化。 我之所以特別提出這一點，是因為我在許多部署中看到了性能的顯著提高和資源的顯著節(jié)省，甚至對存儲節(jié)省等基本資源成本也產生了積極的影響。

我知道這個用例可能是一個 challenge，特別是當我們無法控制數據模型時，因為它來自另一個領域或由外部應用程序管理。 但這將使我們能夠將數字轉化為性能和成本，從而更有效、更有利地、更優(yōu)化地使用 Elasticsearch。

我的同事 Mattias Brunnert 撰寫了一篇關于分析和優(yōu)化 Elasticsearch 中的存儲的博客文章，你可以在其中看到映射（或數據模型）在這方面的影響的示例。 我想強調的是，最佳的數據模型不僅會節(jié)省磁盤空間，還會提高攝取速度和查詢速度。

因此，利用我們現在所處的位置，探索以下 api _field_usage_stats，它將向你展示如何使用數據。 例如，你可以從 n 個字段的索引映射中看到你正在使用哪些字段以及你沒有使用哪些字段。 在此基礎上，你可以定義符合你的需求和實際使用情況的新的、更優(yōu)化的映射。

好吧，我們已經有了用例，我們分析了數據，并且發(fā)現我們可以改進自定義 track 中使用的索引的映射，因此我們繼續(xù)編輯 name.json 文件以使其適應結果 我們的分析。

我們可以找到類似的內容，其中我們看到默認行為，即在推斷文本數據類型時生成文本和關鍵字字段，但在本例中這顯然是不正確的。

因此，我們調整了映射并保存了更改以繼續(xù)重新運行相同的測試。

我們將得到與前一個類似的輸出：

評價時刻

現在我們已經執(zhí)行了兩次自定義 track，區(qū)別在于映射的優(yōu)化，我們將比較結果。

首先，正如我們之前提到的，結果存儲在我們賦予它們的持久性中：

在這些 JSON 文件中，我們可以單獨看到每個測試獲得的結果，但 ES Rally 還允許我們比較執(zhí)行的執(zhí)行情況。 為此，我們首先列出執(zhí)行的執(zhí)行：

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

并且通過獲取 Race ID，我們將執(zhí)行以下命令進行比較：

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

這將為我們提供兩次執(zhí)行的比較：

注：這些數據僅供參考，不代表實際值； 它們是在實驗室中執(zhí)行的，數據樣本由 100 個文檔組成。

使用 ES Rally 優(yōu)化 Elasticsearch

我們已經了解了如何將 ES Rally 與我們自己的數據集一起使用，如何修改它們以使其適應代表當前或未來情況的場景，以及如何比較和評估它們。 這將幫助我們衡量未來或計劃中可能發(fā)生的變化，并確定是否會產生積極或消極的影響。 如果我們定期執(zhí)行負載測試并確定我們距離達到 Elasticsearch 性能的操作或 SLA 限制的程度，那么它對于測量集群的性能也很有用。

ES Rally 可以通過多種方式進行配置，甚至可以以分布式方式執(zhí)行，以測試大型 Elasticsearch 環(huán)境 - 例如，當執(zhí)行 ES Rally 的單個節(jié)點不夠或者出現執(zhí)行瓶頸時。

盡管我們已經了解了如何從 Docker 運行它，但我還是給你留下了一個如何從 K8s 作為作業(yè)運行它的示例作為獎勵：

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

我鼓勵你查看官方文檔或聯系我們的咨詢團隊，以幫助你以最優(yōu)化的方式在你的組織中使用它，以增加最大的價值。

請記住，數據是決策的關鍵。

本文中描述的任何特性或功能的發(fā)布和時間安排均由 Elastic 自行決定。 當前不可用的任何特性或功能可能無法按時交付或根本無法交付。

原文：A step-by-step guide to creating custom ES Rally tracks | Elastic Blog