一、

使用者痛点：告警出现后需要在日志网站、APM、链路追踪程序之间频繁切换；不同网站登录耗时、数据分散导致排查时间长；新人缺乏经验，不知道从何入手。

告警来了第一反应是打开日志网站搜关键词。切到 APM 看监控曲线，再去链路追踪程序找 trace 详情。三个网站来回切换，后来发现只是上游 GC 抖动导致的瞬间超时一分钟后就自愈了。这类告警排查通常需要 ～ 分钟主要耗时不在分析本身，而在于频繁登录不同网站、拼凑分散的数据。排查效率比较依赖个人经验，新人面对告警往往不知道该先看什么。于是我们做了 Troubleshooter——用 LLM Agent 自动完成告警的数据采集、根因分析和处置建议生成。上线后中位数排查耗时从 分钟左右 降到 分钟覆盖了 个服务 和 + 种告警类型。这篇文章是对技术方法的详细说。

二、架构设计

使用者痛点：告警接入与实际排查逻辑耦合导致程序 困难。按理说，

整体采用分层设计。主要原则是告警接入与排查执行解耦——接入层只负责接收和持久化，排查由独立的调度器异步触发。其实，

至于技术栈，

• Agent 框架选 Spring AI Alibaba 而不是自建 ReAct 循环。主要是省事——框架已内置推理循环、工具拦截器、模型拦截器，开箱即用。

三、主要流程

完整排查链路：

主要步骤说明：

• 告警接入接收告警数据，生成唯一事件 ID；
• 指纹生成提取 维度特征，生成 MD5 指纹；
• 知识匹配在知识库中检索相似记录，匹配成功则直接复用历史结论；
• AI 排查Supervisor Agent 编排排查，执行 ReAct 推理循环；老实说，
• 结论验收独立 Validation Agent 检查根因明确性和处置建议完整性；
• 知识沉淀运维确认后的结论存入知识库。

四、AI 排查引擎：ReAct Agent 实战

This is core of system. We use Spring AI Alibaba's 。which implements classic ReAct reasoning loop:

LLM 思考 → 选择工具 → 执行工具 → 观察结果 → 继续思考 → ... → 输出结论

SupervisorAgent：不是简单地调 Prompt

User Pain Point: 仅靠 Prompt 无法让模型获取实时监控数据和日志细节，需要外部工具支撑。

很多人以为「AI 排查」就是构造一个 Prompt 丢给大模型。但实际中，LLM 无法凭空知道你的服务当前 QPS 是多少、错误日志里写了什么、调用链哪个环节超时了。 它需要工具，

SupervisorAgent 的主要设计：

@Component
public class SupervisorAgent {
// 四个 @Tool 方法，暴露给 ReactAgent 框架
@Tool
public String queryLogs { ... }
@Tool
public String queryMetrics { ... }
@Tool
public String queryTrace { ... }
@Tool
public String queryEndpointErrors { ... }
// 执行排查的主要方法
public InvestigationResult investigate {
// 动态建立 instruction
String dynamicInstruction = buildDynamicInstruction;其实，// 建立 ReAct Agent
ReactAgent agent = ReactAgent.builder
.name
.model
.systemPrompt
.methodTools // 四个 @Tool 方法作为可用工具
.build;不过，// 验收循环：最多 N 次 LLM 内容重试
for {
AssistantMessage response = agent.call;// 结论验收
ValidationResult validation = conclusionValidationAgent
.validate。metricsQueried,eventId);if ) break，// 通过结束
// 不通过：将反馈注入 prompt，要 LLM 修正
currentPrompt = buildRetryPrompt);}
return InvestigationResult.complete,suggestion);}
}

四个排查工具的设计哲学

工具一的观点是。queryLogs——日志查询与分析

User Pain Point: 单纯搜索关键词会返回海量噪声，需要智能过滤与去重。

日志是排查的第一入口。它通过 WebSocket 连接日志网站。按优先级分批查询：

查询优先级: traceId> exceptionName> endpoint> keywords

每批结果都会经过 LLM 异步分析，最终汇总所有批次的结论。还有日志去重，防止同一请求的多条日志重复占据分析窗口。

说到工具二。queryMetrics——监控指标查询

User Pain Point: 运维人员往往不知道该查看哪些指标，就会盲目全量拉取导致延迟。不过，

支持  的指标查询：qps,rt,errorRate。containerCpu,containerMemory,percentileRt,gcCount,gcRt,qpstop10,rttop10。说起来，LLM 可以中环境代码不同——生产环境用 csprd‑proxy。测试环境用 t1‑proxy。

工具三的观点是，queryTrace——分布式链路追踪

User Pain Point: 没有统一视图时难以定位到底是哪一级调用出现异常。

从工具四来看。queryEndpointErrors——接口错误排查

User Pain Point: 缺少 traceId 时只能靠手工搜索接口错误日志，非常低效且易漏掉关键信息。

动态策略组装Differing services and alert types require different investigation logic. We designed a strategy‑matching mechanism: precise match on from DB;fallback to built‑in default when no match. Ops can edit strategies via UI without code changes.

instruction = ROLE + strategy + OUTPUT_FORMAT