作者：Philipp Kahr
Elasticsearch Service 用戶(hù)的重要注意事項(xiàng)：目前，本文中描述的 Kibana 設(shè)置更改僅限于 Cloud 控制臺(tái)，如果沒(méi)有我們支持團(tuán)隊(duì)的手動(dòng)干預(yù)，則無(wú)法進(jìn)行配置。 我們的工程團(tuán)隊(duì)正在努力消除對(duì)這些設(shè)置的限制，以便我們的所有用戶(hù)都可以啟用內(nèi)部 APM。 本地部署不受此問(wèn)題的影響。
對(duì)于任何使用 Elasticsearch 作為搜索引擎的人來(lái)說(shuō)，識(shí)別查詢(xún)并排除查詢(xún)故障是一項(xiàng)需要掌握的關(guān)鍵技能。 無(wú)論是電子商務(wù)、可觀(guān)察性還是面向工作場(chǎng)所的搜索解決方案，緩慢的 Elasticsearch 都會(huì)對(duì)用戶(hù)體驗(yàn)產(chǎn)生負(fù)面影響。
要查明慢速 Elasticsearch 查詢(xún)，你可以使用慢速日志，它捕獲在特定閾值運(yùn)行的查詢(xún)。 正確設(shè)置慢日志閾值本身就是一個(gè)挑戰(zhàn)。 例如，在滿(mǎn)負(fù)載下花費(fèi) 500 毫秒的查詢(xún)可能是可接受的，但在低負(fù)載下相同的查詢(xún)可能是不可接受的。 慢日志不區(qū)分并記錄 500 毫秒以上的所有內(nèi)容。 慢日志很好地完成了它的工作，你可以根據(jù)閾值捕獲不同級(jí)別的粒度。 相反，跟蹤可以查看所有查詢(xún)，確定有多少查詢(xún)?cè)谔囟ㄩ撝祪?nèi)。
應(yīng)用程序性能監(jiān)控 (APM) 不再僅限于你的應(yīng)用程序。 使用 Elasticsearch 中的檢測(cè)，我們現(xiàn)在可以將 Elasticsearch 添加為成熟的服務(wù)，而不是對(duì)應(yīng)用程序堆棧的依賴(lài)。 通過(guò)這種方式，我們可以獲得比慢速日志更細(xì)致的性能視圖。
對(duì)于以下示例，我們的數(shù)據(jù)語(yǔ)料庫(kù)是 OpenWebText，它提供大約 40GB 的純文本和大約 800 萬(wàn)個(gè)單獨(dú)文檔，這些文檔在具有 32GB RAM 的 M1 Max Macbook 上本地運(yùn)行。
讓我們開(kāi)始吧！
在 Elasticsearch 中激活跟蹤是通過(guò)靜態(tài)設(shè)置（在 elasticsearch.yml 中配置）和動(dòng)態(tài)設(shè)置完成的，可以在運(yùn)行時(shí)使用 PUT _cluster/settings 命令進(jìn)行切換，其中動(dòng)態(tài)設(shè)置之一是采樣率。 某些設(shè)置（例如采樣率）可以在運(yùn)行時(shí)切換。 在 elasticsearch.yml 中我們要設(shè)置以下內(nèi)容：
tracing.apm.enabled: true
tracing.apm.agent.server_url: "url of the APM server"秘密令牌（或 API 密鑰）必須位于 Elasticsearch 密鑰庫(kù)中。 使用以下命令 elasticsearch-keystore add Tracing.apm.secret_token 或 Tracing.apm.api_key 應(yīng)該可以在 <your elasticsearch install directory>/bin/elasticsearch-keystore 中找到密鑰庫(kù)工具。 之后，你需要重新啟動(dòng) Elasticsearch。 有關(guān)跟蹤的更多信息可以在我們的跟蹤文檔中找到。
一旦 APM 處于活動(dòng)狀態(tài)，我們就可以查看 Kibana 中的 APM 視圖，并看到 Elasticsearch 自動(dòng)捕獲各種 REST API 端點(diǎn)。 在這里，我們主要關(guān)注 POST /{index}/_search 調(diào)用，看看我們能從中獲得什么。
通過(guò)直接檢查 GET /{index}/_search 框上的簡(jiǎn)單查詢(xún)，我們看到以下瀑布細(xì)分。 其中包含內(nèi)部跨度（span），可以更深入地了解 Elasticsearch 在幕后所做的事情。 我們看到這次搜索的總持續(xù)時(shí)間（86 毫秒）。
查詢(xún)附帶的元數(shù)據(jù)包括有關(guān) HTTP 標(biāo)頭、用戶(hù)代理、Elasticsearch 節(jié)點(diǎn)位置（云提供商元數(shù)據(jù)、主機(jī)名、容器信息）、一些系統(tǒng)信息和 URL 詳細(xì)信息的大量信息。 使用一些基本的交易信息，我們可以創(chuàng)建一個(gè)透鏡圖，繪制平均交易持續(xù)時(shí)間，并允許我們查看是否存在上升或下降趨勢(shì)。
我們的搜索應(yīng)用程序
很高興不再需要使用慢日志！ 我可以確定交易持續(xù)時(shí)間并確定在任何閾值下回答了多少搜索。 然而，有一個(gè)挫折 —— Elasticsearch 不會(huì)捕獲發(fā)送的查詢(xún)（查詢(xún)的具體內(nèi)容是什么），因此我們知道查詢(xún)花費(fèi)了很長(zhǎng)時(shí)間，但我們不知道查詢(xún)是什么。
讓我們測(cè)試一個(gè)示例搜索應(yīng)用程序。 在本例中，我們將使用一個(gè)簡(jiǎn)單的 Flask 應(yīng)用程序，其中包含兩個(gè)路由：search_single 和 search_phrase，它們將表示 Elasticsearch 中的 match 和 match_phrase 查詢(xún)。 例如，我們可以使用以下查詢(xún)：
{
"query": {
"match": {
"content": "support"
}
}
}及
{
"query": {
"match_phrase": {
"content": "support protest"
}
}
}以下 Flask 代碼實(shí)現(xiàn)了 search_single 路由。 search_phrase 非常相似，只是它使用 match_phrase 而不是 match。
@app.route("/search_single", methods=["GET"])
def search_single():
query = request.args.get("q", "")
if not query.strip():
return jsonify({"error": "No search query provided"}), 400
try:
result = es.search(
index=ES_INDEX, query={"match": {"content": query}}
)
hits = result["hits"]["hits"]
response = []
for hit in hits:
response.append(
{
"score": hit["_score"],
"content": hit["_source"]["content"],
}
)
return jsonify(response)準(zhǔn)備就緒后，我現(xiàn)在可以調(diào)用 curl -XGET “http://localhost:5000/search_single?q='microphone'” 來(lái)搜索術(shù)語(yǔ) “microphone”。
我們主要將 APM 添加到我們的搜索應(yīng)用程序中進(jìn)行觀(guān)察，但我們的 APM 代理捕獲傳出請(qǐng)求并使用元數(shù)據(jù)信息豐富它們。 在我們的例子中，span.db.statement 包含 Elasticsearch 查詢(xún)。 在下面這個(gè)例子中，有人搜索了 window.
將它們拼湊在一起
在我的 Flask 服務(wù)中，我將查詢(xún)大小設(shè)置為 5,000，這意味著 Elasticsearch 應(yīng)在單個(gè) JSON 響應(yīng)中為我提供最多 5,000 個(gè)匹配文檔。 這是一個(gè)很大的數(shù)字，并且大部分時(shí)間都花在從磁盤(pán)檢索這么多文檔上。 將其更改為前 100 個(gè)文檔后，我可以通過(guò)比較快速識(shí)別儀表板中發(fā)生的情況。
在 APM 視圖中查看 transaction 并激活關(guān)鍵路徑的實(shí)驗(yàn)室功能會(huì)創(chuàng)建一個(gè)覆蓋層，向我們顯示應(yīng)用程序?qū)r(shí)間花在哪里。
之后，我使用字段 transaction.duration.us、es_query_took、transaction.name 創(chuàng)建了一個(gè)儀表板。 一般 KQL 過(guò)濾器包含 service.name、processor.event: transaction、transaction.name: POST /{index}/_search。
附加提示：轉(zhuǎn)到數(shù)據(jù)視圖管理 > 選擇包含 APM 數(shù)據(jù)流的數(shù)據(jù)視圖 > 選擇 transaction.duration.us 字段 > 并將格式更改為 duration。 現(xiàn)在它會(huì)自動(dòng)以人類(lèi)可讀的輸出而不是 microseconds 的形式呈現(xiàn)它。
利用 Lens 注釋?zhuān)╝nnotation）功能，我們可以在中間 Lens 中看到，更改為 100 個(gè)文檔使平均搜索 transaction 量下降了很多。 不僅如此，查看右上角的記錄總數(shù)。 由于我們可以更快地搜索，因此我們有更高的吞吐量！ 我真的很喜歡直方圖，因此我在頂行的中間創(chuàng)建了一個(gè)直方圖，其中 X 軸為交易持續(xù)時(shí)間，Y 軸為記錄數(shù)。 此外，APM 還提供指標(biāo)，因此我們可以隨時(shí)確定發(fā)生了多少 CPU% 使用情況以及 JVM 堆、非堆使用情況、線(xiàn)程計(jì)數(shù)和更多有用信息。
?
結(jié)論
這篇博文向您展示了將 Elasticsearch 作為儀表化應(yīng)用程序并更輕松地識(shí)別瓶頸是多么重要。 此外，你還可以使用事務(wù)持續(xù)時(shí)間作為異常檢測(cè)的指標(biāo)，為你的應(yīng)用程序進(jìn)行 A/B 測(cè)試，并且再也不用懷疑 Elasticsearch 是否感覺(jué)更快，因?yàn)槟悻F(xiàn)在有數(shù)據(jù)可以回答這個(gè)問(wèn)題。 此外，從用戶(hù)代理收集到查詢(xún)的所有元數(shù)據(jù)都可以幫助你排除故障。
可以從此處導(dǎo)入儀表板和數(shù)據(jù)視圖。
警告
Elasticsearch 內(nèi)部的 transaction duration 存在問(wèn)題。 此問(wèn)題已在即將發(fā)布的 8.9.1 版本中修復(fù)。 在此之前，transaction 使用錯(cuò)誤的時(shí)鐘，這會(huì)擾亂整體持續(xù)時(shí)間。本文中描述的任何特性或功能的發(fā)布和時(shí)間安排均由 Elastic 自行決定。 當(dāng)前不可用的任何特性或功能可能無(wú)法按時(shí)交付或根本無(wú)法交付。文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-634226.html
原文：How to troubleshoot slow Elasticsearch queries for better user experience | Elastic Blog文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-634226.html
到了這里，關(guān)于如何解決 Elasticsearch 查詢(xún)緩慢的問(wèn)題以獲得更好的用戶(hù)體驗(yàn)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
