Splunk AI RCA 产品调研

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

一句话结论

Splunk 在 AI RCA 上的路线，不是单纯给 Splunk 搜索框加一个大模型，而是沿着三条线同时推进：

第一条是 Splunk Observability Cloud 的 AI Troubleshooting Agent。它把 RCA 放进告警详情页，告警打开后自动分析 APM、Kubernetes、日志、指标、trace、service dependency 和业务 workflow，给出 impact radius、primary root cause、suspected root causes、Evidence 以及 AI-generated action plan。

第二条是 Splunk AI Assistant / Agent Mode / MCP Server。它把自然语言、SPL、SignalFlow、APM 查询、alert/incident 查询、外部 AI 工具连接起来，让用户用对话完成查询生成、服务健康分析、trace/log 分析和进一步调查。

第三条是 ITSI + AppDynamics 的传统 AIOps / APM RCA 能力。ITSI 侧强调事件聚合、episode、Event iQ、相似事件、服务健康和运维工作台；AppDynamics 侧强调业务交易、拓扑、异常检测、suspected causes、fault domain isolation，以及 Cisco 收购 Splunk 后的统一观测体验。

这家公司最值得研究的地方在于：Splunk 不是把 RCA 看成 “模型回答根因”，而是把 RCA 放进完整运维链路：从告警、事件聚合、服务健康、影响面，到证据、假设、行动计划、外部工单和后续自动化。它的优势是数据平台、搜索语言、ITSI 事件管理和 AppDynamics 应用拓扑的组合；折中是产品线较多、体验正在整合、部分 AI Agent 能力仍有地域/指标/预览限制，且 AI Assistant 的数据使用、成本和上下文边界需要企业客户认真评估。

1. Splunk AI RCA 的产品版图

从公开资料看，Splunk 现在的故障定位和 AI RCA 能力分布在多个产品层。

这个版图说明 Splunk 的 AI RCA 不是一个孤立产品，而是一个组合拳：Observability Cloud 负责云原生和实时排障，ITSI 负责企业 IT 事件管理，AppDynamics 负责混合和传统应用性能，Splunk 平台和 SPL 负责数据检索与分析，AI Assistant / Agent / MCP 负责把这些能力自然语言化和工具化。

2. Splunk 的主线：把 RCA 放到告警页面，而不是只放到聊天框

Splunk 当前最接近 “AI RCA 产品形态” 的能力，是 Splunk Observability Cloud 里的 AI troubleshooting agent and remediation plan。

官方文档说，这个能力用于分析 root causes、test hypotheses、resolve alerts。当用户打开与 Splunk APM services 或 Kubernetes in Infrastructure Monitoring 相关的 alert 时，Splunk Observability Cloud 会自动触发 AI troubleshooting agent 做 RCA，并在 alert 页面展示 suspected root causes。

产品上，它不是一个独立 AI 页面，而是嵌在 alert workflow 里。告警详情里有三个核心 tab：

• Overview：告警摘要、触发规则、impact analysis、blast radius、primary root cause、额外排障信息。
• Root Cause Analysis：展示可调查的 suspected root causes，支持查看每个候选原因的摘要和链接。
• Evidence：展示相关 logs、exemplar traces、Splunk APM services 以及其他对告警有贡献的证据。

这背后的产品判断很明确：RCA 的最佳入口是告警，而不是聊天窗口。用户收到 Slack、邮件或 ServiceNow 通知后，打开 alert，就应该看到第一轮机器调查，而不是再去问 “what happened?”。

这个设计和很多国内厂商常见做法不同。国内很多产品会先做一个 “AI 运维助手”，让用户自己把告警、时间范围、服务名、日志条件喂进去。Splunk 的做法更像一线值班视角：既然告警已经知道了 service、detector、time range、severity、affected entity，平台就应该自动把这些上下文拿来做第一轮 RCA。

3. AI Troubleshooting Agent：从 suspected root causes 到 remediation plan

Splunk 的 AI troubleshooting agent 不是只生成一段摘要，它把调查拆成几个明确步骤。

3.1 自动触发 RCA

AI troubleshooting agent 由 alerts 和 detectors 触发。detector 判断服务和基础设施是否健康，alert 负责通知人。用户打开相关 alert 时，agent 自动运行 RCA。

它的目标不是替代所有人工判断，而是自动完成第一轮重复劳动：

• 查看告警所属 domain；
• 判断影响半径；
• 分析相关服务和上下游；
• 拉取指标、trace、logs；
• 查找 Kubernetes nodes、clusters、services、business workflows 之间的异常关联；
• 提出 suspected root causes；
• 用 Evidence tab 展示证据。

官方博客对它的描述很接近一个 SRE 排障 checklist：先看 payment service 的错误和延迟，再看 APM tags，理解影响范围和 upstream services，再看 traces 和 spans，必要时再看 logs 和 infrastructure。AI agent 的价值就是把这套页面跳转和证据收集自动化。

3.2 展示假设，而不是只给结论

文档里反复使用 suspected root causes、hypotheses、evidence 这些词。这个措辞值得注意。Splunk 没有把 AI RCA 包装成绝对结论，而是把它设计成 “候选原因 + 证据 + 进一步验证”。

在 Root Cause Analysis tab 里，用户可以选择某个 suspected root cause 继续调查，通过摘要里的链接进入对应的 Splunk Observability Cloud 组件，例如 trace analyzer、Kubernetes node、APM service、log view。

这个设计降低了 AI 幻觉风险。用户看到的不只是 “根因是 X”，还可以继续 drill down 到具体证据。

3.3 Evidence tab 是可信度核心

Evidence tab 展示相关日志、exemplar traces、APM services 等证据。这个 tab 非常关键，因为 AI RCA 要被 SRE 接受，不能只输出漂亮文字，必须能解释 “为什么它这么判断”。

对国内厂商来说，这里最值得借鉴的是：AI RCA 的界面要把 evidence 作为一等公民。建议每个候选根因至少包含：

• 关联指标；
• 关联日志模式；
• 关联 trace/span；
• 关联实体；
• 时间关系；
• 影响面；
• 置信度或优先级；
• 反证或不确定性；
• 可继续验证的链接。

3.4 Remediation plan：把 RCA 推到行动

Splunk 的 AI remediation plan 会在用户查看 suspected root cause 后生成 guided steps。它会生成一组 hypotheses 和 root causes，并给出相关 actions。用户可以选择某个 hypothesis/root cause，看一个高层图，复制并运行建议的 kubectl command 或代码块，然后把输出提交回来，让计划决定下一步。

这个设计很有现实感。Splunk 没有直接说 “AI 自动修复生产系统”，而是让用户复制命令、执行、提交输出，再继续下一步。它其实是把 runbook 变成半交互式诊断流程。

这对国内厂商很有参考价值：AI RCA 不应该停在 “原因分析报告”，也不应该一上来就自动修复。更合适的是从 guided remediation 做起，让 AI 生成下一步检查、命令、验证标准和长期建议，关键动作仍由人执行。

3.5 当前限制

这个能力目前有几个重要限制：

• 官方文档显示，AI troubleshooting agent and remediation plan 目前只面向 Splunk Observability Cloud 的 us1 realm 客户开放，需要联系 Splunk representative。
• 当前支持与 Splunk APM services 和 Kubernetes in Infrastructure Monitoring 相关的 alerts。
• 文档明确说当前支持 detectors 和 alerts with standard, default metrics，不支持 custom metrics。
• RCA 是 per-user 运行；退出 alert 页面后仍会继续运行，重新进入可立即看到结果，也可以 regenerate。

这些限制说明该能力还处在较受控的推广阶段。Splunk 没有把它做成所有告警、所有数据、所有区域通用的能力，而是先收敛在 APM/Kubernetes/default metrics 这类数据模型相对清晰的场景。

4. AI Assistant in Observability Cloud：自然语言排障入口

除了自动 RCA Agent，Splunk Observability Cloud 还有 AI Assistant。它的定位是用自然语言访问 observability data，包括 metrics、traces、logs、alerts、dashboards、services、errors。

官方文档列出的典型场景包括：

• 获取 incident 或 alert 详情，例如总结某个 alert id 或 incident。
• 分析服务健康，例如某个服务过去 15 分钟有什么问题。
• 调查某个服务突然 latency increase。
• 分析 trace，例如按 trace ID 做 trace analysis，或找某个服务相关的 error traces。
• 分析 logs，例如找某个服务相关错误日志，总结某个 Kubernetes container 的日志。
• 分析 upstream / downstream services 来定位高错误率。
• 生成和执行 SignalFlow，例如查询高 CPU pod、创建 pod restart count 查询。
• 查询 infrastructure navigators 和 charts。

这说明 Splunk AI Assistant 更像一个 “observability copilot”：它不只回答知识问题，还会利用 Splunk Observability Cloud 里的 APM、Infrastructure Monitoring、Log Observer Connect、SignalFlow 数据。

4.1 Prompt guide 暴露了 Splunk 的产品边界

Splunk 官方 prompt guide 很有意思。它明确告诉用户要提供：

• specific tools or data；
• entity names and types；
• context and filters；
• time range。

它还给了一个很典型的例子： “I got paged, what’s wrong?” 是 poor prompt； “I got paged for api-gateway latency in prod2, what’s wrong?” 是 good prompt； “I got paged for incident <incident_id> what’s wrong?” 是 excellent prompt。

这个文档其实反映了 AI RCA 的底层规律：上下文越结构化、越明确，AI 的结果越可靠。告警 ID、incident ID、service name、environment、time range，比自然语言泛问重要得多。

国内厂商做 AI RCA 时，不应该只训练用户怎么写 prompt，而应该尽量在产品里自动补齐这些上下文。比如从告警页打开 AI 时，自动带上 alert id、service、entity、time range、severity、labels、top related logs、recent changes。

4.2 只支持英语是一个现实折中

截至本次调研，AI Assistant in Observability Cloud 的官方文档写明当前只支持 English。它可以在多个 realm 使用，包括 us0、us1、eu0、eu1、eu2、au0、jp0、sg0 等，但语言上仍是英文。

这和 Splunk AI Assistant for SPL 不同。后者在 Splunk Enterprise / Cloud 文档里显示支持多语言输入输出，包括简体中文等。这个差异说明 Splunk 的不同 AI 产品线成熟度和国际化进度并不一致。

对国内厂商来说，多语言不是可选项。中文告警、中文工单、中文 runbook、中文 IM 群消息是主场景。如果只做英文能力，国内落地会很弱。

4.3 日志查询会影响 SVC quota

文档也明确提醒，当 AI Assistant 需要查询 logs 时，会影响 SVC quota。这是一个很现实的成本边界。

AI RCA 产品必须让用户知道：一次 AI 调查不是免费的。它可能产生：

• 指标查询成本；
• 日志扫描成本；
• trace 查询成本；
• LLM token 成本；
• 向量检索成本；
• 自动化动作成本；
• 额外存储或采样成本。

如果产品不把成本透明化，AI RCA 很容易在试用时很惊艳，生产推广时被财务和平台团队卡住。

5. MCP Server：把 Splunk Observability 接到外部 AI 工具

Splunk 也提供了 Splunk MCP server。官方定义是通过标准、安全的方法，把 O11y AI Assistant capabilities 连接到外部工具。

文档列出的关键点包括：

• 支持自然语言访问 observability data；
• 可集成 AI development tools 和 IDE；
• 使用 SF tokens 和 JWT-based authentication；
• 支持 agentic workflows and automation；
• Hosted MCP Server 由 Splunk MCP Gateway 提供；
• 使用 streamable HTTP transport；
• 通过 user session token 保持用户上下文和 RBAC；
• 可配置到 VS Code、Claude Desktop 等 MCP 客户端；
• 支持除 Google Cloud Platform realms 和 GovCloud realms 之外的 Splunk Observability Cloud production realms。

它暴露的工具也很贴近 RCA：

• Metrics / SignalFlow：get_metric_names、get_metric_metadata、generate_signalflow_program、execute_signalflow_program。
• APM：get_apm_environments、get_apm_services、get_apm_service_dependencies、get_apm_service_latency、get_apm_service_errors_and_requests、get_apm_exemplar_traces、get_apm_trace_tool。
• Alerting：search_alerts_or_incidents。

这说明 Splunk 正在把 Observability Cloud 的关键排障能力工具化，并开放给外部 agent。

这个方向非常值得国内厂商借鉴。未来故障定位不一定发生在监控平台控制台里，而可能发生在：

• IDE；
• AI coding assistant；
• 运维机器人；
• 企业微信/飞书/钉钉；
• 工单系统；
• 事故频道；
• 私有化大模型门户。

可观测性平台需要成为 AI agent 的工具层和证据层，而不是只做自己的 Web UI。

6. Splunk AI Assistant / Agent Mode：把 SPL 和搜索能力变成 AI 工具

Splunk 还有一个容易被忽略但非常重要的能力：Splunk AI Assistant。

它和 Observability Cloud 的 AI Assistant 不是完全同一个东西。Splunk AI Assistant 面向 Splunk 平台和 SPL，目标是让用户更容易访问 Splunk 数据。官方文档说，它可以：

• 根据自然语言写 SPL；
• 解释 SPL；
• 优化 SPL；
• 在用户 tenant 中找到合适数据；
• validate results by running searches；
• troubleshoot ingestion and configuration issues；
• 回答 Splunk 产品概念和功能问题；
• 在熟悉的 Splunk interface 内完成这些任务。

这对 RCA 的价值很直接。大量 Splunk 用户的排障入口仍然是 SPL。生成式 AI 如果能帮助用户写出正确、可执行、符合环境上下文的 SPL，就能降低日志分析门槛。

Agent Mode

Splunk AI Assistant 2.0.0 引入了 Agent Mode。它允许 agentic response generation，能访问更多工具，包括 event scans、fetching existing dashboards、executing searches。它可以把用户 prompt 拆成并行 tool / skill calls，并在获得许可后执行 search。

这里有几个产品细节值得关注：

• 非简单 search 需要用户显式许可。
• search 会影响 consumption 和 SVC costs。
• 管理员可以开启或关闭 Agent Mode。
• 管理员可以通过角色和 capability 限制谁能执行高消耗搜索。
• 执行的 searches 可以通过 audit logs 追踪。
• Agent Mode 的部分 metrics 当前还不在 AI Usage Dashboard 里。
• Teach AI 是 beta 功能，可以让组织用 markdown 给 assistant 补充指导。

这个设计很成熟。Splunk 没有让 AI 直接随意执行搜索，而是把权限、成本、审计、管理员开关都放进了产品。

对国内厂商来说，AI RCA Agent 如果要调用日志查询、SQL、PromQL、TraceQL、执行脚本，也必须有类似机制：

• 只读动作和写动作分级；
• 高成本查询需要确认；
• 每次工具调用记录审计；
• 管理员能限制角色；
• 用户能看到和复用生成的查询；
• 支持组织级 prompt / policy / runbook 指导。

7. ITSI：Splunk 的传统 AIOps 和事件管理底座

Splunk IT Service Intelligence（ITSI）是 Splunk 在 AIOps 和 IT 运维服务健康上的核心产品。它对 RCA 的价值不在于生成式 AI，而在于把大量 alerts 组织成可处理的 operational episodes。

7.1 Event Analytics：先把告警风暴变成 episode

ITSI Event Analytics 会从整个 IT landscape 和其他监控孤岛摄取 events，提供统一的 operational console。它的核心对象是 notable event 和 episode。

Notable event 是 ITSI Event Analytics 的基础单元，可以来自 correlation search、anomaly detection 或 REST sources。Notable events 被送入 Rules Engine，生成 episodes 并触发 episode actions。

Episode 是一组去重、聚合后的 notable events，代表一个服务运行中断、事件序列或需要单独处理的问题。Aggregation policies 根据 similarity、过滤条件和规则把 notable events 聚成 episode，并支持 duplicate consolidation、alert suppression、clear event 自动关闭等动作。

这个设计非常适合 RCA 的上游。因为 RCA 如果直接面对告警风暴，很难有稳定输入。ITSI 先把海量告警压缩成 episode，相当于定义了 “要分析的问题单元”。

7.2 Episode Review：RCA 的人工工作台

Episode Review 是 ITSI 的事件处理界面。用户可以 triage episode、acknowledge、assign owner、change status、查看活动、评论、执行动作、创建外部工单。

在 episode 详情里，ITSI 提供多个和 RCA 相关的视角：

• Impact tab：查看受影响 services、KPIs、entities。
• Events Timeline：查看 episode 内各个 notable event 的时间顺序。
• Common Fields：查看 episode 内所有 events 共享字段和值。
• Similar Episodes：查历史相似 episode，了解过去如何解决。
• All Events：看 episode 内所有原始 notable events 和 severity timeline。

Events Timeline 里还专门有 “Sort for Root cause analysis” 的排序方式，它会按 first event occurred 排序，并标识第一个从正常变为异常的事件。这是一个很实用的产品细节：很多 RCA 不是先问 “哪个告警最严重”，而是先问 “哪个东西最先坏”。

Common Fields 也很有价值。它能帮助用户发现 episode 内多个事件共同拥有的字段，例如相同 host、service、region、instance、datacenter、alert type。这类共同字段往往比 AI 总结更直接。

7.3 Similar Episodes：组织记忆

Similar Episodes tab 可以查当前 episode 是否和历史问题相似，并查看当时如何解决。用户可以选择回看时间范围，也可以指定哪些字段用于相似性比较。

这是 RCA 产品里很重要的一环。真正的排障高手不是每次都从零推理，而是见过足够多类似事故。产品化的历史相似事件检索，就是把组织记忆放进一线响应流程。

国内厂商可以直接借鉴：AI RCA 不能只看当前指标日志，还要检索历史告警、历史故障、复盘、值班记录、工单、变更单。很多时候，历史相似事故比单次相关性分析更有用。

7.4 Event iQ：用 ML 自动生成事件关联策略

Splunk 在 ITSI 里推出了 Event iQ。官方文档说，Event iQ 使用 machine learning algorithms 比较字段值，把 notable events 关联成 episodes。它不是要求用户手写所有事件关联属性，而是分析历史事件数据，自动识别应该用于 grouping policies 的属性。

这解决的是 ITSI 类产品最大的落地问题之一：事件聚合规则很难配。

传统告警聚合通常要求用户知道：

• 哪些字段能代表同一个问题；
• 哪些字段不能用于聚合；
• 时间窗口多长合适；
• 哪些 alerts 应该合并；
• 哪些清除事件能关闭 episode；
• 哪些动作应该自动触发。

Event iQ 的产品思路是让 ML 帮用户找出历史事件中的关联字段，快速创建 event correlation policies，并持续调优。

这对国内厂商很有启发。告警降噪和事件聚合不能完全依赖人工配置，否则复杂客户环境很难成功。AI RCA 的第一步不是回答根因，而是把告警聚成正确的问题单元。

7.5 Episode Summarization

Cisco 在 2025-09-09 的 .conf25 新闻稿中提到，ITSI Episode Summarization 会结合 Event iQ 的 AI-driven alert correlation，自动提供 grouped alerts 的 overview，包括 trends、impact、root cause，帮助更快排障。

截至本次调研，公开帮助文档中能较明确查到 Event iQ、Episode Review、Similar Episodes、Root cause analysis timeline 等能力；Episode Summarization 的公开细节相对有限，需要以具体版本和销售说明为准。

产品方向上，这个功能很合理：ITSI 已经有 episode 和事件时间线，下一步自然是让 AI 自动总结 episode 的影响、趋势、可能根因和下一步动作。

8. AppDynamics：Cisco/Splunk 组合里的 APM RCA 资产

Cisco 收购 Splunk 后，Splunk 的可观测性组合里需要同时看 Splunk Observability Cloud 和 Splunk AppDynamics。

AppDynamics 的 RCA 路线和 Splunk Observability Cloud 不完全一样。它更偏传统/混合应用 APM，重点是业务交易、应用拓扑、异常检测和 suspected causes。

8.1 Automated RCA

AppDynamics 文档说，当 application entity 出现 anomaly 时，Anomaly Detection 使用 AI capabilities 做 Automated Root Cause Analysis，监控 application 内所有 entities 的健康，并展示每个 anomaly 的 suspected causes。

它的 RCA 分两部分：

1. Fault domain isolation：定位系统中问题发生的准确位置。
2. Impacted component analysis：分析 logs、snapshots、trace、infrastructure 等，确定受影响组件。

这个思路和 Splunk Observability Cloud 的 AI troubleshooting agent 有相似之处，都是先隔离 fault domain，再分析相关组件和证据。

8.2 Top Suspected Causes

AppDynamics 的 anomaly troubleshooting 文档里，Top Suspected Causes 会展示 Business Transaction 性能问题的可能根因。用户可以从 call paths 往上遍历 services、backend、cross-application、infrastructure machine entities。它会在 flow map 中高亮 suspected cause 所在路径。

文档也明确指出，可能出现 0 到 3 个 Top Suspected Causes。如果没有足够证据，系统不会强行给原因。这个边界非常重要。

它还区分 Top Deviating Metrics 和 Suspected Cause Metrics：

• Top Deviating Metrics 描述业务交易层面的异常，例如平均响应时间、错误率。
• Suspected Cause Metrics 描述更深层 tier 或 node 上的异常，例如某台机器内存使用率超过 expected range。

这实际上是一条证据链：业务交易变差 -> 拓扑路径 -> 某个 tier/node 异常 -> 某个指标偏离 expected range -> 验证是否是根因。

国内厂商做 RCA 时，也应该把用户体验做成这样的层次，而不是平铺所有指标。

8.3 AppDynamics + Splunk：日志和 APM 的上下文融合

Splunk 官方博客强调，AppDynamics 和 Splunk 的统一体验重点是 SSO、deep linking、保持 troubleshooting context。Log Observer Connect for AppDynamics 可以让用户从 AppDynamics 的 apps、tiers、nodes、business transactions、transaction snapshots 深链到 Splunk Enterprise / Cloud 里的相关日志，并保留时间范围和元数据。

官方博客里有一个很有意思的表达：AppDynamics 用 metrics、events、snapshots 告诉你 what、when、where，Splunk logs 帮你理解 why。

这个定位很清晰。AppDynamics 提供应用拓扑、业务交易和异常上下文，Splunk 提供日志分析深度。两者融合后，RCA 不再需要用户在多个工具里重复输入服务名、时间范围、trace id。

国内可观测性厂商同样需要重视 “跨工具上下文保持”。很多客户都有历史监控、APM、日志、CMDB、工单、网络监控多套系统。AI RCA 如果不能跨系统保持上下文，就会变成一个新的跳转负担。

9. Splunk 的产品设计逻辑

9.1 先定义问题单元，再做 RCA

Splunk 的 ITSI 和 Observability Cloud 都体现了这个原则。

在 ITSI 里，notable events 先被聚成 episodes；在 Observability Cloud 里，detectors 和 alerts 定义了需要调查的问题；在 AppDynamics 里，anomaly 和 Business Transaction 定义了异常对象。

这说明 Splunk 很清楚：RCA 不能直接对全量数据说 “给我找根因”。必须先有问题单元：

• 一个 alert；
• 一个 incident；
• 一个 episode；
• 一个 anomaly；
• 一个 business transaction；
• 一个 service latency spike；
• 一个 trace error。

国内厂商做 AI RCA 时，也应该先设计清楚 RCA 的输入对象。否则 AI 只能泛泛分析，无法稳定评估质量。

9.2 从 evidence-backed summaries 建立信任

Splunk 的 AI troubleshooting agent 强调 suspected root causes backed by evidence，Evidence tab 展示 logs、traces、services 等证据，action plan 也基于 trusted summaries。

这是 AI RCA 的正确方向。用户不需要 AI 讲玄学，需要可验证证据。

建议国内厂商在 UI 上固定展示：

• AI 结论；
• 支持证据；
• 证据来源；
• 时间范围；
• 相关实体；
• 置信度；
• 下一步验证；
• 可反馈按钮。

不要把 evidence 藏在模型思考里，也不要只展示一段自然语言。

9.3 AI 辅助一线响应，而不是替代专家

Splunk 的文档和博客都把 AI troubleshooting agent 描述成帮助 L1 analysts、SRE、AppDev/Ops、Service Owners 更快定位和协作。它不是说 AI 独立负责事故，而是让不同角色快速获得上下文。

这很务实。企业级 RCA 很少只有一个人解决。真正产品价值在于让：

• L1 支持知道是否升级；
• SRE 快速定位候选根因；
• 开发看到相关 trace/log/code clue；
• service owner 看到业务影响；
• ITSM 系统沉淀 ticket；
• 后续复盘能复用证据。

AI 应该降低协作成本，而不只是提升单人查询效率。

9.4 从排障到行动，但保留人类确认

Splunk remediation plan 会给命令和步骤，但让用户复制执行并提交结果。Agent Mode 执行搜索也需要用户明确许可。这体现了一个重要边界：AI 可以生成计划和查询，但高成本、高风险动作要让人确认。

这比 “自动修复一切” 更容易被企业接受。

9.5 通过 Cisco 组合补齐传统应用、网络和业务影响

Splunk Observability Cloud 偏云原生，AppDynamics 偏混合和传统应用，ThousandEyes 偏网络和第三方路径，ITSI 偏企业 IT 服务。Cisco/Splunk 的组合思路，是把 application、infrastructure、network、business transaction、end-user experience 统一起来。

AI RCA 的下一步竞争，很可能不是谁的聊天机器人更会说，而是谁拥有更完整的跨域上下文。

10. 产品亮点

亮点一：AI RCA 直接嵌在告警工作流

Splunk AI troubleshooting agent 的入口是 alert。Overview、Root Cause Analysis、Evidence、Action plan 都围绕告警组织。这比独立聊天框更符合一线响应流程。

亮点二：Evidence tab 把信任机制产品化

Splunk 没有只给一句根因，而是把 logs、exemplar traces、APM services 等证据列出来。这个设计对 AI RCA 非常关键。

亮点三：Remediation plan 做到了 “行动前一步”

它不是停在分析，也不是直接自动修复，而是给 hypothesis、root cause、步骤、命令和结果回填。这是企业接受度较高的过渡形态。

亮点四：ITSI 的 episode 模型成熟

ITSI 把事件聚合、去重、降噪、时间线、影响面、相似历史、外部动作做成了完整事件管理工作台。生成式 AI 可以叠在这个成熟模型上，而不是从零构建事故上下文。

亮点五：Event iQ 把告警聚合配置智能化

很多 AIOps 项目失败在规则配置成本太高。Event iQ 用 ML 分析历史事件，帮助自动生成 correlation policy，这比让用户手工写所有聚合规则更现实。

亮点六：SPL 和 SignalFlow 生成降低查询门槛

Splunk 用户大量依赖 SPL 和 SignalFlow。AI Assistant 能生成、解释、优化这些查询语言，是排障效率的基础提升。

亮点七：MCP Server 显示开放工具层思路

Splunk 不只把 AI 放在产品内，也通过 MCP server 把 metrics、APM、alerts 工具开放给外部 AI 工具。这是未来可观测性平台的关键方向。

亮点八：AppDynamics 补齐业务交易和传统应用 RCA

AppDynamics 的 Business Transaction、flow map、Automated RCA、suspected causes 对传统企业客户很重要。国内厂商如果只做云原生微服务，很容易忽略大量三层应用、SAP、混合部署和业务交易场景。

11. 折中和限制

折中一：产品线多，体验整合仍在进行

Splunk 有 Observability Cloud、Splunk Platform、ITSI、AppDynamics、On-Call、MCP、AI Assistant 等多条线。Cisco 收购后又引入 ThousandEyes 和 Cisco AI Assistant 方向。对客户来说，能力丰富，但也可能出现入口多、术语多、功能边界复杂的问题。

国内厂商可以借鉴 Splunk 的能力组合，但要避免把用户体验拆碎。AI RCA 最怕用户不知道该从哪个页面开始。

折中二：AI Troubleshooting Agent 当前覆盖范围有限

截至调研时，官方文档显示 AI troubleshooting agent and remediation plan 只在 us1 realm 开放，主要面向 APM services 和 Kubernetes in Infrastructure Monitoring，且只支持 standard/default metrics，不支持 custom metrics。

这说明真正可用的 AI RCA 需要高质量数据模型。自定义指标、复杂业务指标、非标准环境要支持起来更难。

折中三：AI Assistant in Observability Cloud 只支持英文

对全球产品可以接受，但对中国市场不够。国内客户需要中文告警、中文日志摘要、中文 runbook、中文 IM 协作和中文复盘。

折中四：成本和资源消耗需要显式管理

日志查询影响 SVC quota；Agent Mode search 会影响 consumption；非简单搜索需要用户授权；管理员需要用角色和 capability 限制高成本搜索。这些都是 AI RCA 产品必须面对的问题。

国内厂商如果不做成本控制，AI Agent 很容易把日志查询、PromQL、SQL、trace scan 打爆。

折中五：数据使用和合规边界复杂

Observability Cloud AI Assistant 使用用户 prompts、grounding observability data、assistant responses、feedback、usage data 等 essential data；可选是否允许用于 research and development，但 essential purposes 是使用该功能的前提。

Splunk AI Assistant for SPL 文档则强调私有公司数据不共享给 public AI/chatbot offerings，服务数据不发给第三方 LLM service providers，客户可选择退出训练/微调用途。

这说明不同产品线的数据处理机制并不完全一样。企业客户需要逐项确认数据是否出域、是否用于训练、是否可关闭、是否审计。

折中六：Agent Mode 仍有可观测性缺口

文档说明 Agent Mode 2.0.0 的部分 metrics 还不在 AI Usage Dashboard 里。对于企业 AI Agent 来说，agent 自身的可观测性非常重要：谁调用了什么、花了多少钱、执行了哪些 search、是否命中 guardrails、失败在哪里，都要能看。

折中七：相似事件和事件聚合依赖字段质量

ITSI Similar Episodes、Event iQ、Common Fields 都依赖事件字段、实体、服务、KPI、标题和属性质量。如果源头告警字段混乱，聚合和相似性分析效果会下降。

这再次说明 AI RCA 不能跳过数据治理。

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

1. 把 AI RCA 放进告警详情页

最值得直接借鉴的是 Splunk 的 alert-centric RCA。建议在告警详情页固定提供：

• Overview：告警摘要、影响面、触发规则、受影响对象。
• RCA：候选根因列表、优先级、证据摘要。
• Evidence：相关指标、日志、trace、拓扑、变更、历史事故。
• Action plan：下一步检查、命令、runbook、工单动作。
• Feedback：用户确认、否定、编辑、采纳结果。

不要让用户从空白聊天框开始。

2. 先做 “候选根因 + 证据”，不要宣称确定根因

Splunk 和 AppDynamics 都大量使用 suspected causes、hypotheses、evidence。国内产品应该少说 “根因已确定”，多说 “候选原因、证据、置信度、下一步验证”。

这更符合真实故障现场，也更容易建立信任。

3. 把事件聚合做成 AI RCA 的前置能力

ITSI 的 episode 模型很值得借鉴。国内厂商应该把 alert event 聚合成 incident/episode/problem，再对这个问题单元做 RCA。

核心能力包括：

• 告警去重；
• 相似告警聚合；
• 时间窗口聚合；
• 同服务/同主机/同集群聚合；
• 清除事件自动关闭；
• 事件时间线；
• common fields；
• similar incidents；
• 手工拆分/合并；
• 自动化动作。

没有这个前置层，AI RCA 会被告警风暴淹没。

4. 用 ML 自动推荐聚合规则

Event iQ 的方向很实际。国内厂商可以做：

• 分析历史告警，推荐聚合字段；
• 模拟聚合效果；
• 展示预期降噪率；
• 让用户确认后生成规则；
• 持续观察规则效果并建议调整。

这比让用户一开始就写复杂 AIOps 规则更容易落地。

5. 把日志、trace、指标的关联字段治理好

Splunk Related Content 和 Log Observer Connect 都强调上下文跳转和字段匹配。国内产品要让 AI RCA 好用，必须先保证：

• trace id 能串起日志和 trace；
• service.name、env、cluster、namespace、pod、host 等标签一致；
• deploy version、region、tenant、customer、endpoint 可用于过滤；
• 日志能按 trace/service/container 回跳；
• APM、infra、logs 共享实体模型。

没有这些，AI 只能做浅层总结。

6. 把 runbook 做成交互式 remediation plan

不要只让 AI 输出一段 “建议检查 CPU、重启服务”。可以做成步骤式计划：

• 假设 A；
• 为什么怀疑 A；
• 第一步执行什么查询；
• 预期输出是什么；
• 用户把结果贴回或系统自动执行只读查询；
• 如果结果满足条件，进入下一步；
• 否则切换到假设 B；
• 最后生成修复建议和复盘记录。

这比 “AI 自动修复” 更容易进入生产。

7. 对高成本/高风险动作做权限和审计

Agent Mode 的显式许可、角色限制、audit logs 很值得学。国内 AI RCA Agent 也应该区分：

• 免费/低成本工具调用；
• 高成本查询；
• 只读诊断命令；
• 写操作；
• 生产变更；
• 自动化修复。

越靠近生产变更，越需要权限、审批、审计、回滚和人类确认。

8. 让 AI 支持查询语言，而不是绕开查询语言

Splunk 的 SPL 和 SignalFlow AI 能力说明一个事实：企业用户不会因为 AI 出现就抛弃查询语言。更现实的是让 AI 帮用户写、解释、优化查询。

国内厂商如果有 PromQL、LogQL、SQL、TraceQL、自研 DSL，也应该做：

• 自然语言生成查询；
• 查询解释；
• 查询优化；
• 查询结果摘要；
• 查询安全检查；
• 查询成本预估；
• 一键打开原生查询页面。

9. 打通外部 AI 工具和 IM/IDE 入口

Splunk MCP Server 的路线值得提前布局。国内厂商可以提供：

• MCP server；
• 企业微信/飞书/钉钉 bot 工具调用；
• IDE 插件；
• 工单系统插件；
• 事故频道插件；
• 私有化大模型平台工具集成。

工程师排障不一定愿意打开监控控制台。可观测性平台应该成为 AI 工具的上下文提供者。

10. 重视传统企业和混合环境

AppDynamics 的存在提醒我们，很多大客户并不是纯云原生。传统 Java/.NET、三层应用、SAP、数据库、网络、第三方 API、on-prem 环境仍然很多。

国内厂商做 AI RCA 不能只围绕 Kubernetes 和微服务设计，也要考虑：

• 业务交易；
• 单体应用；
• 中间件；
• SAP/ERP；
• 数据库慢查询；
• 传统网络；
• 混合云；
• 数据中心；
• 网络和应用体验关联。

13. 总结：Splunk 的真正启发

Splunk 的 AI RCA 路线最值得借鉴的地方，是它没有把 RCA 简化成 “AI 问答”。它把 RCA 放在多个成熟产品对象上：

• Observability Cloud 的 alert；
• ITSI 的 episode；
• AppDynamics 的 anomaly 和 business transaction；
• Splunk 平台的 search；
• MCP 的 tool；
• remediation plan 的 action。

这背后的判断是对的：AI RCA 需要稳定的产品对象、结构化上下文和可追溯证据链。

对国内可观测性厂商来说，Splunk 的启发可以概括为几句话：

1. RCA 入口要在告警和事件页，而不是只在聊天框。
2. 根因要以候选假设和证据呈现，而不是神秘结论。
3. 告警聚合、事件时间线、相似历史，是 AI RCA 的前置基础。
4. Action plan 比自动修复更适合作为第一阶段。
5. 查询语言、工具调用、权限、成本、审计，是 Agentic RCA 的基本盘。
6. 未来可观测性平台要成为外部 AI 工具的上下文和工具层。

Splunk 的产品线很复杂，当前 AI 能力也不是所有场景都成熟可用。但它的方向很清楚：从 detection、investigation、root cause、remediation 到 business impact，用 AI 把运维工作流中的低效步骤压缩掉。国内厂商如果能把这个思路本地化到中文、私有化、混合云、国产中间件、企业 IM、工单和 CMDB 场景里，会比单纯做一个 “AI 运维助手” 更有竞争力。

参考资料

1. Splunk Docs: AI troubleshooting agent and remediation plan in Splunk Observability Cloud https://help.splunk.com/en/splunk-observability-cloud/create-alerts-detectors-and-service-level-objectives/create-alerts-and-detectors/ai-troubleshooting-agent-and-remediation-plan
2. Splunk Blog: Accelerate Resolution and Prevent Future Outages with Splunk Observability Cloud https://www.splunk.com/en_us/blog/observability/ai-troubleshooting-agent-in-splunk-observability-cloud
3. Splunk Docs: Splunk AI Assistant in Observability Cloud https://help.splunk.com/en/splunk-observability-cloud/splunk-ai-assistant/ai-assistant-in-observability-cloud
4. Splunk Docs: Prompt guide and library for AI Assistant in Observability Cloud https://help.splunk.com/en/splunk-observability-cloud/splunk-ai-assistant/prompt-guide-and-library-for-ai-assistant-in-observability-cloud
5. Splunk Docs: Interact with your observability data using the Splunk MCP server https://help.splunk.com/en/splunk-observability-cloud/splunk-ai-assistant/interact-with-your-observability-data-using-the-splunk-mcp-server
6. Splunk Docs: Related Content in Splunk Observability Cloud https://help.splunk.com/en/splunk-observability-cloud/data-tools/related-content
7. Splunk Docs: View dependencies in the service map in Splunk APM https://help.splunk.com/en/splunk-observability-cloud/monitor-application-performance/manage-services-spans-and-traces-in-splunk-apm/view-dependencies-in-the-service-map
8. Splunk Docs: Find the root cause of an error using Tag Spotlight https://help.splunk.com/en?resourceId=apm_apm-scenarios_troubleshoot-tag-spotlight
9. Splunk Docs: Use and manage Troubleshooting MetricSets https://help.splunk.com/en/splunk-observability-cloud/monitor-application-performance/analyze-services-with-span-tags-and-metricsets/learn-about-troubleshooting-metricsets/use-and-manage-troubleshooting-metricsets
10. Splunk Docs: About Splunk AI Assistant https://help.splunk.com/en/splunk-enterprise/search/splunk-ai-assistant
11. Splunk Docs: Agent Mode in Splunk AI Assistant https://help.splunk.com/en/splunk-enterprise/search/splunk-ai-assistant/2.0.0/use-splunk-ai-assistant/agent-mode-in-splunk-ai-assistant
12. Splunk Docs: Overview of Event Analytics in ITSI https://help.splunk.com/en/splunk-it-service-intelligence/splunk-it-service-intelligence/detect-and-act-on-notable-events/4.20/overview/overview-of-event-analytics-in-itsi
13. Splunk Docs: Investigate episodes in ITSI https://help.splunk.com/en/splunk-it-service-intelligence/splunk-it-service-intelligence/detect-and-act-on-notable-events/4.18/episode-review/investigate-episodes-in-itsi
14. Splunk Docs: Automate event correlation with Event iQ in ITSI https://help.splunk.com/en/splunk-it-service-intelligence/splunk-it-service-intelligence/detect-and-act-on-notable-events/4.21/event-correlation/automate-event-correlation-with-event-iq-in-itsi
15. Cisco Newsroom: Cisco Supercharges Observability with Agentic AI for Real-Time Business Insights https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2025/m09/cisco-supercharges-observability-with-agentic-ai-for-real-time-business-insights.html
16. Splunk Docs: What is Root Cause Analysis (RCA)? in AppDynamics https://help.splunk.com/en/appdynamics-saas/get-started/26.4.0/alert-and-respond/anomaly-detection/what-is-root-cause-analysis-rca
17. Splunk Docs: Troubleshooting Anomalies in AppDynamics https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/anomaly-detection/troubleshooting-anomalies
18. Splunk Product Page: Splunk AppDynamics https://www.splunk.com/en_us/products/splunk-appdynamics.html
19. Splunk Blog: Cisco builds a unified observability experience between AppDynamics and Splunk https://www.splunk.com/en-us/blog/observability/cisco-builds-a-unified-observability-experience-between-appdynamics-and-splunk.html
20. Splunk Blog: Introducing Log Observer Connect for AppDynamics https://www.splunk.com/en_us/blog/observability/log-observer-connect-for-appdynamics.html