作者：来自 Elastic Valentin Crettaz
探索 Kibana 中的查询活动，它为你提供正在进行的搜索工作负载的实时视图，让你可以查看正在运行的内容，将其追溯到其来源，并在安全时取消
测试 Elastic 的前沿开箱即用功能。深入了解 Elasticsearch Labs 仓库中的示例 notebooks，开始免费的云试用，或者现在就在你的本地机器上试用 Elastic。
直到现在，当性能开始下降时，很难看到到底有哪些搜索工作负载正在运行。查询活动通过在 Kibana 中突出显示正在运行的搜索来解决这个问题。你可以看到正在进行的内容，发现资源消耗大的任务，并在关键时刻采取行动。在这篇博客文章中，我们将介绍这一新功能以及如何开始使用。
当 "某些东西变慢" 终于有了答案
查询活动（Query activity）现在已经在你的 Elastic Cloud Serverless 项目中可用。对于 Elastic Cloud Hosted 和 Elastic Self-Managed 集群，它随 Kibana 9.4 一起发布，并在该版本的所有部署和集群中可用。查询活动是 Kibana 中基于 Elasticsearch Tasks Management API 的视图。它专为与搜索相关的任务而构建，支持任何查询语言，包括 Elasticsearch Query Language（ ES|QL ）、 DSL 、 SQL 和 Event Query Language（ EQL ）。
事情总是以同样的方式开始。某个星期五，有人给你发消息： Discover 好像卡住了。高管仪表板无法加载。我们是不是改了什么？你打开监控页面，盯着 CPU 看，也许再查看一下日志，但你仍然在猜测。这是一个巨大的 ES|QL pipeline 吗？是一个没人记得的仪表板？还是一个在最糟糕时间默默工作的后台规则？集群本身并不是故意神秘。正在进行的任务只是不可见，除非你喜欢待在 Dev Tools 里，通过任务 ID 和一些 JSON 片段来还原整个过程。
我们为所有曾经低声说过"只要告诉我现在在运行什么就行了"的人构建了查询活动。这是 Kibana 中的一个新界面，用于列出 ES|QL 、 DSL 、 SQL 或 EQL 中的活动搜索任务。它会显示当前正在消耗你集群资源的查询，并提供足够的上下文，让你无需四处查找就能从恐慌转向诊断。
你熟悉的流程，以及一分钟的改写版本
如果你使用 Elasticsearch 超过一周，你一定经历过那套老流程。第一幕 ，有人说集群感觉变慢了。第二幕 ，你在 shards、 heap、慢日志以及写在便签上的任务 ID 之间来回奔波。几个小时过去了，你仍然无法说出是哪一个查询。第三幕，也许你在晚饭前找到了罪魁祸首，或者下个月第一幕再次上演，同一个 "反派" 换了个假胡子又出现。
查询活动（Open Query activity ）用一个默认流程取代了这种漫无目的的第二幕。故事还是一样，但被压缩成大约一分钟内从症状到证据再到来源再到行动。把这段内容粘贴到你的 runbook 中，或者发到你的值班频道里。这就是这个功能在实践中的全部创新。
-
一旦第一幕出现，立即打开查询活动（Query activity ）。在 Elastic Cloud Hosted 和 Elastic Self-Managed 集群中，进入 Stack Management ，然后选择 Cluster performance。在 Elastic Cloud Serverless 中，进入 Admin and Settings，然后选择 Project performance。在你开始猜测之前就这样做。
-
刷新查询列表一次，这样你看到的是当前的情况，而不是五分钟前的数据。
-
暴露压力 。按运行时间排序，或收紧"运行时间（Run time）"筛选器，直到高消耗任务浮到顶部。
-
打开 最严重问题项的详情面板 。你将看到持续时间、查询类型、索引范围以及完整的查询文本。这就是你的证据，无需打开 Dev Tools
-
定位责任方 。使用 trace.id 跳转到 Discover，并根据该 trace 在审计或查询日志中过滤，或者使用 X-Opaque-Id 来确定该查询来源于哪个仪表板、已保存搜索或规则
-
解决第三幕 。让查询完成，修复上游，或者在合适的时候并且 Elasticsearch 表示该任务可以取消时将其取消
这就是一次完成过去需要三幕的流程。你得到的是归因，而不是传闻；是决策，而不是表演。
查询活动深入解析
上面的一分钟流程是一种习惯。接下来是其背后的机制： Kibana 中使这种改写成为可能的具体控制和信号。你可以看到正在执行的内容、运行了多久、来自哪里，以及接下来该做什么，而无需在多个标签页之间拼凑线索。
在底层，这个视图由 Elasticsearch 的 Tasks Management API 提供支持，用于处理长时间运行的搜索任务。它被转化为一个为速度而设计的操作型 UI。你可以快速找到异常项，检查丰富的细节，并自信地采取行动。
以下是 UI 如何支撑 runbook 中每个步骤。
主视图是一个可过滤的运行中查询列表。它包含一个搜索栏，你可以匹配表中的任何内容，包括任务 ID。你还可以使用运行时间、查询语言以及来源（例如 Discover、 Dashboard 等界面）进行筛选。你可以自行定义什么是 "噪音"。
刷新是有意设计为手动的。表格不会自动刷新。你在准备好时点击 Refresh， UI 会显示上一次刷新的时间。你不应该去猜列表是否已经过时。
当你点击任务 ID 时，会打开一个详情面板。它会显示开始时间、运行时间、查询涉及的索引数量以及完整的查询文本。当存在 X-Opaque-Id 时，它可以帮助你将 Elasticsearch 查询追溯到其在 Kibana 中的来源，从而把 "神秘负载" 变成 "那个仪表板、那个版本"。通过前后导航，你可以在队列中逐个查看，而无需返回列表。当 trace.id 可用时，你可以打开已预先按该 trace 过滤的 Discover。这在事件沟通频道已经很繁忙时尤其有帮助。
在任务可以取消的情况下，你可以从列表或详情面板发起取消请求。这里有一个刻意设计的确认步骤。在你确认之后，取消控件会显示一个加载状态，直到 Elasticsearch 报告该任务确实已停止。目标是避免误操作，而不是追求快速误操作。
查看和管理活动查询任务需要相应的集群权限。 UI 会清楚地提示缺失的权限。例如，没有 cluster:manage 权限的用户可能无法执行破坏性操作；没有 cluster:monitoring 权限的用户可能无法查看任务详情。你不应该看到一个空白界面，让人感觉整个系统在和你玩捉迷藏。
如果你一直在关注我们更广泛的查询可观测性故事，这就是 "实时端" 的部分。它展示的是此刻在产品中发生的事情，并且提供你可以直接使用的控制能力。随着时间推移，当你需要判断是否 "以前发生过类似情况" 时，可以把它与历史视图结合，例如查询日志，以及 AutoOps 中关于长时间运行搜索任务的洞察。当你需要回答 "这一分钟到底是什么在消耗集群资源" 时，就从 Kibana 中新的 Query activity UI 开始。
适用人群（以及谁会成为关键角色）
集群与平台管理员得到的是最直接的收益：更快的事件响应，以及更少时间把 API 转译成给利益相关方看的叙述。
卓越中心（Centers of excellence - CoE）和内部搜索专家则获得同样重要的价值：一个可以截图的教学时刻。这是导致共享容量被拖垮的查询模式。这是当所有人都很忙时，"交互式" 与 "后台" 压力的真实差异。
任何承担服务级别协议（SLA）责任的人，都能更清晰地连接用户体验（"应用很慢"）与搜索现实（"这三个请求仍在运行，其中一个非常庞大"）。
你不需要写出这个查询的人，也可以成为那个冷静解释集群状况的人。这正是这个功能的核心目的。
并不是所有任务都可以被取消，深度调优工作依然有其意义。Query activity 不会替你修复查询，但它能在几秒内指出哪些查询可能需要关注，并在你使用更重型工具之前，提供更快的证据、更清晰的归因，以及更好的决策。
在哪里找到它
你可以在各部署模式的性能区域找到 Query activity。在 Elastic Cloud Hosted 和 Elastic Self-Managed 集群中，进入 Stack Management，然后进入 Cluster performance。在 Serverless 项目中，进入 Admin and Settings，然后进入 Project performance。
阈值设置：进入 Stack Management，然后打开 Advanced Settings。 running_queries:minRunningTime 默认是 100 ms。只有运行时间超过该阈值的任务才会显示。这样你可以过滤噪音，而不会被瞬时任务淹没。
下一步做什么
在集群平稳时完整走一遍这六步流程。当第一幕事件发生时，你就不会在压力下学习一个新的 UI。然后在下一次空闲时再重复一次。从 "假设" 到 "看见" 的差距，就是整个产品的价值所在。
如果你还没有使用 Elastic Cloud，你仍然可以在 elastic.cloud/registration 上动手体验整个技术栈。
原文：https://www.elastic.co/search-labs/blog/kibana-query-activity-long-running-searches