Observability：和你的 AutoOps 聊聊

原创于 2025-12-19 09:16:54 发布 · 686 阅读

21 ·

CC 4.0 BY-SA版权

本文为博主原创文章，未经博主允许不得转载。

文章标签：

#elasticsearch #大数据 #搜索引擎 #全文检索 #数据库

Elastic 同时被 2 个专栏收录

2196 篇文章

订阅专栏

Observability

322 篇文章

订阅专栏

作者：来自 Elastic val Val Crettaz

AutoOps 通过实时收集、分析和关联数百个指标，帮助你诊断 Elasticsearch 集群中的问题，提供根因分析和准确的解决路径。每次检测到问题时，AutoOps 会记录并在时间轴上显示，就像下图所示。你可以轻松看到哪些问题经常出现，颜色表示问题的严重程度，颜色越深表示在特定时间范围内该类型事件发生的次数越多。

当你需要紧急解决问题且时间紧迫时，你可能需要一些帮助来确定从哪里开始调查以及重点关注什么。利用 Elastic AI，我们能够将上图中看到的离散级联事件关联成一个连贯的故事，直至识别根因及应采取的修复措施。

我们选择了 “以聊天为先” 的方式，将新发布的 Elastic Agent Builder 接入上述时间轴上的所有洞察数据。话不多说，我们开始与它聊天，下面是过程展示。

热身阶段

我们的首要目标是解决正在影响集群的当前问题，因此我们以如下方式开始对话：

在快速查看索引映射以确定如何查询洞察数据后，Elastic Agent Builder 创建了几个后续查询，以检索当前打开的高严重性问题，将它们按类型和频率分类，深入其上下文以了解涉及的节点或索引，检索与已识别节点和索引相关的其他洞察，最后阅读洞察描述，形成了如下所示的初步回答：

哇！！仅用 79 秒就处理了超过一万条事件，并将它们关联成我们能够理解的故事。现在让我们深入分析一下。

问题 #1：节点 instance-368 上的高搜索队列

查看第一个问题及受影响的索引，我们甚至不需要查看慢日志，因为我们知道问题与 Kibana 警报规则有关。我们可以很容易判断 Kibana 在执行这些规则时也遇到了困难，但规则太多，无法确定哪些有问题。因此，既然建议查看长时间运行的查询，而 AutoOps 可以捕获它们，那就找出是哪条查询导致这个问题吧：

几秒钟内，出现了如下 DSL 查询，我们能够轻松在 AutoOps 捕获的 X-Opaque-ID HTTP 头中找到警报规则的 ID（如下图红色标注部分）。

我们回到 Kibana，对查询做了些改进（例如，不需要检索 10000 条命中）。我们还调整了其调度频率，之前设置得过高，最终保存了该规则。几分钟后，我们就看到 instance-368 的搜索队列降至 0。完成 ✅

问题 #2：数据节点负载不平衡

接下来是什么？第二个问题不言自明。由于建议查看分片分配策略，通过快速查看 AutoOps 的分片视图，我们能够轻松定位三个高索引活动的索引，并在已识别的节点上发现一些索引热点。

由于这些索引只有三个主分片，全部分配到同一组节点上，且其增长速度超过预期，我们决定将分片数量加倍，因为有足够的热点节点来处理额外分片。随后，我们对相应的数据流进行了切换，热点消失。完成 ✅

问题 #3：数据冻结节点负载不平衡

为排查最后一个问题，我们再次利用 Elastic Agent Builder 帮助分析。我们基本上让它“自我验证”其建议，并要求它查找在已识别索引上运行的任何查询。显然还有改进空间，它本应自动应用自身建议来找出搜索流量的来源。但无论如何，我们继续询问，看看接下来发生了什么：

几秒钟后，它返回了一条运行了 158 分钟（>2 小时 30 分钟）的长时间查询，涉及所有 partial-.ds-synthetics-http-default* 索引。与上面的第一个问题类似，查看该查询我们发现它在处理三个月的数据（其中两个月的数据已进入冻结层），并试图聚合大量桶。

此外，X-Opaque-ID HTTP 头显示了查询来源的仪表板 ID——Global-Synthetics-Health（上图红色标注）。访问该仪表板后，我们发现它包含许多在相同数据视图上运行的 Lens 可视化。这种情况并不罕见，但仪表板保存的三个月时间范围并不适用，因为热层只保留一个月的数据。我们将时间范围改为最近 10 天，终止了长时间运行的查询，冻结层立即得到缓解。完成 ✅

总结

好，让我们回顾一下刚刚发生的事情：我们有一个紧急问题需要解决，决定利用 AutoOps，它会跟踪集群中所有最近检测到的事件。了解今天发生的问题往往可能由之前一个或多个问题引起，能够关联事件并理清它们的级联关系，对于理解根因并采取措施至关重要。在几分钟内，借助运行在 AutoOps 洞察数据之上的 Elastic Agent Builder，我们快速获得了集中关注点和处理方法的有力指导。现在我们的集群再次“呼吸”，多亏了 Elastic AI 驱动的 AutoOps 洞察！

当然，这还不完美，还有许多改进空间，但我们已经展示了如何利用 AI 将所有洞察关联为可执行建议，从而大幅加快集群恢复过程。敬请关注，我们将在不久的将来通过在 AutoOps 中引入 AI 助手来实现这一目标。

原文：https://discuss.elastic.co/t/dec-6th-2025-en-a-little-chat-with-your-autoops/383721