番禺网站建设技术,小清新网站设计,网站代码在哪看,苏州手机网站开发公司作者#xff1a;Philipp Kahr Elasticsearch Service 用户的重要注意事项#xff1a;目前#xff0c;本文中描述的 Kibana 设置更改仅限于 Cloud 控制台#xff0c;如果没有我们支持团队的手动干预#xff0c;则无法进行配置。 我们的工程团队正在努力消除对这些设置的限制…作者Philipp Kahr 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 调用看看我们能从中获得什么。 通过直接检查 GET /{index}/_search 框上的简单查询我们看到以下瀑布细分。 其中包含内部跨度span可以更深入地了解 Elasticsearch 在幕后所做的事情。 我们看到这次搜索的总持续时间86 毫秒。 查询附带的元数据包括有关 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}), 400try:result es.search(indexES_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?qmicrophone” 来搜索术语 “microphone”。
我们主要将 APM 添加到我们的搜索应用程序中进行观察但我们的 APM 代理捕获传出请求并使用元数据信息丰富它们。 在我们的例子中span.db.statement 包含 Elasticsearch 查询。 在下面这个例子中有人搜索了 window. 将它们拼凑在一起
在我的 Flask 服务中我将查询大小设置为 5,000这意味着 Elasticsearch 应在单个 JSON 响应中为我提供最多 5,000 个匹配文档。 这是一个很大的数字并且大部分时间都花在从磁盘检索这么多文档上。 将其更改为前 100 个文档后我可以通过比较快速识别仪表板中发生的情况。
在 APM 视图中查看 transaction 并激活关键路径的实验室功能会创建一个覆盖层向我们显示应用程序将时间花在哪里。 之后我使用字段 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 作为仪表化应用程序并更轻松地识别瓶颈是多么重要。 此外你还可以使用事务持续时间作为异常检测的指标为你的应用程序进行 A/B 测试并且再也不用怀疑 Elasticsearch 是否感觉更快因为你现在有数据可以回答这个问题。 此外从用户代理收集到查询的所有元数据都可以帮助你排除故障。
可以从此处导入仪表板和数据视图。 警告 Elasticsearch 内部的 transaction duration 存在问题。 此问题已在即将发布的 8.9.1 版本中修复。 在此之前transaction 使用错误的时钟这会扰乱整体持续时间。 本文中描述的任何特性或功能的发布和时间安排均由 Elastic 自行决定。 当前不可用的任何特性或功能可能无法按时交付或根本无法交付。 原文How to troubleshoot slow Elasticsearch queries for better user experience | Elastic Blog
