如何解决 Elasticsearch 查询缓慢的问题以获得更好的用户体验-Toy模板网

这篇具有很好参考价值的文章主要介绍了如何解决 Elasticsearch 查询缓慢的问题以获得更好的用户体验。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

作者：Philipp Kahr

如何解决 Elasticsearch 查询缓慢的问题以获得更好的用户体验,Elasticsearch,Observability,Elastic,elasticsearch,大数据,搜索引擎,运维,可用性测试

Elasticsearch Service 用户的重要注意事项：目前，本文中描述的 Kibana 设置更改仅限于 Cloud 控制台，如果没有我们支持团队的手动干预，则无法进行配置。我们的工程团队正在努力消除对这些设置的限制，以便我们的所有用户都可以启用内部 APM。本地部署不受此问题的影响。

对于任何使用 Elasticsearch 作为搜索引擎的人来说，识别查询并排除查询故障是一项需要掌握的关键技能。无论是电子商务、可观察性还是面向工作场所的搜索解决方案，缓慢的 Elasticsearch 都会对用户体验产生负面影响。

要查明慢速 Elasticsearch 查询，你可以使用慢速日志，它捕获在特定阈值运行的查询。正确设置慢日志阈值本身就是一个挑战。例如，在满负载下花费 500 毫秒的查询可能是可接受的，但在低负载下相同的查询可能是不可接受的。慢日志不区分并记录 500 毫秒以上的所有内容。慢日志很好地完成了它的工作，你可以根据阈值捕获不同级别的粒度。相反，跟踪可以查看所有查询，确定有多少查询在特定阈值内。

应用程序性能监控 (APM) 不再仅限于你的应用程序。使用 Elasticsearch 中的检测，我们现在可以将 Elasticsearch 添加为成熟的服务，而不是对应用程序堆栈的依赖。通过这种方式，我们可以获得比慢速日志更细致的性能视图。

对于以下示例，我们的数据语料库是 OpenWebText，它提供大约 40GB 的纯文本和大约 800 万个单独文档，这些文档在具有 32GB RAM 的 M1 Max Macbook 上本地运行。

让我们开始吧！

在 Elasticsearch 中激活跟踪是通过静态设置（在 elasticsearch.yml 中配置）和动态设置完成的，可以在运行时使用 PUT _cluster/settings 命令进行切换，其中动态设置之一是采样率。某些设置（例如采样率）可以在运行时切换。在 elasticsearch.yml 中我们要设置以下内容：

tracing.apm.enabled: true
tracing.apm.agent.server_url: "url of the APM server"

秘密令牌（或 API 密钥）必须位于 Elasticsearch 密钥库中。使用以下命令 elasticsearch-keystore add Tracing.apm.secret_token 或 Tracing.apm.api_key 应该可以在 <your elasticsearch install directory>/bin/elasticsearch-keystore 中找到密钥库工具。之后，你需要重新启动 Elasticsearch。有关跟踪的更多信息可以在我们的跟踪文档中找到。

一旦 APM 处于活动状态，我们就可以查看 Kibana 中的 APM 视图，并看到 Elasticsearch 自动捕获各种 REST API 端点。在这里，我们主要关注 POST /{index}/_search 调用，看看我们能从中获得什么。

如何解决 Elasticsearch 查询缓慢的问题以获得更好的用户体验,Elasticsearch,Observability,Elastic,elasticsearch,大数据,搜索引擎,运维,可用性测试

通过直接检查 GET /{index}/_search 框上的简单查询，我们看到以下瀑布细分。其中包含内部跨度（span），可以更深入地了解 Elasticsearch 在幕后所做的事情。我们看到这次搜索的总持续时间（86 毫秒）。

如何解决 Elasticsearch 查询缓慢的问题以获得更好的用户体验,Elasticsearch,Observability,Elastic,elasticsearch,大数据,搜索引擎,运维,可用性测试

查询附带的元数据包括有关 HTTP 标头、用户代理、Elasticsearch 节点位置（云提供商元数据、主机名、容器信息）、一些系统信息和 URL 详细信息的大量信息。使用一些基本的交易信息，我们可以创建一个透镜图，绘制平均交易持续时间，并允许我们查看是否存在上升或下降趋势。

我们的搜索应用程序

很高兴不再需要使用慢日志！我可以确定交易持续时间并确定在任何阈值下回答了多少搜索。然而，有一个挫折 —— Elasticsearch 不会捕获发送的查询（查询的具体内容是什么），因此我们知道查询花费了很长时间，但我们不知道查询是什么。

让我们测试一个示例搜索应用程序。在本例中，我们将使用一个简单的 Flask 应用程序，其中包含两个路由：search_single 和 search_phrase，它们将表示 Elasticsearch 中的 match 和 match_phrase 查询。例如，我们可以使用以下查询：

{
  "query": {
    "match": {
      "content": "support"
    }
  }
}

及

{
  "query": {
    "match_phrase": {
      "content": "support protest"
    }
  }
}

以下 Flask 代码实现了 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)

准备就绪后，我现在可以调用 curl -XGET “http://localhost:5000/search_single?q='microphone'” 来搜索术语 “microphone”。

我们主要将 APM 添加到我们的搜索应用程序中进行观察，但我们的 APM 代理捕获传出请求并使用元数据信息丰富它们。在我们的例子中，span.db.statement 包含 Elasticsearch 查询。在下面这个例子中，有人搜索了 window.

如何解决 Elasticsearch 查询缓慢的问题以获得更好的用户体验,Elasticsearch,Observability,Elastic,elasticsearch,大数据,搜索引擎,运维,可用性测试

将它们拼凑在一起

在我的 Flask 服务中，我将查询大小设置为 5,000，这意味着 Elasticsearch 应在单个 JSON 响应中为我提供最多 5,000 个匹配文档。这是一个很大的数字，并且大部分时间都花在从磁盘检索这么多文档上。将其更改为前 100 个文档后，我可以通过比较快速识别仪表板中发生的情况。

在 APM 视图中查看 transaction 并激活关键路径的实验室功能会创建一个覆盖层，向我们显示应用程序将时间花在哪里。

如何解决 Elasticsearch 查询缓慢的问题以获得更好的用户体验,Elasticsearch,Observability,Elastic,elasticsearch,大数据,搜索引擎,运维,可用性测试

之后，我使用字段 transaction.duration.us、es_query_took、transaction.name 创建了一个仪表板。一般 KQL 过滤器包含 service.name、processor.event: transaction、transaction.name: POST /{index}/_search。

附加提示：转到数据视图管理 > 选择包含 APM 数据流的数据视图 > 选择 transaction.duration.us 字段 > 并将格式更改为 duration。现在它会自动以人类可读的输出而不是 microseconds 的形式呈现它。

利用 Lens 注释（annotation）功能，我们可以在中间 Lens 中看到，更改为 100 个文档使平均搜索 transaction 量下降了很多。不仅如此，查看右上角的记录总数。由于我们可以更快地搜索，因此我们有更高的吞吐量！我真的很喜欢直方图，因此我在顶行的中间创建了一个直方图，其中 X 轴为交易持续时间，Y 轴为记录数。此外，APM 还提供指标，因此我们可以随时确定发生了多少 CPU% 使用情况以及 JVM 堆、非堆使用情况、线程计数和更多有用信息。

如何解决 Elasticsearch 查询缓慢的问题以获得更好的用户体验,Elasticsearch,Observability,Elastic,elasticsearch,大数据,搜索引擎,运维,可用性测试

结论

这篇博文向您展示了将 Elasticsearch 作为仪表化应用程序并更轻松地识别瓶颈是多么重要。此外，你还可以使用事务持续时间作为异常检测的指标，为你的应用程序进行 A/B 测试，并且再也不用怀疑 Elasticsearch 是否感觉更快，因为你现在有数据可以回答这个问题。此外，从用户代理收集到查询的所有元数据都可以帮助你排除故障。

可以从此处导入仪表板和数据视图。

警告
Elasticsearch 内部的 transaction duration 存在问题。此问题已在即将发布的 8.9.1 版本中修复。在此之前，transaction 使用错误的时钟，这会扰乱整体持续时间。

本文中描述的任何特性或功能的发布和时间安排均由 Elastic 自行决定。当前不可用的任何特性或功能可能无法按时交付或根本无法交付。

原文：How to troubleshoot slow Elasticsearch queries for better user experience | Elastic Blog文章来源地址https://www.toymoban.com/news/detail-634226.html

到了这里，关于如何解决 Elasticsearch 查询缓慢的问题以获得更好的用户体验的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！