从告警到根因仅需 3 分钟：使用 Elastic Agent Builder 实现自动化根因分析-北京尧图网络

作者来自 Elastic Jeffrey Rengifo自动化根因分析只有在 agent 将故障时间窗口与上一次健康时间窗口进行对比时才有效。跳过这一步你得到的就只是一个摘要器。只读 skill、受限 role 以及 Elastic Workflow 都已包含在这里。告警触发在 checkout latency 上。3 分钟 22 秒后一个 Elastic Observability case 已经打开其中包含根因、背后的证据以及 agent 对其结论的置信度。整个过程中没有人需要在 Kibana、聊天工具、工单系统和终端之间来回切换。在本文中我们将端到端构建这一闭环。我们将使用 Elastic Agent Builder将日志、traces、metrics、告警和 runbook 上下文提供给一个 agent由它来调查问题然后使用 Elastic Workflows 执行已知的后续步骤打开 case、发送通知、运行 enrichment 查询或触发 remediation 路径。我们将以 checkout latency 回退作为示例但同样的模式也适用于任何你的团队已经明确了解手动处理步骤的故障事件类型。前提条件Elastic Cloud 或 self-managed 集群运行 9.4 版本我们将使用 checkout latency 回退作为贯穿全文的示例。如果你希望针对自己的 telemetry 按照本文进行操作可以将查询指向你自己的 service。如果你希望复现完全相同的故障事件可以使用配套 notebook它会模拟该故障事件并为你设置 role、skill、tool 和 workflow。为什么 dashboard 不足以应对故障事件Dashboard 可以展示症状但无法选择下一条查询。Dashboard 仍然是共享态势感知的最佳工具之一但在故障事件期间当图表变红之后真正困难的工作才开始工程师仍然需要依次回答一系列运维问题。发生了什么变化你需要访问同一时间窗口内相关的 deploys、告警、日志、traces 和 metrics。受到了什么影响你需要了解 services、hosts、users、regions、SLOs 和 dependency paths。最可能的原因是什么你需要结合 telemetry 与 runbooks 或之前的故障事件 case 来获取证据。下一步安全的操作是什么你需要一个有边界的操作同时包含适当的权限、审计记录以及 rollback 路径。最后一个问题就是 dashboard 的能力边界。它可以展示症状但无法决定下一条应该运行哪个查询、哪个 runbook 适用或者应该运行哪个 workflow。如今工程师需要在 Kibana、聊天工具、工单系统、终端和内部文档之间来回切换才能做出这些判断。SRE control plane 可以让工程师继续掌握判断权同时将更多上下文和更多操作集中到同一个运维界面中。自动化根因分析如何工作状态、策略和操作自动化根因分析需要将三样东西集中在一个地方telemetry、用于约束 telemetry 的权限以及它能够触发的操作。状态State对于 SRE 工作而言这些状态就是 Elasticsearch 中的 telemetry日志、traces、metrics、告警、SLOs 以及相关的运维记录。策略Policy策略定义谁可以查询哪些数据、agent 可以调用哪些 tools、哪些 workflows 可以运行以及哪些地方需要人工决策。操作Action操作是一组已知的 tools 和 workflows它们在明确的输入、权限和输出约束下运行。Agent Builder 适用于系统需要对复杂、杂乱的上下文进行推理的场景而 Workflows 适用于系统需要执行确定性操作的场景。两者可以双向协作当 workflow 需要在执行下一步之前进行分析时可以通过ai.agent步骤调用 agent当对话需要执行可重复的操作时agent 也可以通过 workflow tool 调用 workflow。Elastic Agent Builder 为 AI 故障事件响应带来了什么Agent Builder skills 是可复用的能力包。一个 skill 可以包含 instructions、tools 和 context用于引导 agent 完成特定任务。对于 SRE 工作而言可复用的 skill 包非常重要因为故障事件响应很少只是运行一条查询。一次好的调查有其固定的结构而根因分析就是一个很好的例子。真正有价值的单元并不是 “询问模型发生了什么”而是一条可重复的调查路径从告警开始确定时间窗口检查正确的 telemetry记录不确定性并将结构化结果交给 case 或 workflow。Agent 需要决定从哪个信号开始查询正确的 index对比正确的时间窗口检查相关 services并解释背后的证据同时明确说明自己不知道什么而不是将未知信息隐藏起来。Elastic 针对这一模式提供了内置的 Elastic AI Agent。内置 skills 按 solution 进行划分因此负责 SRE 故障事件处理闭环的是observability.investigation同时还有dashboard-management等平台 skill任何 solution 都可以使用。列表中显示的是简短名称因此在 UI 中查找investigation即可。该 skill 以 Markdown instructions 的形式提供这与我们将在下一节中创建自己的 skill 时使用的格式相同。此外还有开箱即用的 tools例如platform.core.search、platform.core.get_document_by_id、platform.core.get_index_mapping、platform.core.list_indices、platform.core.get_workflow_execution_status和platform.core.resume_workflow_execution。Skills 指导工作tools 执行受约束的操作而 agent 会根据任务决定使用哪些 tools。场景checkout latency 回退部署2026.07.09.1将一个连接池配置错误发布到了checkout-api。几分钟内p95 latency 从 180ms 上升到超过 2s并且首次出现 HTTP 500 错误。此时还没有人知道连接池是根因。证据分散在三个信号中单独任何一个信号都无法回答这个问题信号它展示的内容LogsPoolExhaustedException和 HTTP 500 错误而且只出现在新版本中Tracespayment-gatewayspan 的耗时从约 180ms 上升到约 2500msMetrics部署完成后连接池立即达到 20 / 20持续处于满负载状态将这三个信号关联起来就是我们希望 agent 完成的工作。这也为本文其余部分定义了契约契约详情输入Service 名称和告警摘要访问权限仅对logs-*、traces-*和metrics-*执行只读搜索输出可能的根因、支持性证据、置信度以及下一步安全操作副作用创建一个 Observability case并附加分析结果从这里开始我们将逐一构建这个契约中的各个部分skill 负责定义调查流程tool 和 role 负责限制访问权限而 workflow 则负责将输出转换为 case。在 Elastic Agent Builder 中构建只读调查 skill我们先从一个只读 skill 开始在不接触生产环境的情况下提高调查质量# Checkout latency investigation Use this skill when an engineer asks why checkout latency, errors, or failed transactions increased. Work through the investigation in this order: 1. Identify the affected service, environment, and time range. 2. Query traces for the slowest transactions in that window. 3. Query logs for errors from the same service and dependency path. 4. Compare current error and latency rates with the previous healthy window. 5. Return the likely cause, supporting evidence, confidence level, and the next safe action. Do not recommend a production change unless there is a workflow tool assigned for that action. If the evidence is incomplete, say what data is missing.这类 skill 属于 runbook 执行指南可以让 agent 在不同故障事件之间保持一致。它还可以帮助经验较少的工程师提出更好的后续问题因为 agent 能够展示下一条查询并解释为什么这条查询很重要。如果没有第 4 步agent 只能描述当前正在发生什么然后就停止了。与之前健康时间窗口进行对比才真正让它具备分析能力。而最后一行则允许 agent 在数据缺失时明确说明数据缺失而不是进行猜测。使用受限权限添加 AI agent observability tools每个 tool 都应该只暴露 agent 所需的最小操作并提供仍然能够支持任务的最小数据访问权限。对于只读调查 agent所需权限通常从搜索 observability 数据和检查 index 结构开始。Agent Builder permissions 文档指出tools 会以当前用户的身份访问 Elasticsearch 数据而面向读取的 tools 需要read和view_index_metadata等 index 权限。在 Dev Tools 中运行以下内容创建一个限定用于调查的 rolePOST /_security/role/agent-builder-observability-investigator { cluster: [monitor_inference], indices: [ { names: [logs-*, metrics-*, traces-*], privileges: [read, view_index_metadata] } ], applications: [ { application: kibana-.kibana, privileges: [feature_agentBuilder.read, feature_actions.read], resources: [space:default] } ] }这个 role 为 agent 提供了足够的权限来检查 telemetry同时将可能修改生产环境的操作排除在权限范围之外。monitor_inferencecluster privilege 允许 agent 使用 Agent Builder 背后的 inference endpoints但它本身不会授予任何数据访问权限。添加 custom tool 时应使用运维语言对其进行描述因为 tool description 也是 agent 判断何时调用该 tool 的依据之一。建议使用类似下面这样的描述Use this tool to search checkout service logs for errors in a bounded time range. Required inputs: - service_name - environment - start_time - end_time Return: - matching log samples - error counts by message - affected host and pod names when present相比一个写着“搜索所有日志查找任何相关信息”的宽泛 tool范围受限的 tool description 要安全得多。Agent 会获得一个清晰的契约而 reviewer 也能够明确判断这个 tool 能做什么、不能做什么。使用 Elastic Workflows 实现故障事件响应自动化调查流程稳定可用后我们就可以为那些应该重复执行的操作添加 Workflows。借助 Workflowscontrol plane 就具备了实际的运维能力因为它可以查询更多上下文、让 agent 总结证据、打开 case、通知 channel或者调用 remediation endpoint。关键在于每一个步骤都是明确的。Workflows 编辑器会在你保存或运行任何内容之前提供验证流程。利用它可以提前发现语法问题避免 workflow 向 Cases 写入内容或调用任何操作之前才发现错误。进入Workflows Create workflow然后粘贴以下内容name: obs-labs-checkout-control-plane description: Checkout regression investigation with Agent Builder and case creation. tags: [sre-control-plane, agent-builder, workflows] triggers: - type: manual inputs: - name: service_name type: string default: checkout-api - name: alert_summary type: string default: Checkout API p95 latency increased above 2s and HTTP 500s rose in the last 15 minutes after deployment 2026.07.09.1. steps: - name: rca_analysis type: ai.agent agent-id: elastic-ai-agent create-conversation: true with: message: | Investigate this checkout incident as an SRE would. Service: {{ inputs.service_name }} Alert: {{ inputs.alert_summary }} Search the available logs, traces, and metrics for this service. Compare the window before and after the most recent deployment. Return a concise likely cause, supporting evidence, confidence, and next safe action. If the evidence is incomplete, say what data is missing. - name: case_title type: ai.agent agent-id: elastic-ai-agent with: conversation_id: {{ steps.rca_analysis.output.conversation_id }} message: Produce a short case title for this incident. Output only the title. - name: case_description type: ai.agent agent-id: elastic-ai-agent with: conversation_id: {{ steps.rca_analysis.output.conversation_id }} message: Produce a concise case description. Output only the description. - name: create_case type: cases.createCase with: title: {{ steps.case_title.output.message }} description: {{ steps.case_description.output.message }} owner: observability severity: medium tags: [sre-control-plane, agent-builder, workflows] - name: add_agent_analysis type: cases.addComment with: case_id: {{ steps.create_case.output.case.id }} comment: | ## Agent Builder RCA {{ steps.rca_analysis.output.message }} Agent conversation: {{ kibanaUrl }}/app/agent_builder/conversations/{{ steps.rca_analysis.output.conversation_id }}每个步骤都会通过其输出为下一步提供输入。ai.agent步骤会输出包含模型文本的message和conversation_id而cases.createCase会输出新的case.id。这三个字段就是完整的契约这个 workflow 不会重启任何服务。它会请求 Agent Builder 进行调查复用同一个 conversation 来生成 case 标题和描述创建一个 Observability case然后将 agent 的分析结果写回 case comment。这里有两个细节值得说明。第一步中的create-conversation: true标志让接下来的两个步骤变得更加高效case_title和case_description传递相同的conversation_id因此 agent 已经拥有调查过程中的上下文不需要重复执行查询。第二我们使用 manual trigger并为alert_summary设置默认值这样你可以在将 workflow 连接到实时告警规则之前先运行整个流程。在生产环境中你应该将 trigger 切换为alert并将 workflow 关联到负责该故障事件类型的规则。点击播放按钮运行 workflow。我们的运行耗时 3 分钟 22 秒rca_analysis、case_title、case_description、create_case和add_agent_analysis全部标记为成功。几乎所有时间都花在调查本身上仅rca_analysis就耗时 3 分钟 5 秒而两个 case 写入步骤各自在大约 1 秒内完成。然后workflow 写入了一个 Observability case。Case 列表显示有一个处于 open 状态的 case其中包含生成的 checkout 标题、我们设置的 tags、中等严重性以及一条 comment。Case 详情就是这次调查的审计记录。它记录了所考虑的证据、受影响的 hosts 和部署版本、可能的错误类型、agent 的置信度以及任何缺失的信号。一个有用的运维 control plane 应该展示其证据的局限性而不是将不确定性包装成确定的结论。如果你的 agent 从不报告数据缺失或较低的置信度这应该被视为需要收紧 skill instructions 的信号而不是所有调查都进展顺利的证明。只读的自动化根因分析模式可以在不修改受影响 service 的情况下提高响应质量。只有当 remediation 操作已经得到充分理解、范围足够有限并且配套了验证和 rollback 时才应该加入 remediation例如清除一个 cache key、重启一个 worker、将流量从一个不健康的 instance 转移出去或者运行一个预先批准的维护任务。将 Elastic Workflows 转换为 agent toolsWorkflow tools 允许 Agent Builder 对话触发 Elastic Workflow并使用其输出。这是从 “agent 推荐下一步操作” 到 “agent 可以提供一个已知操作” 的桥梁。一个 workflow tool 应该有一个范围明确的描述Use this tool only when checkout errors are caused by connection pool exhaustion on a single worker. The workflow drains and recycles the connection pool for one worker, then verifies that the worker resumes successful requests. Required input: - host_name Do not use this tool for database outages, deploy regressions affecting all hosts, or multi-host failures.描述很重要因为它定义了 agent 的选择边界。注意最后一行如何排除我们刚才调查的场景我们的故障事件同时影响两个 hosts并且由一次部署导致因此 agent 不应该提供这个 tool。这正是关键所在。一个能够匹配所有故障事件的 workflow tool就是一个没有边界的 workflow tool。Workflow 仍然负责执行。Agent 不需要知道如何重新初始化连接池。它只需要识别何时可能适用某个已知 workflow收集所需的输入并向工程师提供该操作。如何阻止 AI agent 修改生产环境SRE control plane 应围绕影响范围控制来构建这意味着每条操作路径都需要清晰的边界。在将 workflow 暴露为 agent tool 之前使用以下检查检查项重要性首先采用只读模式在添加生产操作之前验证调查流程范围明确的输入 schema防止模糊的 prompt 演变成模糊的操作明确的权限将 agent 限制在当前用户允许访问的数据和操作范围内Dry-run 或仅创建 case 模式允许团队在启用 remediation 之前审查输出对高风险步骤进行人工审核在影响较大的场景中确保人工参与决策操作后验证确认 workflow 确实改善了 service而不仅仅是执行了某条命令对于审核边界本身Workflows 提供了wait步骤、超时和执行历史因此高风险路径可以暂停等待批准同时保留审计记录。Agent 可以帮助收集证据并提出下一步操作但生产环境中的实际操作应该始终保留在已知的 workflow 路径中。首先针对一种故障事件类型进行验证在实际部署时应针对一种经常发生的故障事件类型验证 control plane。跟踪 agent 是否找到了正确的证据、workflow 输出是否足够完整以供审核以及工程师是否信任其推荐的下一步操作。可以使用一个简单的验证计划选择一种具有明确 runbook 的告警类型。为该告警构建一个只读 investigation skill。添加一两个具有受限 index 权限的查询 tools。使用历史故障事件运行 agent并将其摘要与实际 case notes 进行比较。添加 case-creation workflow并与负责该服务的 SRE 团队一起审核输出。只有完成这些步骤后才考虑添加一个能够执行受限 remediation 操作的 workflow tool。最大的失败模式并不是模型给出了不够完美的摘要而是在调查流程尚未得到验证之前就授予了广泛的操作权限。让第一个版本保持简单、范围明确且可审核。结论本文介绍了以下内容SRE control plane 将状态Elasticsearch 中的 telemetry、策略权限和审核边界以及操作已知的 tools 和 workflows结合在一起。Agent Builder 负责对复杂的上下文进行推理而 Workflows 负责确定性执行两者可以相互调用。只读 investigation skill 将 runbook 转换为可重复的调查路径并记录不确定性而不是隐藏不确定性。在logs-*、metrics-*和traces-*上使用带有read和view_index_metadata的受限 role可以让 agent 发挥作用同时阻止其修改生产环境。在ai.agent步骤之间复用conversation_id可以让后续步骤基于已有调查继续工作而不必重复执行查询。仅创建 case 的 workflow 可以在启用任何 remediation 之前提供完整的审计记录。Tool description 不只是文档也是安全边界因为它决定了 agent 何时会提供某个操作。资源Agent Builder for ObservabilityAgent Builder skillsAgent Builder toolsWorkflow toolsAI-augmented workflowsRoot cause analysis workflow for observability alerts原文Automated root cause analysis with Elastic Agent Builder | Elastic Observability Labs

从告警到根因仅需 3 分钟：使用 Elastic Agent Builder 实现自动化根因分析

相关推荐

1.6万元预算游戏主机：9800X3D + 5060 Ti 16G配置与装机全攻略

驯服 PUNKs：ES|QL 如何查询 Elasticsearch 从未被告知的字段

AI使用与职业疏忽：从注意义务到可辩护的决策流程

更多资讯

唐山考低压电工证报名通过率揭秘：外省证书能不能转过来？

高压电工证培训标识牌考试真题与备考技巧

沈阳特种电工作业证官方回应学历不高也能报考

建设厅电工证查询6怎么查？全国通用证书怎么考？电工证是刚需！

电工证什么岗位好考值不值得考的真相来了

盲人可以报考电工证吗千万别踩坑的真相来了

今日更新

特种工指挥考试题库怎么刷才不会白交培训费？官方报名入口在这！

电工证考试多少分合格在哪考别再交冤枉钱了

福清应急管理局电工证真实经历：工地太忙根本没时间复习考试怎么办

本周精选

安监局电工证分数查询怎么查才能知道含金量高不高

新疆电工作业干活累吗良心建议助你避开考不过的坑

中牟县电工证怎么报名外省证能转吗

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？