从告警到根因仅需 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 错误。此时还没有人知道连接池是根因。

证据分散在三个信号中，单独任何一个信号都无法回答这个问题：

信号	它展示的内容
Logs	PoolExhaustedException 和 HTTP 500 错误，而且只出现在新版本中
Traces	payment-gateway span 的耗时从约 180ms 上升到约 2500ms
Metrics	部署完成后，连接池立即达到 20 / 20，持续处于满负载状态

将这三个信号关联起来，就是我们希望 agent 完成的工作。这也为本文其余部分定义了契约：

契约	详情
输入	Service 名称和告警摘要
访问权限	仅对 logs-*、traces-* 和 metrics-* 执行只读搜索
输出	可能的根因、支持性证据、置信度以及下一步安全操作
副作用	创建一个 Observability case，并附加分析结果

从这里开始，我们将逐一构建这个契约中的各个部分：skill 负责定义调查流程，tool 和 role 负责限制访问权限，而 workflow 则负责将输出转换为 case。

在 Elastic Agent Builder 中构建只读调查 skill

我们先从一个只读 skill 开始，在不接触生产环境的情况下提高调查质量：

`

1.  # Checkout latency investigation

3.  Use this skill when an engineer asks why checkout latency, errors, or failed transactions increased.

5.  Work through the investigation in this order:

7.  1. Identify the affected service, environment, and time range.
8.  2. Query traces for the slowest transactions in that window.
9.  3. Query logs for errors from the same service and dependency path.
10.  4. Compare current error and latency rates with the previous healthy window.
11.  5. Return the likely cause, supporting evidence, confidence level, and the next safe action.

13.  Do not recommend a production change unless there is a workflow tool assigned for that action.

15.  If the evidence is incomplete, say what data is missing.

`AI写代码![](https://csdnimg.cn/release/blogv2/dist/pc/img/runCode/icon-arrowwhite.png)

这类 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 中运行以下内容，创建一个限定用于调查的 role：

`

1.  POST /_security/role/agent-builder-observability-investigator
2.  {
3.    "cluster": ["monitor_inference"],
4.    "indices": [
5.      {
6.        "names": ["logs-*", "metrics-*", "traces-*"],
7.        "privileges": ["read", "view_index_metadata"]
8.      }
9.    ],
10.    "applications": [
11.      {
12.        "application": "kibana-.kibana",
13.        "privileges": ["feature_agentBuilder.read", "feature_actions.read"],
14.        "resources": ["space:default"]
15.      }
16.    ]
17.  }

`AI写代码![](https://csdnimg.cn/release/blogv2/dist/pc/img/runCode/icon-arrowwhite.png)

这个 role 为 agent 提供了足够的权限来检查 telemetry，同时将可能修改生产环境的操作排除在权限范围之外。monitor_inference cluster privilege 允许 agent 使用 Agent Builder 背后的 inference endpoints，但它本身不会授予任何数据访问权限。

添加 custom tool 时，应使用运维语言对其进行描述，因为 tool description 也是 agent 判断何时调用该 tool 的依据之一。建议使用类似下面这样的描述：

`

1.  Use this tool to search checkout service logs for errors in a bounded time range.

3.  Required inputs:
4.  - service_name
5.  - environment
6.  - start_time
7.  - end_time

9.  Return:
10.  - matching log samples
11.  - error counts by message
12.  - affected host and pod names when present

`AI写代码![](https://csdnimg.cn/release/blogv2/dist/pc/img/runCode/icon-arrowwhite.png)

相比一个写着"搜索所有日志，查找任何相关信息"的宽泛 tool，范围受限的 tool description 要安全得多。Agent 会获得一个清晰的契约，而 reviewer 也能够明确判断这个 tool 能做什么、不能做什么。

使用 Elastic Workflows 实现故障事件响应自动化

调查流程稳定可用后，我们就可以为那些应该重复执行的操作添加 Workflows。借助 Workflows，control plane 就具备了实际的运维能力，因为它可以查询更多上下文、让 agent 总结证据、打开 case、通知 channel，或者调用 remediation endpoint。关键在于，每一个步骤都是明确的。

Workflows 编辑器会在你保存或运行任何内容之前提供验证流程。利用它可以提前发现语法问题，避免 workflow 向 Cases 写入内容或调用任何操作之前才发现错误。

进入 Workflows > Create workflow，然后粘贴以下内容：

`

1.  name: obs-labs-checkout-control-plane
2.  description: Checkout regression investigation with Agent Builder and case creation.
3.  tags: ["sre-control-plane", "agent-builder", "workflows"]

5.  triggers:
6.    - type: manual

8.  inputs:
9.    - name: service_name
10.      type: string
11.      default: "checkout-api"
12.    - name: alert_summary
13.      type: string
14.      default: "Checkout API p95 latency increased above 2s and HTTP 500s rose in the last 15 minutes after deployment 2026.07.09.1."

16.  steps:
17.    - name: rca_analysis
18.      type: ai.agent
19.      agent-id: elastic-ai-agent
20.      create-conversation: true
21.      with:
22.        message: |
23.          Investigate this checkout incident as an SRE would.

25.          Service: {{ inputs.service_name }}
26.          Alert: {{ inputs.alert_summary }}

28.          Search the available logs, traces, and metrics for this service.
29.          Compare the window before and after the most recent deployment.

31.          Return a concise likely cause, supporting evidence, confidence, and next safe action.
32.          If the evidence is incomplete, say what data is missing.

34.    - name: case_title
35.      type: ai.agent
36.      agent-id: elastic-ai-agent
37.      with:
38.        conversation_id: "{{ steps.rca_analysis.output.conversation_id }}"
39.        message: "Produce a short case title for this incident. Output only the title."

41.    - name: case_description
42.      type: ai.agent
43.      agent-id: elastic-ai-agent
44.      with:
45.        conversation_id: "{{ steps.rca_analysis.output.conversation_id }}"
46.        message: "Produce a concise case description. Output only the description."

48.    - name: create_case
49.      type: cases.createCase
50.      with:
51.        title: "{{ steps.case_title.output.message }}"
52.        description: "{{ steps.case_description.output.message }}"
53.        owner: "observability"
54.        severity: "medium"
55.        tags: ["sre-control-plane", "agent-builder", "workflows"]

57.    - name: add_agent_analysis
58.      type: cases.addComment
59.      with:
60.        case_id: "{{ steps.create_case.output.case.id }}"
61.        comment: |
62.          ## Agent Builder RCA

64.          {{ steps.rca_analysis.output.message }}

66.          Agent conversation: {{ kibanaUrl }}/app/agent_builder/conversations/{{ steps.rca_analysis.output.conversation_id }}

`AI写代码![](https://csdnimg.cn/release/blogv2/dist/pc/img/runCode/icon-arrowwhite.png)

每个步骤都会通过其输出为下一步提供输入。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 tools

Workflow tools 允许 Agent Builder 对话触发 Elastic Workflow，并使用其输出。这是从 "agent 推荐下一步操作" 到 "agent 可以提供一个已知操作" 的桥梁。

一个 workflow tool 应该有一个范围明确的描述：

`

1.  Use this tool only when checkout errors are caused by connection pool exhaustion on a single worker.

3.  The workflow drains and recycles the connection pool for one worker, then verifies that the worker resumes successful requests.

5.  Required input:
6.  - host_name

8.  Do not use this tool for database outages, deploy regressions affecting all hosts, or multi-host failures.

`AI写代码

描述很重要，因为它定义了 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 输出是否足够完整以供审核，以及工程师是否信任其推荐的下一步操作。

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

1. 选择一种具有明确 runbook 的告警类型。

2. 为该告警构建一个只读 investigation skill。

3. 添加一两个具有受限 index 权限的查询 tools。

4. 使用历史故障事件运行 agent，并将其摘要与实际 case notes 进行比较。

5. 添加 case-creation workflow，并与负责该服务的 SRE 团队一起审核输出。

6. 只有完成这些步骤后，才考虑添加一个能够执行受限 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 Observability

• Agent Builder skills

• Agent Builder tools

• Workflow tools

• AI-augmented workflows

• Root cause analysis workflow for observability alerts

原文：Automated root cause analysis with Elastic Agent Builder | Elastic Observability Labs