当前位置：首页 > news >正文

从告警到根因只需几秒：基于 AI 驱动的可观测性，使用 Elastic Agent Builder 和 Workflows

news 2026/6/19 20:14:02

作者：来自 Elastic Aleksandar Panov

Elastic Agent Builder 和 Workflows 替代仪表盘排查：一个问题即可浮现根本原因，跨周关联指标，并计算业务影响；然后工作流提交工单。

Elastic Agent Builder 和 Workflows 将可观测性从 “仪表盘搜索” 转变为 agentic 故障排查。在一次对话中，agent 会编写并执行 ES|QL 查询，在 3 周时间窗口内关联出行量、交付时长以及争议率，并得出约 36,669 美元的未交付收入估算，而无需人工操作任何面板。本文将完整展示这一过程：从 FastFreight Co 的流量告警开始，到一个具备检查能力的运营 agent，再到自动创建 Jira 工单的工作流。

AI 之前的方式：仪表盘、阈值与手动关联

在 AI 出现之前，你通常会配置 Kibana Alerts 或 Watcher 这类阈值规则，例如当过去 10 分钟错误率超过 5% 时触发告警。当告警触发后，你需要打开相关仪表盘视图，手动关联日志、追踪与指标数据，并寻找问题根因。因此，首先引起注意的是告警本身 —— 某个阈值被触发并产生告警，在这个案例中是出行量的断崖式下降。

有了合适的仪表盘，你可以发现确实出了问题，但如果你不够熟悉，这些仪表盘无法告诉你原因，也无法跨多个面板进行关联，更重要的是，无法计算业务影响。

识别 “为什么” 以及回答影响相关的问题需要很高的专业能力。例如，虽然前 3 个面板显示的是与同一供应商相关的问题，但最后一个面板是无关的，它显示的是另一个供应商的问题。

经验丰富的仪表盘操作员能够识别这种模式：

信号	解读
出行量下降，时长上升，争议上升	供应商的运营故障
所有指标正常，但成本飙升	账单异常

对某些仪表盘和视图所代表含义的理解需要大量投入。理解你所处理问题的性质和原因需要时间。通常，这些知识要么存在于你的脑海中，要么最终记录在某个 wiki 中。主要缺点是系统可以检测并展示数据，但无法对底层数据行为进行推理。而 agent 可以做到。

Elastic Agent Builder：提问即答案

AI Agent 的本质，是将那些被写死在仪表盘和指标中的特定问题与组织中少数人掌握的经验知识，转化为可以被公司中任何人使用的灵活 agent，从而按需探索数据并即时生成洞察。

Agent Builder 是 Elastic 的 AI 对话式平台，用于通过自然语言与数据交互。接下来我们将基于前面提到的出行量下降告警，对供应商交易日志进行排查。

使用 Agent Builder 时，你可以使用内置模型，或通过 connectors 连接其他模型提供方，包括在你环境中运行的本地 LLM。在这个示例中，我们通过 connector 使用了 GPT-4o，但任何受支持的模型都可以使用。

选择好 LLM 之后，你可以进入 Agent Builder，直接让 agent 分析数据，并即时生成查询、表格和图表。

接下来我们看看，当你不再点击各个面板，而是直接提问时，会发生什么。

我们当前有一个活跃告警：FastFreight Co（vendor_id=1）在过去 24 小时内的出行量已下降到 100 以下。我们的基线大约是每天 229 次出行。你能确认 FastFreight 当前的每日出行量，并展示过去 3 周的变化情况吗？

一个问题就足够了。agent 拉取了数据，而表格已经确认出行量正在持续下降。

接下来我们需要找出退化从什么时候开始。agent 生成并执行 ES|QL 查询，来定位首次低于基线平均值的日期，从而确定下降的起点。

上面的截图展示了幕后发生的事情。agent 编写 ES|QL，执行查询，并发现性能退化大约从 3 月 1 日开始。从 3 月 11 日起，下降变得更加严重。

在此基础上，再追问一个问题就揭示了另外两个红色信号：平均交付时长从 12.6 分钟上升到 46 分钟，而争议率从 0.3% 上升到 20%。agent 在一次回答中就完成了跨指标关联。

再经过几轮迭代，就能从问题诊断推进到业务影响分析。

Agent 计算出如下汇总结果：

预期出行量：3 月 1 日到 3 月 19 日，约 228 次/天 = 约 4,328 次
实际出行量：1,884 次
缺失出行量：约 2,444 次
损失收入：缺失出行量 × 基线平均值（约 $15.00）

预计损失：约 $36,669 的未交付收入。

因此，业务影响可以通过一次请求生成。在 AI 出现之前，如果不借助外部工具，这是不可能完成的。

你可以将 agent 连接到你的私有数据，并获得基于 RAG 的回答。这使它能够使用你组织拥有的信息，返回更精确的答案，而不是通用的 LLM 响应。

从通用 agent 到专属分析师：具备领域记忆的自定义 agent

因此，可观测性已经从 “查看特定图表并知道去哪里找问题”，转变为 “描述要检查什么”，而 agent 会在数据中自动导航，并以自动生成的图表、曲线、表格和报告的形式将结果返回给你。你可以询问“是否有任何异常”，agent 会在你的索引中查找异常值。

不过，每一次与通用 agent 的对话都从零开始。你必须重新解释数据、阈值以及需要检查的内容。自定义能力也有限。你无法定义特定的提示或工具，也无法在 Kibana 之外使用你的 agent。Agent Builder 正是为了解决这个问题，它允许你创建基于领域的专用分析师（agent），供不同团队从各自视角使用。

下面是当你选择一个自定义 agent 并开始对话时的效果。

在使用 agents 方面，有多种可选方式，从使用内置 agents 和工具，到创建你自己的 agents 和工具。

你可以通过 MCP server 将它们连接到外部工具，或将其作为外部资源使用。自定义 agents 通过自定义指令构建（例如“你是高级车队运营分析师……”），并结合 ES|QL 参考，从而对准确性和安全性进行更细粒度的控制。

通过使用特定的 agent，你可以更快发现问题，深入关联数据，诊断故障，并更迅速地采取行动。

在我们的示例中，“OpsWatch” 是运营团队的 agent。它了解出行量、交付时长以及人员配置水平。但它不了解费用，也不了解 SLA。

在被询问进行运营评估后，它会基于真实数据给出结论与建议。用其他方法需要数小时完成的事情，在这里几秒钟就可以完成。

最后再说一点关于作用范围边界。当被问及成本问题时，它会拒绝回答，并将问题重定向到另一个自定义 agent，因为它理解该问题已经超出了自身边界，并建议转而询问另一个自定义构建的 agent —— CostGuard。这是 scoped agents 的设计特性。