提升 Instana 可观测性：通过多智能体事件调查解决故障问题
Instana 多智能体事件调查技术可自动化执行现代企业 IT 系统的根本原因分析，将故障解决时长从数小时缩短至数分钟。
用于事件调查的智能体式 AI 可自主开展根本原因分析与深度排查，精准定位引发事件的故障根源。Instana 可并行自动分析系统拓扑、分布式追踪、应用程序性能指标、日志及基础设施事件。
该技术支持多实体调查，即对相关服务与基础设施开展同步分析，通过协作式 AI 智能体实现智能体式 AI 事件调查与图形引导的根本原因分析 (RCA)，可在极少人工介入的前提下，更快、更精准地识别潜在根本原因。
我们通过一个具体案例了解该挑战的产生场景：
- 凌晨 2:30，FinTech Global 的高级站点可靠性工程师 (SRE) Alex 收到紧急告警：“检测到严重延迟 - 支付处理 API。”Alex 登录监控系统后，发现情况已十分严峻且令人担忧。
- 支付处理 API 的响应时间从 200 毫秒骤升至 3 秒以上。错误率已突破 5%，且仍在持续攀升。多个下游服务性能出现下降，多个区域已反馈客户受到业务影响。
- 财务团队测算，支付处理每中断一分钟，公司将因交易损失与客户好感度下降产生约 2 万美元的经济损失。
在传统事件响应流程中，Alex 需经历耗时漫长的调查过程。具体工作包括手动梳理数十个服务与 Kubernetes 工作负载、在多款可观测性工具的仪表板间切换、追踪调用图多层级链路的追踪与日志，还需尝试还原故障在系统中的传播路径。即便依托功能完善的可观测性平台获取全面遥测数据，关联所有信息并定位潜在根本原因的认知负担仍然较重，整个过程可能耗时数小时。
随着各组织尝试在可观测性技术栈之上部署通用大语言模型 (LLM) 智能体以加快事件响应速度，这一挑战愈发突出。
为什么通用 LLM 智能体无法解决这一问题？ReAct、“计划-执行”等主流智能体模式看似具备优势：可让模型自主决定查询内容、调用工具并构建推理过程草稿。但在站点可靠性工程与运维实际场景中，该模式暴露出三大核心难题：
上下文混乱
事件会产生海量数据，涵盖追踪、日志、指标、Kubernetes 事件及变更历史等。将所有数据一次性纳入单一上下文窗口的方式无法满足规模化需求。上下文不足会导致智能体遗漏关键线索，上下文过多则会掩盖有效信号，引发延迟与成本上升，同时削弱推理能力。
工具调用稳定性不足
让 LLM 自由调用工具可能会导致命令选择错误、参数（例如时间窗口、命名空间或筛选条件）不匹配导致实参不一致，以及重复或冗余调用（会使上下文膨胀并增加成本）。在多步骤调查中，这些问题会叠加，导致上下文碎片化，增加得出错误根本原因的可能性。
安全与可信度
在生产环境中，不能为 LLM 提供开放式 I/O 接口。SRE 需要可审计、可复现的推理过程：系统检索了哪些信息？系统为何判定该节点为根本原因？如果重新开展调查，是否会得到相同结论？换言之，事件处理并非简单的对话问题。这类问题属于图结构推理问题。
借助 Instana，工程师可采用全新处理方式
即便依托完善的可观测性平台，定位最可能的根本原因仍可能耗时数小时。在可观测性技术栈上“仅添加 LLM 智能体”的尝试，往往会因隐性问题而失败，例如上下文过载、工具调用不稳定，或是故障期间 SRE 无法信赖的模糊推理。
借助 IBM Instana，Alex 及其他可靠性工程师可采用全新方式处理问题。她在 Instana 中打开事件页面，滚动至“潜在根本原因”板块，点击“运行调查”。
数分钟内，AI 驱动的调查即可精准定位故障状态、引发事件的根本原因，并梳理出故障在系统中的传播路径。依托该诊断结果，组织可立即开展问题修复工作，显著缩短平均解决时间 (MTTR)。
现代系统可清晰呈现各类关联关系，包括服务间的相互调用、服务在容器、节点与集群上的运行状态，以及系统包含的配置映射、队列、数据库与外部依赖项。部署、配置推送、自动扩缩容等变更事件均可被追踪并关联呈现。
您可将其视作一张操作图，节点代表服务、Pod、主机、配置等实体，边缘代表调用、运行依赖、关联依托等关系。事件并非孤立的指标突增，而是故障随时间在该拓扑图中持续传播的结果。
核心转变在于，让系统拓扑、故障信息与因果算法引导智能体，以细分且明确的单元开展推理。这正是 Instana 智能事件调查功能的设计理念。
在事件视图中，Alex 这类用户可查看 Instana 通过因果 AI 识别出的潜在根本原因实体（请参阅详细博客），同时查看问题发生位置的应用程序与基础设施环境、展示受影响服务及依赖项的拓扑与影响范围、错误详情与延迟曲线图。
她无需手动切换多个仪表板，只需点击运行调查，结果便会实时呈现。
智能事件调查是一项多阶段、拓扑引导、由 LLM 辅助的新型工作流。
事件调查共分为四个步骤，首先分析因果 AI 整理的上下文事件数据，即 Instana 已识别的信息。其次开展变更事件分析，明确事件发生前后的变动内容。随后进行多实体调查，梳理故障的传播路径。最后生成 AI 报告，说明最可能的原因、相关证据与修复方案。
第 1 步：初始快照，锁定事件核心信息
Instana 从告警实体出发，在 Alex 的场景中为支付处理 API 与部分下游服务，结合当前潜在根本原因候选对象，以及包含上下游调用、基础设施层级关系、相关 Kubernetes 资源的本地拓扑开展分析。
系统不会将全部遥测数据输入模型，而是判断：“针对本次事件，应优先核查哪些实体与关联关系？”控制器将这些实体加入调查队列，依次获取限定上下文数据包，包括实体周边的局部拓扑片段，以及相关日志、追踪数据与指标。
第 2 步：变更事件分析，梳理近期系统变动
多数 SRE 会直观地提出疑问：“问题爆发前发生了哪些变更？”调查流程会自动完成该步骤，通过设定时间窗口，例如事件开始前 60 分钟至开始后 20 分钟，收集相关服务与基础设施的部署、配置变更、扩缩容事件等变更信号，筛选出与事件发生时间高度吻合的可疑变更。
Alex 无需手动翻阅部署记录、比对时间线，智能体调查引擎会自动完成关联分析。
第 3 步：多实体调查，追踪故障根源而非无关信息
这正是 Exploration Over Graph (EOG) 工作流让 Instana 精准定位故障的核心逻辑。系统会对调查队列中的每个实体调用工具、收集证据包，并判断该实体属于根本原因、故障表象，还是证据不足无法判定？相关证据是否表明故障沿特定边缘路径，例如从服务 A 至服务 B，或从配置错误的文件波及对应服务。系统随后更新因果子图，记录已确认的传播路径，例如 A 故障引发 B 故障，并将实体归类为根本原因、故障表象或排除对象。
Instana 负责队列管理，确保 LLM 仅处理聚焦的系统局部数据，同时保留可审计、可复现的推理说明。经过多轮迭代，AI 调查可定位根本原因，即支付网关服务中的连接池配置错误，追踪故障经支付处理 API 至所有下游服务的完整传播链，并提供可操作的修复步骤。
Instana 多智能体调查的价值不仅限于处理单个事件。通过自动关联拓扑、追踪数据、日志、指标与变更事件，Instana 将根本原因定位时间从数小时缩短至数分钟，直接降低平均解决时间 (MTTR)。对于运营高交易量服务的组织而言，故障每一分钟都会影响营收与客户体验，该项优化可直接创造商业价值。
SRE 团队可获取连贯且有证据支撑的事件说明，而非分散在多个仪表板中的原始遥测数据。完整的可观测性数据仍可用于后续深度调查，同时系统提供清晰的分析起点，省去数小时的手动关联工作。由于调查过程可审计、可复现，SRE 团队可验证 AI 结论，逐步建立对系统的信任。推理过程公开透明，明确核查的实体、收集的证据，以及判定特定节点为根本原因的依据。
AI 承担事件处理中耗时的关联工作后，SRE 团队可将精力投入主动可靠性建设，例如服务级别目标 (SLO) 管理、错误预算管控与混沌工程。从被动应急处置转向主动可靠性建设，可提升系统整体稳定性，减少重大事件的发生频次。
在 ITBench 这一 IT 自动化与事件任务基准测试套件的内部评估中，Instana 拓扑引导式调查方法生成的根本原因拓扑图更精准，排查弯路远少于传统 ReAct 模式 LLM 智能体，同时保持较小的上下文体量与可审计的行为逻辑。该验证结果表明，结构化拓扑引导模式相比通用 LLM 智能体模式，效果更优。
作为 AI 驱动的 Instana 智能事件调查功能与完整潜在根本原因分析流程的一部分，您可进入“Events”→“Incidents”页面，筛选包含潜在根本原因的应用程序智能告警，点击运行调查，启动 AI 驱动的多实体调查
随后您可查看实时更新的调查阶段、跨服务与基础设施的故障传播链，以及有证据支撑、可立即执行的修复建议。
感谢贡献者 Dishant Kaushik、Marc Palaci-Olgun、Shivangi Pathak、Chun-Wah Chung、Adwan Syed、Nevil Kandathil Sintho、Melissa Denby、Paul Watkins 与 Gopika Murali K。