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

作者来自 Elastic Aleksandar PanovElastic 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 Covendor_id1在过去 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 的设计特性。闭环从诊断到执行的 Elastic Workflows我们在这里展示的内容说明了可观测性正在走向的方向从盯着仪表盘转向直接提问。仪表盘仍然有价值但调查将从 agent 开始。过去只有少数人掌握的业务知识现在可以写入 agent 的指令中因此当新员工提出开放性问题时agent 能准确知道应该运行哪些查询来回答问题甚至可能挖掘出新的洞察。在理解了 agents 如何诊断事件之后下一个问题是它们能否创建工单或通知团队它们可以给出建议但不会执行操作。从对话式 AI 到自动化响应之间的空白由 Elastic Workflows 来填补。Workflow 是一种基于规则触发的自动化机制可以调用外部 API如 Jira、Slack、Teams 等或执行后续的 Elasticsearch 查询。例如它可以创建一个包含详细信息的 Jira 工单或向特定 Slack 频道如 #ops-alerts发送一条包含摘要的消息。当告警触发时Workflow 会启动并调用 Agent Builder 的 agent。该 agent 执行 ES|QL 查询关联相关指标并返回诊断结果。随后 Workflow 执行后续动作创建 Jira 工单、发送 Slack 消息或两者同时执行整个过程无需任何人工介入。原文Elastic Agent Builder agents overview | Elastic Docs