Elastic AI RCA 产品调研

• 调研对象：Elastic 在 Observability、AIOps、AI Assistant、Agent Builder、Streams、Workflows、MCP Apps 等方向的公开产品与文档
• 适用视角：国内监控、可观测性、AIOps、AI SRE 产品规划参考
• 主要资料来源：Elastic 官方文档、官网产品页、官方博客、官方新闻稿。文末附引用链接。

一句话结论

Elastic 在 AI RCA 上的产品思路，不是把 “Root Cause Analysis” 做成一个单独按钮，而是把 Elastic 最擅长的搜索、日志、机器学习和开放生态能力，串成一条故障调查链路：

先用统一数据底座承接 logs、metrics、traces、alerts、APM、infrastructure 等遥测数据；再用机器学习做异常检测、日志模式分析、日志速率变化分析、APM latency / failure correlations、change point detection；再用 AI Assistant / Elastic AI Agent 把这些结构化证据转成自然语言解释、查询、图表、时间线和处置建议；最后通过 Agent Builder、Workflows、MCP Server / MCP Apps，把可观测性能力带到外部 AI 工具和自动化流程里。

这条路线和 New Relic、incident.io 有明显差异。New Relic 更强调一体化遥测平台上的事件关联、Issue、SRE Agent；incident.io 更强调事故协作入口、Slack、历史事故和 postmortem。Elastic 的底色更像 “Search AI Platform for Ops”：它把 RCA 看成一个搜索、统计、相关性、日志结构化、知识检索和工具调用共同完成的过程。

对国内厂商最值得借鉴的点是：不要急着宣称 “AI 自动给根因”。更现实的产品路径是先把故障调查中的证据收集、模式发现、上下文压缩、查询生成、运行手册匹配、低风险动作自动化做好。RCA 的可信度来自数据工程和产品工作流，不只是大模型回答。

1. Elastic AI RCA 的产品版图

从公开资料看，Elastic 在故障定位、AI RCA 相关方向大致形成了七层能力。

这个组合背后的逻辑很清楚：Elastic 不试图只靠 LLM 推理完成 RCA，而是先让平台产生结构化信号，再让 AI 调用工具、检索知识、解释结果。

2. 当前产品状态：AI Assistant 正在让位给 Elastic AI Agent

调研时需要注意一个重要变化：Elastic 最新文档已经明确写到，Elastic AI Assistant for Observability and Search 已被标记为 deprecated，Elastic AI Agent 现在是 Observability 中默认的聊天体验。如果用户仍要切回 AI Assistant，需要在 GenAI settings 中配置。

这说明 Elastic 的 AI 产品正在从 “助手” 转向 “Agent Builder + Agent + Tools + Skills” 的架构。这个变化很关键。

早期 AI Assistant 更像嵌在 Kibana 里的自然语言入口，功能包括：

• 解释 stack trace、错误日志，帮助定位可能原因。
• 识别性能瓶颈，例如资源密集操作、慢查询。
• 生成 alert summary、incident timeline、关键指标报告。
• 把自然语言转成 Elasticsearch query、ES|QL，并直接执行。
• 生成时序图、分布图等可视化。
• 在 APM、Infrastructure、Logs、Alerting、Universal Profiling 等页面提供 contextual prompts。

而 Agent Builder 的设计更进一步：Agent 不只是回答问题，而是带着 tools 和 skills 迭代执行任务。官方文档把 Agent 描述为根据用户目标选择工具、传参、执行、评估返回结果，再决定是否继续调用工具，直到完成回答。

这对 RCA 产品形态有明显影响：

AI Assistant 时代，产品关注 “用户问一句，AI 答一句”。 Agent Builder 时代，产品关注 “用户给一个调查目标，Agent 拆解任务、调用工具、组织证据、给出结论和下一步”。

对国内厂商来说，这个转变值得跟进。单纯做一个聊天框已经不够了，下一步是把可观测性系统里的查询、拓扑、告警、日志聚类、变更、工单、运行手册、通知动作，都抽象成 AI 可调用的工具。

3. Elastic 的 RCA 路线：从日志和搜索优势出发

Elastic 的核心优势一直是搜索和日志。它做 AI RCA 的方式也很自然：先把混乱、半结构化、非结构化的运行数据变成可搜索、可聚合、可统计、可解释的证据。

Streams：把日志治理前移

Elastic 近年很强调 Streams。它不是狭义 RCA 功能，但对 RCA 很重要。真实故障定位里，大量根因线索藏在日志里，而日志的问题通常不是 “没有数据”，而是：

• 格式混乱；
• 字段没抽取；
• pipeline 脆弱；
• schema 不一致；
• 日志量巨大；
• 高噪声日志挤占存储和查询成本；
• 出故障时才发现日志无法有效过滤和关联。

Streams 的产品思路是把日志接入、解析、分区、字段抽取、生命周期策略集中到 Kibana 的统一 UI 里。它支持 AI suggestions 来建议日志分区，也支持 AI 生成 grok patterns，帮助用户从非结构化日志中抽字段。

这背后有一个很务实的判断：RCA 的质量不只是事后分析能力决定的，更多时候取决于事前数据有没有被整理好。Elastic 把 AI 用在 “日志接入和治理” 阶段，虽然不如 “AI 一键 RCA” 吸睛，但实际价值很高。

Significant Events / Log rate spikes

Elastic 在日志分析产品页里强调，Streams 可以用 agentic AI 自动突出 critical errors、anomalies、system changes 等 significant events。Log rate analysis 也会在日志速率出现 spike 时自动运行，给出问题描述和处置建议，用户还可以从这里继续进入 Observability AI Assistant 做深入调查。

这是一种很好的入口设计：AI 不要求用户先知道问什么，而是在用户看到异常日志速率、日志模式、重要事件时，直接给出解释和下一步入口。

国内产品常见问题是把 AI 做成一个悬浮聊天框，让用户自己组织问题。Elastic 的做法更好：在故障证据出现的页面上直接嵌入 AI。

4. 机器学习是 Elastic RCA 的第一层证据引擎

Elastic 的 RCA 并不只靠生成式 AI。它有较长时间积累的机器学习和统计分析能力，这些能力反而是 AI RCA 可信度的基础。

Anomaly detection

Elastic Machine Learning 的 anomaly detection 会对时间序列构建概率模型，持续识别异常事件，模型会随时间演进，也能用于预测未来行为。这类能力适合指标、日志速率、APM、基础设施等场景。

它的价值不是直接告诉用户最终根因，而是把 “哪里发生了异常” 先找出来。对 RCA 来说，这一步相当于把调查范围从全量数据压缩到少数异常时间段、实体、字段或模式。

Log rate analysis

Log rate analysis 用统计方法分析日志速率突然升高或降低的原因，并把显著字段和值展示出来。Elastic 文档强调，它可以从可能包含数百万日志事件的多个字段和值中，找到导致某个变化的原因候选。

这类功能非常适合日志型故障：

• 某类错误突然增加；
• 某个服务日志突然下降，可能代表服务停止输出；
• 某个版本、pod、region、customer、endpoint 贡献了大部分异常日志；
• 某个字段值在异常窗口里显著过度出现。

它不是大模型的自由发挥，而是统计分析给出候选解释。LLM 再把这些候选解释成自然语言，可信度会高很多。

Log pattern analysis

Log pattern analysis 会对选定字段做 categorization analysis，把大量相似日志归成模式，并展示每类模式的分布和示例文档。用户可以跳转到 Discover 继续过滤和检查。

这解决的是故障现场最常见的体力活：不是让人一行一行翻日志，而是先把相似日志聚类，告诉用户异常窗口里到底多了哪几类日志。

对国内厂商来说，日志模式分析应该是 AI RCA 的基础能力之一。没有日志聚类和模式差异分析，只把日志塞给 LLM，总会遇到 token、噪声、幻觉和成本问题。

Change point detection

Change point detection 用 change point aggregation 检测时间序列中的分布变化、趋势变化和显著变化点。文档里也明确标注这是 technical preview，可能会变更或移除。

这个能力适合回答 “什么时候开始变坏”：

• 延迟从哪个时间点开始抬升；
• 吞吐从哪个时间点开始下降；
• 错误率在哪个 bucket 开始切换到新分布；
• 某个 host、service、region 是否比其他分组更早出现变化。

但 Elastic 也在产品上保持了边界：它用 p-value、变化类型、分组字段来呈现统计结果，而不是直接把变化点包装成最终根因。

APM latency / failure correlations

APM correlations 是 Elastic RCA 很有代表性的功能。它会找出和高延迟 transaction 或失败 transaction 显著相关的属性，例如 host、pod、region、user segment、hardware、版本等。

产品设计上，它让用户从 APM service 的 transaction group 进入 correlations tab，看 latency distribution 或 failed transaction distribution，再看哪些字段和值对慢请求或失败请求贡献更大。用户可以用正向/反向过滤快速缩小样本，继续查看 trace。

这个设计非常符合真实排障流程：

先看全局慢不慢，再找慢请求是不是集中在某个维度，再把噪声过滤掉，再看样本 trace。

它没有把 “相关性” 偷换成 “因果性”。文档用的是 potentially correlated、potentially point toward the root cause 这一类表达。这个措辞很重要，因为很多 RCA 产品最容易过度承诺。

5. AI Assistant / AI Agent：把证据转成可执行调查

Elastic AI Assistant 的价值，不是代替底层分析，而是把底层分析结果组织成用户能理解、能追问、能执行的调查过程。

Contextual insights：AI 放在证据现场

Elastic 在多个 Observability 页面嵌入 contextual prompts：

• Universal Profiling：解释最昂贵的 library / function，并给优化建议。
• APM：解释 APM errors，并给 remediation suggestions。
• Infrastructure：解释主机上运行的进程。
• Logs：解释日志消息，生成查找相似日志的 search pattern。
• Alerting：针对 log rate changes 给出可能原因和修复建议。

这个设计比独立 AI 页面更强，因为用户不需要先把上下文复制给 AI。AI 可以直接读取当前屏幕上的结构化数据、当前数据集、告警、日志、APM 服务等上下文。

Function calling：让 AI 调工具，而不是凭空回答

Elastic AI Assistant 使用 function calling 来获取上下文。文档列出的函数包括：

• alerts：获取 Observability alerts。
• changes：获取 logs 和 metrics 的 spikes / dips 等 change points。
• elasticsearch：调用 Elasticsearch APIs。
• get_data_on_screen：读取当前屏幕结构化数据。
• get_dataset_info / get_alerts_dataset_info：了解数据集和字段。
• query：生成、执行和可视化查询。
• retrieve_elastic_doc：检索 Elastic 文档。
• summarize：把信息存入知识库。
• APM 数据存在时，还可以调用 APM 相关函数，例如获取 downstream dependencies。

这说明 Elastic 的 AI RCA 不是纯 prompt，而是工具化产品。AI 的一部分价值来自 “知道什么时候调用哪个工具”，另一部分来自 “把工具结果组织成调查叙事”。

国内厂商可以直接借鉴：AI RCA 平台应该把内部能力工具化，例如：

• 查询指标；
• 查日志模式；
• 查 trace；
• 查拓扑上下游；
• 查变更；
• 查发布记录；
• 查告警历史；
• 查 CMDB；
• 查运行手册；
• 查历史故障；
• 创建工单；
• 发 IM 通知；
• 生成复盘草稿。

这些工具要有明确输入、输出、权限和审计，而不是让大模型直接拼 SQL 或自由调用接口。

Alert workflow connector：从告警触发调查

Elastic 提供 Observability AI Assistant connector，可以在 alerting workflow 中调用 AI Assistant。告警触发时，会把事件上下文发给 AI Assistant，再根据配置消息执行任务，例如创建图表、回忆历史相似告警、查找 active alerts、生成报告，并把结果发到 Slack。

这类能力的关键不是 “AI 写了一段话”，而是把 AI 放进告警流程里，让 AI 在告警触发时自动完成第一轮上下文收集。

但它也有边界：文档提到每个规则只能有一个 Observability AI Assistant action，且 token / function call limit 可能影响过宽泛的提示词或一次分析多个告警。这提醒我们，AI RCA 产品需要非常重视任务粒度。一个告警触发一次小调查，比一次性让 AI 分析整个告警风暴更可控。

6. Knowledge Base：RAG 是让 RCA 接近客户现场的关键

Elastic AI Assistant 的知识库使用语义检索，把 top results 作为上下文传给 LLM。它支持 ELSER 和 E5，前者更适合英文场景，后者支持多语言。用户可以把 runbooks、GitHub issues、内部文档、Slack messages 等资料加入知识库，也可以通过内容连接器接入 GitHub、Confluence、Google Drive、Jira、S3、Teams、Slack 等外部数据。

这对 RCA 很关键。真正的故障定位不仅需要实时遥测数据，还需要组织内部知识：

• 这个告警过去怎么处理；
• 哪个 runbook 有步骤；
• 哪个服务最近迁移过；
• 哪个团队负责；
• 哪些错误可以忽略；
• 哪些客户环境特殊；
• 哪个历史事故和当前现象相似；
• 哪些变更经常导致同类问题。

Elastic 的设计说明，RCA 不应该是每次从零推理。RCA 更应该是 “实时证据 + 组织记忆 + 工具调用”。

这里也有值得注意的折中。知识库需要 ML node，Elastic Cloud 开启 autoscaling 后可能带来额外成本；内容连接器在 Elastic Stack 9.0+ 或 Serverless 场景需要 self-managed connector service；切换知识库 embedding model 后需要重新索引。对企业用户来说，这些都是部署和成本门槛。

国内厂商如果要做类似能力，建议一开始就把 “知识来源、索引范围、权限继承、更新频率、版本重建、失效策略、敏感信息处理” 设计清楚。否则 RAG 很快会变成一个看起来很智能、实际不可治理的功能。

7. Agent Builder：Elastic 正在把 RCA 做成可扩展 Agent 平台

Elastic Agent Builder 是 Elastic AI 平台的核心演进方向。它提供自然语言聊天界面、内置 agents 和 tools，也允许用户创建 custom agents 和 custom tools。它还支持导入外部 MCP server 的工具，以及把自己的工具和 agent 暴露给外部系统。

在 Observability 场景下，Agent Builder 提供 built-in Observability skills。官方文档里 observability.investigation skill 的描述很直接：回答可观测性问题，并诊断 APM services 和 infrastructure 中的问题，覆盖 service health、error rates、latency、failed transactions、service topology、trace analysis、log patterns、SLO breaches、alert investigations 等。

Agent Builder 的 built-in Observability tools 也很贴近 RCA：

• observability.get_alerts：按时间范围和条件取 Observability alerts。
• observability.get_services：获取 APM services 信息。
• observability.get_hosts：获取 infrastructure hosts 信息。
• observability.get_trace_change_points：检测 trace latency、throughput、failure rate 的显著变化点。
• observability.get_apm_correlations：分析 APM transaction correlations，找出和慢请求、失败请求最相关的维度。

这说明 Elastic 正在把 RCA 拆成一组可组合的工具，而不是一个封闭功能。Agent 的价值是根据用户问题选择合适工具，并把结果串起来。

这个设计值得国内厂商认真借鉴。很多厂商会把 “RCA 算法” 做成一个黑盒接口，输入告警 ID，输出根因。这种方式短期容易包装，但长期难扩展。更好的方式是：

• 把 RCA 拆成多个专用工具；
• 每个工具有清晰适用场景；
• 工具输出结构化证据；
• Agent 负责规划、调用、总结；
• 用户可以检查每一步证据；
• 客户可以按自己的行业和系统扩展工具。

8. Workflows：把非确定性推理和确定性动作拆开

Elastic Workflows 是内置自动化引擎，可以用 YAML 定义确定性的事件驱动流程。它和 Agent Builder 的关系很重要：

• Agent 可以触发 Workflows，执行可靠、可重复的动作。
• Workflows 可以在某个步骤调用 Agent，让 LLM 处理需要推理、语言理解或上下文综合的部分。

这是 AI RCA 产品设计里非常重要的边界。

故障处置里有些事情适合 agent：

• 解释日志；
• 总结告警；
• 比较多个候选原因；
• 生成查询；
• 写调查报告；
• 匹配 runbook；
• 推荐下一步。

但有些事情应该走 deterministic workflow：

• 创建 case；
• 通知值班人；
• 发 Slack / PagerDuty / ServiceNow；
• 调用固定检查脚本；
• 执行低风险回滚前检查；
• 归档证据；
• 生成复盘模板；
• 执行需要审批的动作。

Elastic 把这两者拆开，是很成熟的产品思路。AI 不应该接管所有流程。AI 负责判断、解释和建议，Workflow 负责可审计、可复现、可治理的动作。

国内厂商做 AI SRE 时，也应该避免 “全自动修复” 的空泛表达。更可行的路线是：AI 给出调查和建议，Workflow 提供受控执行，人类在关键动作前确认。

9. MCP Server / MCP Apps：RCA 入口正在离开监控控制台

Elastic 在 MCP 上动作很积极。

Elastic Agent Builder MCP server 给外部客户端提供标准接口，让 Claude Desktop、Cursor、VS Code 等工具访问 Elastic Agent Builder tools。工具执行使用 API key 的权限范围，Elastic 文档也建议生产环境限制 API key 只访问必要 indices，并设置过期时间。

2026 年 4 月 21 日，Elastic 还宣布 MCP Apps for Elastic，把安全、可观测性和搜索工作流嵌入第三方 AI 工具。它的核心判断是：文本摘要无法承载天然需要交互的工作流，比如告警列表、调查图、dashboard、distributed trace。MCP Apps 允许工具返回文本摘要的同时返回交互式 UI，用户可以在 Claude、VS Code、GitHub Copilot、Goose、Postman、MCPJam 等环境里直接查看、过滤、钻取和行动。

这个方向对 RCA 很有启发。未来故障排查不一定发生在监控平台页面里，而可能发生在：

• IDE；
• 命令行；
• IM 群；
• AI coding assistant；
• 工单系统；
• 事故管理平台；
• 内部 AI portal。

可观测性厂商如果只把 AI 做在自己的控制台里，很可能错过工程师实际工作的入口。Elastic 的 MCP Apps 给出的方向是：可观测性平台不只是 UI 产品，也要成为外部 AI agent 的数据、工具和交互组件提供方。

国内厂商可以结合企业微信、飞书、钉钉、IDE 插件、私有化 AI 助手，做类似的 “带交互组件的 RCA”。只返回一段文字是不够的，trace waterfall、日志模式、指标对比、拓扑图、告警列表、变更时间线，都应该能在对话里交互。

10. 产品亮点

亮点一：RCA 前置到数据治理，而不是只做事后解释

Elastic 很清楚，故障定位的上限由数据质量决定。Streams、AI grok、AI partitioning、ECS / OTel 标准化、auto-import，本质上都是在提升 RCA 的上游质量。

这对国内厂商尤其重要。很多企业的监控数据不是不够多，而是日志没结构化、标签不一致、服务名混乱、拓扑缺失、告警字段不规范。直接做 AI RCA，只会把这些脏数据包装成更漂亮的不确定答案。

亮点二：统计和 ML 先收敛，LLM 再解释

Elastic 没有把所有 RCA 压在 LLM 上。它用 log rate analysis、pattern analysis、change point、APM correlations、anomaly detection 先找候选证据，再让 AI 解释和组织。

这是更稳的路线。LLM 适合总结、解释、编排、生成查询、匹配知识，不适合在海量原始遥测中盲猜因果。

亮点三：AI 嵌在问题现场

Elastic 把 AI 放在 logs、APM、Infrastructure、Alerting 等上下文页面里。用户看到异常，就能直接让 AI 解释当前日志、当前告警、当前进程、当前错误。

这种 embedded assistance 比通用聊天框更容易产生使用。用户不需要先描述上下文，AI 也不需要靠用户复制粘贴来理解场景。

亮点四：工具化和可扩展性强

Agent Builder 的 tools、skills、custom agents、MCP server，让 Elastic 的 AI RCA 具备平台属性。客户可以扩展自己的 tools，也可以把 Elastic tools 暴露给外部 AI 系统。

这比固定 RCA 页面更有想象力。不同企业的 RCA 上下文差异很大，工具化平台比单一算法更能适配。

亮点五：开放模型和部署选择

Elastic 支持 Elastic Managed LLMs，也支持 OpenAI、Azure OpenAI、Amazon Bedrock、Google Gemini，还支持连接本地 LLM。这对企业客户很现实，因为不同客户对数据出境、模型供应商、私有化、成本和合规要求不同。

国内厂商也应该避免把 AI RCA 绑定到单一模型。更好的产品架构是模型可替换、工具协议稳定、评估体系内置。

亮点六：MCP Apps 把 “AI 回答” 升级成 “AI 工作流界面”

这是 Elastic 最近最值得关注的动作。RCA 的证据天然是视觉和交互式的：图表、trace、拓扑、日志列表、告警表、时间线。把它压缩成一段文本会损失大量信息。

MCP Apps 的价值在于让 AI 对话返回可交互 UI。这个方向很可能会影响未来可观测性产品的交互形态。

11. 重要折中和限制

折中一：产品命名和体验正在迁移

AI Assistant 已经 deprecated，Elastic AI Agent 成为默认聊天体验，Agent Builder 还需要在 Observability 中 opt in。对用户来说，这可能带来命名、入口、能力边界和迁移认知成本。

国内厂商如果也从 Assistant 演进到 Agent，需要提前设计清楚产品叙事：哪些能力是旧助手，哪些是新 agent，历史能力如何迁移，权限和价格如何变化。

折中二：很多能力依赖订阅、ML 资源和 LLM 连接器

AI Assistant 需要合适订阅、Kibana privilege、LLM connector；知识库需要 4GB ML node；Elastic Managed LLMs 可能产生额外成本；某些 Agent Builder / Observability 能力也依赖特定版本、特性开关或 license。

这不是缺点，而是企业级 AI 产品的现实。AI RCA 的成本不只是模型 token，还包括 ML 节点、向量索引、连接器、工具调用、存储和查询成本。

折中三：数据安全需要用户显式配置

Elastic 文档明确说明，AI Assistant 查询使用当前用户权限，这是好的；但也说明发给 AI Assistant 的数据默认不匿名化，可能包括 alert data、configurations、queries、logs、chat interactions。需要匿名化时，用户要启用 anonymization pipeline。

它支持 RegExp 和 NER 规则，但也列出了限制：非字符串字段不处理，NER 会增加延迟，结构化 JSON 里的实体可能漏检，模型有 false negative / false positive。

这对国内厂商是强提醒：企业 AI RCA 必须把脱敏、权限、审计、数据出境、模型供应商、私有化部署作为核心产品能力，而不是售前问到才解释。

折中四：相关性不是因果性

APM correlations、log rate analysis、change point detection 都能给出强信号，但它们不能天然等同于最终根因。Elastic 的公开文档在措辞上比较谨慎，更多使用 correlated、potentially point to root cause、statistically significant 等表达。

国内厂商要避免把统计相关包装成 “根因已确定”。更好的 UI 是展示证据链、置信度、候选原因、反证和下一步验证动作。

折中五：Agent 能力强，但成本和可控性更复杂

Agent 的 tool selection、multi-step reasoning、function calling 会消耗 token，也可能遇到上下文长度、函数调用上限、权限不足、工具失败等问题。Elastic 文档里也提醒过宽泛 prompt 可能超过 token limit，一次分析多个告警可能超过 function call limit。

这说明 Agentic RCA 需要任务边界设计：什么是一次调查，最多调用几步，哪些动作只读，哪些需要审批，失败后如何降级，用户如何查看每一步证据。

12. 对国内可观测性厂商的借鉴建议

1. 不要从 “一键根因” 开始，从 “一键调查包” 开始

更可信的 AI RCA 产品形态不是直接说 “根因是 X”，而是生成一个调查包：

• 发生了什么；
• 什么时候开始；
• 哪些服务、主机、pod、region、版本受影响；
• 哪些指标变化最大；
• 哪些日志模式新增或激增；
• 哪些 trace 变慢或失败；
• 最近有哪些发布、配置、扩容、依赖变化；
• 历史上有没有类似事故；
• 可能原因有哪些；
• 每个原因的证据和反证是什么；
• 下一步该检查什么；
• 有哪些 runbook 可以执行。

用户会更信任 “证据充分的候选原因”，而不是 “神秘的根因结论”。

2. 把日志 RCA 做深，别只盯指标和拓扑

Elastic 的强项提醒我们：日志仍然是 RCA 最丰富的数据源。国内厂商可以优先做：

• 日志模板聚类；
• 异常窗口 vs 基线窗口的日志模式差异；
• 错误日志摘要；
• 日志速率变化原因分析；
• 日志字段自动抽取；
• 日志和 trace / metric 的关联；
• 日志里的版本、实例、客户、区域、错误码过度出现分析。

这类能力比通用聊天更容易落地，也更容易让用户感知 MTTR 改善。

3. 建立 “ML/统计证据 + LLM 解释” 的双层架构

不要让大模型直接对原始数据做 RCA。应该先用确定性或统计工具产生候选信号，再让 LLM 整理：

• 异常检测找时间段；
• change point 找开始时间；
• correlation 找维度；
• pattern analysis 找日志类别；
• trace analysis 找慢 span；
• topology 找影响路径；
• change analysis 找变更；
• RAG 找 runbook 和历史事故。

LLM 负责把这些证据组织成可读结论、生成查询、推荐下一步，而不是凭空推理。

4. AI 要嵌到故障页面，不要只做独立聊天

建议在这些位置直接提供 AI 入口：

• 告警详情页：解释告警、拉取相关告警、生成初步调查报告。
• 日志详情页：解释日志、找相似日志、找异常窗口内新增模式。
• APM trace 页：解释慢 span、关联错误、查看下游依赖。
• 服务概览页：总结服务健康、错误率、延迟、吞吐、实例异常。
• 事件时间线：生成事故摘要、影响面、下一步。
• 复盘页面：生成 timeline、root cause candidate、follow-ups。

AI 的最佳入口不是 “问我任何问题”，而是 “基于你正在看的问题，我先帮你查这几件事”。

5. 把客户知识库做成产品主线

RCA 很依赖客户自己的知识。国内厂商应该把以下内容纳入知识库：

• 运行手册；
• 历史故障；
• 值班记录；
• 变更单；
• 发布单；
• CMDB；
• 架构文档；
• 服务负责人；
• 告警处理说明；
• IM 群消息；
• 工单；
• FAQ。

同时要内置权限继承、空间隔离、脱敏、索引状态、重新索引、内容过期、引用来源展示。没有治理能力的知识库，越用越危险。

6. 把 RCA 能力工具化，给 Agent 调用

建议把 RCA 能力设计成一组工具：

• get_alert_context
• get_related_alerts
• get_metric_change_points
• get_log_rate_analysis
• get_log_patterns
• get_trace_slow_spans
• get_service_dependencies
• get_recent_changes
• search_runbooks
• search_past_incidents
• create_incident_report
• notify_oncall

每个工具都应该有固定 schema、权限校验、调用审计、错误返回和可展示结果。这样未来无论接入自研 Agent、MCP、企业微信机器人、飞书机器人还是 IDE 插件，都能复用。

7. 低风险自动化优先，不要急着自动修复

Elastic 用 Workflows 把确定性动作和 Agent 推理拆开，这非常值得学。国内产品可以先从低风险自动化开始：

• 告警触发后自动生成调查摘要；
• 自动拉相关指标图；
• 自动列出近期变更；
• 自动查历史相似事故；
• 自动推荐 runbook；
• 自动创建工单；
• 自动生成复盘初稿；
• 自动通知服务 owner。

真正涉及生产变更的动作，例如扩容、重启、回滚、配置修改，应该先走审批和 human-in-the-loop。

8. 面向外部 AI 工具开放，而不是把用户锁在控制台

MCP Server / MCP Apps 的方向值得国内厂商提前布局。未来可观测性能力应该可以被外部 AI 调用：

• 在 IDE 里问某个服务最近为什么报错；
• 在 IM 群里让 AI 拉取告警上下文；
• 在工单里自动补充服务健康和近期变更；
• 在 Copilot / Claude Code 中查看 trace 和日志模式；
• 在事故频道里展示可交互的告警列表、拓扑和日志聚类。

这不是简单返回链接，而是返回可交互组件和结构化工具结果。

9. 对 AI RCA 做评估体系

Elastic 有 LLM performance matrix 的思路，虽然这次没有展开细看，但方向值得借鉴。国内厂商应该为 AI RCA 建立评估集：

• 告警摘要准确率；
• 根因候选命中率；
• 证据引用完整度；
• 幻觉率；
• 查询生成成功率；
• 工具调用成功率；
• 平均 token 成本；
• 平均调查耗时；
• 用户接受率；
• 建议被编辑比例；
• runbook 匹配准确率；
• 历史事故召回率。

没有评估体系，AI RCA 很容易停留在 demo 好看、生产不稳的阶段。

13. 总结：Elastic 的真正启发

Elastic 的 AI RCA 路线最值得借鉴的地方，不是某一个具体功能，而是它对 AI 和可观测性关系的判断：

AI 不是替代可观测性平台，而是放大可观测性平台已有的数据、搜索、统计、机器学习、知识库、工具和工作流能力。

Elastic 没有把 RCA 简化成 “问大模型根因是什么”。它做的是一条更工程化的路径：

1. 先把数据接进来，尽量标准化和结构化。
2. 用 ML 和统计分析把异常、变化、模式、相关维度找出来。
3. 用 RAG 把 runbook、历史事故、内部知识接进来。
4. 用 AI Assistant / Agent 把证据组织成自然语言和调查步骤。
5. 用 Workflows 把可重复动作自动化。
6. 用 MCP 把能力开放到工程师真实工作的地方。

这条路线没有 “一键根因” 那么好营销，但更接近真实生产环境。对国内可观测性厂商来说，最实际的借鉴是：先把 RCA 做成可信的证据链和调查流程，再逐步走向 agentic automation。用户最终买单的不是 AI 的神奇感，而是事故里少翻几小时日志、少切几十个页面、少漏一次关键变更、少写一份重复复盘。

参考资料

1. Elastic Docs: Elastic AI Assistant for Observability and Search https://www.elastic.co/docs/solutions/observability/ai/observability-ai-assistant
2. Elastic Docs: Agent Builder for Observability https://www.elastic.co/docs/solutions/observability/ai/agent-builder-observability
3. Elastic Docs: Elastic Agent Builder https://www.elastic.co/docs/explore-analyze/ai-features/elastic-agent-builder
4. Elastic Docs: Elastic Agent Builder agents overview https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/agent-builder-agents
5. Elastic Docs: Elastic Agent Builder built-in skills reference https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/builtin-skills-reference
6. Elastic Docs: Elastic Agent Builder built-in tools reference https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/tools/builtin-tools-reference
7. Elastic Docs: Elastic Agent Builder MCP server https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/mcp-server
8. Elastic Docs: AIOps Labs https://www.elastic.co/docs/explore-analyze/machine-learning/machine-learning-in-kibana/xpack-ml-aiops
9. Elastic Docs: Find transaction latency and failure correlations https://www.elastic.co/docs/solutions/observability/apm/find-transaction-latency-failure-correlations
10. Elastic Docs: What is Elastic Machine Learning? https://www.elastic.co/docs/explore-analyze/machine-learning
11. Elastic Observability AIOps product page https://www.elastic.co/observability/aiops
12. Elastic Log analytics product page https://www.elastic.co/observability/log-monitoring
13. Elastic Docs: Partition data into child streams https://www.elastic.co/docs/solutions/observability/streams/management/partitioning
14. Elastic Docs: Observability AI Assistant connector and action https://www.elastic.co/docs/reference/kibana/connectors-kibana/obs-ai-assistant-action-type
15. Elastic Blog: Elastic on Elastic: How we monitor our own services, websites, and operations https://www.elastic.co/blog/how-we-monitor-at-elastic
16. Elastic News: Elastic Delivers First Embedded AI Experiences for Observability and Security Inside Third-Party AI Tools https://ir.elastic.co/News--Events/news/news-details/2026/Elastic-Delivers-First-Embedded-AI-Experiences-for-Observability-and-Security-Inside-Third-Party-AI-Tools/default.aspx
17. Elasticsearch Labs: Elastic Security, Observability, and Search now offer interactive UI in your AI tools https://www.elastic.co/search-labs/blog/mcp-apps-elastic
18. Elastic demo gallery: Root cause analysis with the AI Assistant for Observability https://www.elastic.co/demo-gallery/rca-ai-assistant-observability