从告警到根因仅需3分钟：基于 Elastic Agent Builder 的自动化根因分析

一个针对结账延迟的告警被触发。3分22秒后，一个 Elastic Observability 工单已创建，其中包含根因、支撑证据以及智能体的置信度。整个过程无需任何人在 Kibana、聊天、工单和终端之间来回切换。

在本文中，我们将端到端地构建这个闭环。我们将使用 Elastic Agent Builder 将日志、链路、指标、告警和 runbook 上下文输入到一个智能体中，由其调查问题；并使用 Elastic Workflows 来执行已知的后续步骤：创建工单、发送通知、运行丰富查询，或触发修复路径。

我们以结账延迟回归作为示例，但同样的模式适用于任何团队已经知道手动步骤的故障类别。

先决条件

• 运行 9.4+ 版本的 Elastic Cloud 或 自管理 集群

我们将以结账延迟回归作为贯穿示例。如果你想针对自己的遥测数据跟进，请将查询指向你自己的服务。如果你希望复现该确切故障，配套的 notebook 会模拟该故障，并为你设置好角色、技能、工具和工作流。

为什么仪表板不足以应对故障响应

仪表板显示症状，但无法选择下一个查询。仪表板仍然是共享态势感知的最佳工具之一，但在故障发生时，当图表变红之后，真正的工作才刚刚开始，工程师仍然需要回答一系列操作性问题。

• 发生了什么变化？ 你需要访问同一时间窗口内的相关部署、告警、日志、链路和指标。
• 哪些受影响？ 你需要了解服务、主机、用户、区域、SLO 和依赖路径。
• 可能的原因是什么？ 你需要结合 runbook 或历史故障工单，从遥测数据中获取证据。
• 接下来可以安全地做什么？ 你需要一个有边界的行为，包含适当的权限、审计追踪和回滚路径。

显示当前状态但无下一步操作的 Kibana 仪表板，包含 KPI、趋势和细分面板

最后一个问题正是仪表板的局限所在。它可以显示症状，但无法决定下一步该运行哪个查询、哪个 runbook 适用，或哪个工作流应当执行。当今，工程师通过在 Kibana、聊天、工单、终端和内部文档之间切换来提供这种判断。

一个 SRE 控制平面将判断权保留在工程师手中，同时将更多上下文和更多操作汇集到同一个操作界面上。

自动化根因分析如何工作：状态、策略与行动

自动化根因分析需要将三件事整合在一起：遥测数据、限定其范围的权限，以及它可以触发的行动。

• 状态： 对于 SRE 工作而言，状态就是 Elasticsearch 中的遥测数据：日志、链路、指标、告警、SLO 以及相关的操作记录。
• 策略： 策略定义了谁可以查询哪些数据、智能体可以调用哪些工具、哪些工作流可以运行，以及哪些环节需要人工决策。
• 行动： 行动是一组已知的工具和工作流，它们以明确的输入、权限和输出运行。

Elastic 作为 SRE 控制平面：通过 Agent Builder 和工具进行调查，在护栏内决策，通过工作流执行行动

在系统需要对混乱的上下文进行推理时，Agent Builder 非常有用；而在需要确定性执行时，Workflows 则非常有用。

两者可以双向工作：工作流可以通过 ai.agent 步骤调用智能体（当它需要在下一步之前进行分析时），而智能体也可以通过工作流工具调用工作流（当对话需要可重复的行动时）。

Elastic Agent Builder 为 AI 故障响应增添了什么

Agent Builder 技能 是可复用的能力包。一个技能可以包含指令、工具和上下文，指导智能体完成特定任务。

可复用的技能包对于 SRE 工作至关重要，因为故障响应很少是单个查询就能完成的。一个好的调查有其结构，而根因分析就是一个很好的例子。有用的单元不是“问模型发生了什么”，而是一条可复用的调查路径：从告警开始，限定时间窗口，检查正确的遥测数据，记录不确定性，并将结构化结果交给工单或工作流。智能体需要决定从哪个信号入手，查询正确的索引，比较正确的时间窗口，检查相关服务，并解释证据，同时不隐藏其未知信息。

Elastic 为此模式内置了一个 Elastic AI Agent。内置技能按解决方案限定范围，因此承载 SRE 故障循环的技能是 observability.investigation，以及任何解决方案都可以使用的平台技能（如 dashboard-management）。列表显示的是短名称，因此在 UI 中查找 investigation。

该技能以 Markdown 指令形式提供，与我们在下一节中自定义技能时使用的格式相同。

Agent Builder 中的 observability.investigation 技能，显示其描述和 Markdown 指令

还有一些开箱即用的工具，例如 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。

Agent Builder 工具页面，列出内置的 platform.core 工具，搜索工具描述已展开

技能指导工作，工具执行有边界的操作，智能体根据任务选择使用什么。

场景：结账延迟回归

告警触发 Agent Builder 对日志、链路和指标进行调查，最终得出根因并创建工单

部署 2026.07.09.1 将连接池配置错误引入 checkout-api。几分钟内，p95 延迟从 180ms 飙升到超过 2s，HTTP 500 首次出现。此时尚无人知道连接池是原因。

证据分散在三个信号中，没有一个能单独回答整个问题：

将这三个信号关联起来，正是我们希望智能体完成的工作。这为我们余下的文章提供了契约：

此后的一切都围绕该契约的各个部分展开：技能塑造调查，工具和角色限定访问范围，工作流将输出转化为工单。

在 Elastic Agent Builder 中构建只读调查技能

我们从一个只读技能开始，它能提高调查质量而不触及生产环境：

# 结账延迟调查
当工程师询问结账延迟、错误或失败事务增加的原因时，使用此技能。
按以下顺序进行调查：
1. 确定受影响的服务、环境和时间范围。
2. 查询该时间窗口内最慢事务的链路。
3. 查询同一服务和依赖路径的日志中的错误。
4. 将当前错误率和延迟率与上一个健康窗口进行比较。
5. 返回可能的原因、支撑证据、置信度以及下一步安全操作。
除非为该操作分配了工作流工具，否则不要推荐生产变更。
如果证据不完整，指出缺少哪些数据。

这类技能本质上是一份 runbook 执行指南，能让智能体在不同故障中保持一致。它还能帮助经验较少的工程师提出更好的后续问题，因为智能体可以展示下一个查询并解释其重要性。

缺少第 4 步时，智能体只会描述当前状况并止步于此。与上一个健康窗口进行比较，才是使其成为分析的关键。而最后一条则允许智能体在数据缺失时直接说明，而不是猜测。

添加具有窄权限的 AI 智能体可观测性工具

每个工具应当暴露智能体所需的最小操作，并配备仍能支持任务的最小数据访问权限。

对于只读调查智能体，所需权限通常从搜索可观测性数据和检查索引结构开始。Agent Builder 权限文档指出，工具以当前用户身份对 Elasticsearch 数据执行操作，面向读取的工具需要 read 和 view_index_metadata 等索引权限。

在开发工具中运行以下命令，创建一个限定调查范围的角色：

POST /_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"
      ]
    }
  ]
}

该角色为智能体提供了足够的权限来检测遥测数据，同时将生产更改操作排除在外。monitor_inference 集群权限是让智能体使用 Agent Builder 背后的推理端点所必需的，它本身不授予任何数据访问权限。

当添加自定义工具时，请用操作语言描述它，因为工具描述是智能体决定何时调用它的一部分。优先选择这样的描述：

使用此工具在限定时间范围内搜索结账服务的日志中的错误。
必需输入：
- service_name
- environment
- start_time
- end_time
返回：
- 匹配的日志样本
- 按消息统计的错误计数
- 受影响的主机和 Pod 名称（如果存在）

一个窄工具描述比一个笼统地说“搜索所有相关日志”的宽泛工具要安全得多。智能体获得清晰的契约，审查者也能推理出工具能做什么、不能做什么。

使用 Elastic Workflows 进行故障响应自动化

一旦调查路径变得有用，我们就可以为那些应该可重复的操作添加 Workflows。有了 Workflows，控制平面就变得可操作了，因为它可以查询更多上下文、让智能体总结证据、创建工单、通知频道或调用修复端点。关键在于，每一步都是明确的。

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。这三个字段构成了整个契约：

工作流步骤：rca_analysis 通过共享对话将信息传递给 case_title 和 case_description，然后创建工单并将分析结果添加为评论

该工作流不会重启任何东西。它让 Agent Builder 进行调查，复用同一对话生成工单标题和描述，创建 Observability 工单，并将智能体分析结果作为工单评论写入。

有两个细节值得注意。第一个步骤上的 create-conversation: true 标志使得后续两个步骤成本很低：case_title 和 case_description 传递相同的 conversation_id，因此智能体已经掌握了调查上下文，无需重复查询。我们使用手动触发器并设置了默认的 alert_summary，以便在将其附加到实时告警规则之前可以运行该序列。在生产环境中，你会将触发器切换为 alert，并将工作流附加到拥有该故障类别的规则上。

点击播放按钮运行工作流。我们的运行耗时 3 分 22 秒，rca_analysis、case_title、case_description、create_case 和 add_agent_analysis 全部标记为成功。几乎全部时间都花在了调查本身：rca_analysis 单独就花了 3 分 5 秒，而两次工单写入各约 1 秒完成。

工作流执行视图，显示五个步骤在 3 分 22 秒内全部成功

然后工作流写入了一个 Observability 工单。工单列表显示一个已打开的工单，标题由智能体生成，带有我们的标签、中等严重级别和一条评论。

Observability 工单列表，显示一个由工作流创建的已打开工单

工单详情是调查的审计产物。它记录了所考虑的证据、受影响的主机和部署版本、可能的错误类型、智能体的置信度以及任何缺失的信号。

工单详情，显示生成的描述和 Agent Builder RCA 评论

一个有用的操作控制平面会揭示其证据的局限性，而不是将不确定性转化为自信的断言。如果你的智能体从未报告过缺失数据或较低置信度，那就是一个信号，表明需要收紧技能指令，而不是每次调查都顺利。

只读自动化根因分析模式可以在不改变受影响服务的情况下提高响应质量。只有在操作被充分理解、范围狭窄、并配有验证和回滚时，才添加修复步骤：清除一个缓存键、重启一个工作进程、将流量从一个不健康实例移走，或运行一个预先批准的维护任务。

将 Elastic Workflows 转化为智能体工具

工作流工具 允许 Agent Builder 对话触发一个 Elastic Workflow 并使用其输出。这是从“智能体推荐了下一步”到“智能体可以提供已知操作”的桥梁。

一个工作流工具应该有狭窄的描述：

仅当结账错误由单个工作进程上的连接池耗尽引起时，才使用此工具。
该工作流会排空并回收一个工作进程的连接池，然后验证该工作进程能否恢复成功请求。
必需输入：
- host_name
不要将此工具用于数据库中断、影响所有主机的部署回归或多主机故障。

描述之所以重要，是因为它设定了智能体的选择边界。注意最后一行排除了我们刚刚调查的场景：我们的故障影响了两台主机，并且由部署引起，因此智能体不应提供此工具。这正是关键所在。一个匹配每个故障的工作流工具，就是一个没有边界的工作流工具。

工作流仍然拥有执行权。智能体不需要知道如何回收连接池。它只需要能识别何时某个已知工作流可能适用，收集所需的输入，并将该操作呈现给工程师。

如何阻止 AI 智能体更改生产环境？

一个 SRE 控制平面应该围绕爆炸半径控制来构建，这意味着每个操作路径都需要一个清晰的边界。在将工作流暴露为智能体工具之前，请使用以下检查：

对于审查边界本身，Workflows 提供了 wait 步骤、超时和执行历史，因此一个高风险路径可以暂停等待批准，同时仍留下审计追踪。

智能体可以帮助收集证据并提出下一步行动，但生产操作应始终保持在已知的工作流路径内。

首先针对一个故障类别进行验证

对于实际部署，请针对一个重复出现的故障类别验证控制平面。跟踪智能体是否找到正确的证据、工作流输出是否足够完整以供审查，以及工程师是否信任推荐的下一步。

使用一个简单的验证计划：

1. 选择一个具有已知 runbook 的告警类型。
2. 为该告警构建一个只读调查技能。
3. 添加一到两个具有限定索引权限的查询工具。
4. 针对历史故障运行智能体，并将其摘要与实际工单笔记进行比较。
5. 添加一个工单创建工作流，并与负责的 SRE 团队一起审查输出。
6. 只有在之后才考虑执行一个有边界修复步骤的工作流工具。

主要的失败模式不是模型给出了不完美的摘要，而是在调查路径得到验证之前就授予了宽泛的操作权限。保持第一个版本简单、有范围、可审查。

结论

我们涵盖了以下内容：

• 一个 SRE 控制平面将状态（Elasticsearch 中的遥测数据）、策略（权限和审查边界）和行动（已知的工具和工作流）结合在一起。
• Agent Builder 处理对混乱上下文的推理，而 Workflows 处理确定性执行，两者可以互相调用。
• 一个只读调查技能将 runbook 转化为可重复的调查路径，并记录不确定性而非隐藏它。
• 在 logs-*、metrics-* 和 traces-* 上具有 read 和 view_index_metadata 权限的限定角色，使智能体保持有用，同时不允许其更改生产环境。
• 在 ai.agent 步骤间复用 conversation_id 可以让后续步骤建立在调查基础上，而不是重复执行。
• 一个仅创建工单的工作流可以在启用任何修复之前提供完整的审计产物。
• 工具描述是一个安全边界，而非文档，因为它决定了智能体何时提供操作。

资源

• Agent Builder for Observability
• Agent Builder 技能
• Agent Builder 工具
• 工作流工具
• AI 增强工作流
• 可观测性告警的根因分析工作流