前言在互联网后端运维工作中线上告警排查是工程师的日常核心工作之一。绝大多数开发者和运维人员都有过这样的真实体验收到线上告警后需要轮番切换日志平台、APM监控系统、链路追踪平台多个工具反复搜索关键词、查看监控曲线、核查调用链路详情。往往耗时十几二十分钟最终却发现只是上游服务GC抖动引发的瞬时超时问题早已自动自愈。这类无效且低效的排查场景在日常运维工作中比比皆是。常规告警排查的耗时基本集中在10分钟至30分钟真正用于分析故障根因的时间少之又少大部分时间都浪费在跨平台登录、数据拼凑、信息整合等机械操作上。除此之外传统告警排查极度依赖人员经验。资深运维人员可以快速锁定排查方向新人却常常无从下手不知道优先核查哪些指标、检索哪些日志团队整体排查效率参差不齐故障处理标准化程度极低。针对这些行业痛点得物技术团队自研了Troubleshooter智能告警排查系统依托LLM Agent技术重构传统运维告警排查流程。这套系统可以自动完成告警数据采集、智能根因分析、标准化处置建议生成彻底替代人工机械排查工作。系统上线后业务告警中位数排查耗时从20分钟压缩至4.4分钟成功覆盖11个核心服务以及十余种常见告警类型极大提升了运维工作的标准化、智能化水平。本文将完整拆解这套系统的架构设计、核心流程、技术落地细节、实战案例以及迭代思考。一、整体架构设计实现解耦式智能排查为了保障系统的稳定性和可扩展性Troubleshooter整体采用分层架构设计核心设计原则是实现告警接入与排查执行的完全解耦。简单来说接入层仅负责接收、校验、持久化告警数据不参与任何排查逻辑具体的故障排查工作由独立的调度器异步触发执行这种设计可以有效避免告警接入拥堵影响排查任务保障两大流程独立高效运行。1.1 核心技术栈选型逻辑在Agent框架的选型上团队最终选择了Spring AI Alibaba并未采用自研ReAct循环框架。核心原因是贴合业务落地需求追求高效稳定落地。Spring AI Alibaba框架已经内置了完整的推理循环、工具拦截器、模型拦截器等核心能力开箱即用无需团队从零开发基础核心能力大幅降低了开发成本和试错成本。同时框架兼容性强能够完美适配各类大模型接口和自定义工具完全满足运维排查场景的个性化需求。二、全链路排查流程构建标准化运维体系Troubleshooter设计了一套闭环的智能告警排查链路从告警接入到知识沉淀形成完整循环既实现了单次故障的高效处理也能持续积累运维经验让系统越用越智能。整套流程分为七大核心步骤层层递进、逻辑闭环。2.1 七大核心排查步骤第一步是告警接入。系统实时接收各类业务服务的告警数据同时为每一条告警生成唯一事件ID作为本次排查任务的唯一标识方便后续日志追溯、进度追踪和结果复盘。第二步是指纹生成。系统会智能提取五大维度的告警核心特征包含服务名、告警类型、错误模式、指标名、错误摘要基于这些特征生成32位MD5指纹。该指纹是后续相似告警匹配的核心依据能够精准区分不同类型的故障场景。第三步是知识匹配。系统会携带生成的告警指纹在运维知识库中检索历史相似故障记录。如果匹配到高度相似的历史告警会直接复用过往的根因结论和处置方案实现秒级故障响应无需重复排查。第四步是AI智能排查。这是整套流程的核心环节由Supervisor Agent统一编排排查任务持续执行ReAct推理循环调用各类排查工具采集数据逐步推导故障根因。第五步是结论验收。系统配备独立的Validation Agent专门负责校验AI生成结论的质量重点核查根因是否清晰明确、处置建议是否完整可落地杜绝无效、模糊的排查结果。第六步是报告推送。验收通过后系统自动生成标准化Markdown格式排查报告包含故障概况、根因分析、影响范围、处置建议等内容直接推送至对应飞书运维群组同步告知运维人员。第七步是知识沉淀。运维人员确认排查结论准确无误后本次故障的完整排查数据会自动存入系统知识库丰富故障案例库为后续相似告警快速匹配提供数据支撑。三、核心AI排查引擎ReAct Agent实战落地细节AI排查引擎是Troubleshooter系统的核心核心直接决定故障排查的准确率和效率。系统基于Spring AI Alibaba的ReactAgent实现经典ReAct推理循环核心逻辑为大模型思考、选择排查工具、执行工具调用、观测返回结果、持续迭代思考循环往复直至推导出准确的故障结论。3.1 Supervisor Agent打破简单Prompt调用误区在AI运维排查的落地误区中很多团队认为AI排查就是编写固定提示词直接调用大模型获取结果。但实际线上场景中大模型无法主动获取服务实时QPS、接口响应耗时、具体错误日志、链路异常节点等实时线上数据单纯依靠静态提示词根本无法完成精准排查。因此得物团队设计了Supervisor Agent核心是通过自定义工具赋能大模型让AI可以自主调用各类运维平台接口采集真实线上数据基于实际数据完成推理分析。以下是核心代码实现Component public class SupervisorAgent{ // 四个 Tool 方法暴露给 ReactAgent 框架 Tool(description 查询并分析应用日志返回排查摘要) public String queryLogs(String serviceName, Integer minutes, ...){ ... } Tool(description 查询服务监控指标QPS/RT/错误率/CPU/内存/GC) public String queryMetrics(String serviceName, String metricTypes, ...){ ... } Tool(description 通过 traceId 查询分布式调用链详情) public String queryTrace(String traceId){ ... } Tool(description 无 traceId 时通过接口路径查询错误日志并提取 traceId) public String queryEndpointErrors(String serviceName, String endpoint, ...){ ... } // 执行排查的核心方法 public InvestigationResult investigate(TroubleEvent event){ // 1. 动态构建 instruction策略匹配 or 兜底策略 String dynamicInstruction buildDynamicInstruction(event); // 2. 构建 ReAct Agent ReactAgent agent ReactAgent.builder() .name(supervisor) .model(selectedModel) .systemPrompt(dynamicInstruction) .methodTools(this) // 四个 Tool 方法作为可用工具 .build(); // 3. 验收循环最多 2 次 LLM 内容重试 for (int attempt 0; attempt maxRetries 2; attempt) { AssistantMessage response agent.call(currentPrompt); // 结论验收 ValidationResult validation conclusionValidationAgent .validate(responseText, metricsQueried, eventId); if (validation.isPassed()) break; // 通过结束 // 不通过将反馈注入 prompt要求 LLM 修正 currentPrompt buildRetryPrompt(feedback, responseText); } return InvestigationResult.complete(responseText, suggestion); } }Supervisor Agent的核心执行逻辑分为三步首先会根据当前告警事件动态构建专属指令匹配对应服务和告警类型的排查策略无匹配策略则使用系统兜底策略。其次基于动态指令构建ReAct Agent将四大排查工具注入框架供大模型自主调用。最后开启多轮验收重试机制最多支持2次内容重试确保排查结论合规准确。3.2 四大核心排查工具设计全覆盖运维排查场景为了适配全场景线上故障排查系统设计了四类核心排查工具覆盖日志、监控、链路、接口错误四大排查维度完美复刻人工排查的完整思路。工具一为日志查询分析工具queryLogs。日志是故障排查的第一优先级依据该工具通过WebSocket连接日志平台按照固定优先级分批查询数据查询优先级依次为traceId、异常名称、接口路径、业务关键词。每一批查询结果都会由LLM异步分析最终汇总所有批次的结论。同时内置LogDeduplicator日志去重能力过滤同一请求产生的重复日志避免冗余数据干扰AI分析。工具二为监控指标查询工具queryMetrics。该工具支持十大核心运维指标查询包含QPS、响应耗时RT、错误率、容器CPU、容器内存、百分位RT、GC次数、GC耗时、TOP10慢请求等。大模型可以根据不同告警类型自主选择需要查询的指标维度实现精准数据采集。比如OOM内存溢出告警AI会主动查询CPU、内存、GC、QPS、RT等全维度指标而接口响应超时告警则重点关注耗时、慢请求、QPS波动等核心数据。同时工具支持多环境可插拔适配区分生产、预发、测试等不同环境的接口参数适配不同平台的查询规则。工具三为分布式链路追踪工具queryTrace。如果告警信息携带traceId该工具可直接调用APM平台接口获取完整Span调用树将结构化的链路数据转化为通俗易懂的文本信息交付给LLM分析能够精准识别下游依赖服务卡顿、接口异常报错、链路耗时堆积等核心问题。工具四为接口错误排查工具queryEndpointErrors。针对无traceId但明确接口路径的告警场景该工具可以检索对应接口的所有错误日志通过正则表达式批量提取有效traceId再逐一完成链路分析。同时设置了关键防护机制若接口路径为根路径则直接拒绝执行避免全量请求查询带来的无效排查和性能损耗。3.3 动态策略与超时隔离保障系统稳定运行不同服务、不同告警类型的排查思路存在极大差异固定排查逻辑无法适配多样化场景。为此系统设计了动态策略组装机制通过服务名加告警类型的组合维度从数据库精准匹配专属排查策略无匹配数据时自动启用内置兜底策略。运维人员可通过前端页面在线编辑策略内容无需修改代码即可完成排查逻辑迭代灵活性极高。最终的AI指令由角色定位、专属排查策略、输出格式要求三部分动态拼接而成。同时为了避免外部平台接口异常导致排查任务中断所有工具调用都做了超时隔离处理。通过独立线程池结合超时时间控制单个工具执行超时或报错时会返回标准化降级提示不会终止整体排查流程LLM可基于已有数据继续推导结论最大限度保障排查任务的完整性。核心超时控制代码如下public ToolResult executeWithTimeout(Tool tool, MapString, Object parameters){ FutureToolResult future executor.submit(() - tool.execute(parameters)); try { return future.get(tool.getTimeoutSeconds(), TimeUnit.SECONDS); } catch (TimeoutException e) { future.cancel(true); return ToolResult.timedOut(工具执行超时继续使用已有信息进行排查); } catch (ExecutionException e) { return ToolResult.failed(工具执行失败: e.getCause().getMessage()); } }四、多层级幻觉控制保障AI排查结论质量大模型落地运维场景最大的痛点就是输出不稳定、易产生幻觉结论出现无依据定根因、虚假处置建议等问题。为了解决这一核心问题得物团队搭建了四层幻觉控制体系从格式、内容、证据、重试四个维度严格校验输出结果彻底规避无效结论。4.1 零LLM格式规则校验系统首先执行毫秒级规则校验无需调用大模型仅通过代码逻辑检查结论规范性。核心校验两项内容一是核查排查报告是否包含五大必备章节缺失任意模块直接判定校验失败。二是如果本次排查调用过指标查询工具报告必须附带标准化指标数据表格确保结论有数据支撑。核心校验逻辑如下private ValidationResult checkFormat(String conclusion, boolean hasMetricsQuery){ // 检查 5 个必要章节 for (String[] keywords : REQUIRED_SECTIONS) { if (containsSection(conclusion, keyword)) found true; else missingItems.add(缺少章节「 keywords[0] 」); } // 如果调用过 queryMetrics必须有指标表格 if (hasMetricsQuery !METRIC_TABLE_PATTERN.matcher(conclusion).find()) { missingItems.add(缺少指标数据表格); } }4.2 独立Agent内容质量审核通过格式校验后Validation Agent会深度审核结论内容重点核查四项核心标准分别是故障根因是否明确无歧义、核心判定逻辑是否合理、所有结论是否都有工具采集的真实数据支撑、处置建议是否具体可落地。从内容层面杜绝AI幻觉问题。4.3 多工具交叉验证为了避免单一工具数据偏差导致误判系统设置了多维度交叉验证机制。日志分析结果需要和链路追踪数据相互印证日志报错信息需要和监控指标波动保持一致同时严格校验故障时间线的统一性只有多源数据达成共识才能最终确定故障根因大幅提升排查准确率。4.4 分级重试容错机制系统制定了合理的重试规则格式类问题不消耗重试配额直接自动修正。内容不合理、证据不足等核心问题最多允许2次LLM重新生成。若验收Agent出现异常系统会宽容放行避免正常故障排查任务因校验异常被阻断平衡了结论质量和排查效率。五、全流程可观测告别AI排查黑盒传统AI排查最大的问题是流程不透明无法追溯AI的思考过程和工具调用记录出现问题难以复盘优化。Troubleshooter搭建了双层可观测体系通过文件系统日志和内存进度追踪让每一步排查动作都清晰可见。5.1 精细化文件日志记录系统会为每一条告警事件在文件系统中创建独立的日志目录以唯一事件ID区分完整记录从告警接入到结论输出的所有流程。日志分类清晰包含原始告警信息、接入记录、LLM系统指令、用户提示词、每一次大模型调用结果、各类工具执行日志、验收日志、最终排查结论等完整内容方便运维人员深度复盘问题。5.2 实时内存进度追踪系统通过EventProgressTracker在内存中实时维护每个排查事件的状态包含当前排查阶段、正在执行的策略、工具调用进度等信息。前端页面通过3秒轮询的方式同步数据运维人员可以实时查看AI排查进度无需被动等待结果输出提升运维感知度。六、真实生产案例直观展现排查效率提升以得物生产环境一次效率网关超时告警为例完整展示Troubleshooter的智能排查能力直观对比人工排查与AI排查的效率差距。6.1 告警基础信息本次告警服务为效率网关告警类型是业务应用30秒内接口异常告警严重级别为P4发生在生产环境涉及接口路径为自定义后台列表查询接口告警无自带traceId属于典型的无链路线索的疑难告警。6.2 AI完整排查过程Supervisor Agent全程耗时4分钟左右完成3次工具调用和1轮验收修正。首次排查完成后验收检测出报告缺失必填字段判定不通过系统将验收反馈注入提示词触发LLM二次优化输出。第二次验收完全通过报告补充了完整的结构化信息最终判定故障紧急程度为观察结论置信度为高。6.3 最终标准化排查结论本次告警核心原因是舆情管理端服务底层gorm-v2数据库查询出现严重阻塞导致效率网关触发30秒硬性超时属于特定多条件过滤场景下的偶发性慢查询引发的链路中断。从判定依据来看告警窗口内仅出现2次错误请求服务整体QPS、响应耗时、错误率等核心指标均正常无大规模异常属于偶发个案。同时分布式调用链清晰显示99%的请求耗时集中在gorm-v2数据库组件网关超时堆栈、响应流中断机制与业务多条件过滤SQL场景完全匹配结论可信度极高。具体根因为舆情管理端列表查询接口在执行多状态过滤加分页查询时底层数据库组件执行阻塞单条请求耗时达到29.99秒逼近网关30秒超时阈值最终触发超时异常。本次故障影响范围有限仅影响前端舆情升级列表查询功能30分钟内仅2次请求失败未引发服务级联故障业务整体运行正常。系统同步输出三条可落地的处置建议一是核查该接口慢查询日志补充缺失的复合索引优化查询效率。二是调整网关对应路由的超时参数新增降级兜底策略。三是评估复杂多条件查询的业务合理性采用异步查询、分批拉取的方式优化接口性能。本次AI排查总耗时4分钟包含工具调用耗时、LLM推理和结论验收时间。如果采用人工排查运维人员需要依次切换APM、日志、链路平台逐一核查数据至少需要10至20分钟AI将本次排查效率提升了数倍。七、落地难点与技术优化方案在系统落地过程中团队遇到了环境标识混乱、大模型接口限流两大核心问题通过针对性优化彻底解决了线上适配难题。7.1 多环境标识统一映射线上不同系统的环境标识命名极不统一生产环境存在十余种别名且日志平台和APM监控平台的环境参数规则不一致极易导致工具查询数据出错。为此团队通过配置文件集中管理所有环境别名映射关系覆盖生产、预发、测试等5套环境支持精确匹配和模糊包含匹配。同时固定工具层的环境参数转换逻辑不让大模型自主识别翻译环境名彻底规避环境匹配错误的问题。7.2 大模型多Key轮询限流优化大模型网关存在单API Key调用频率限制系统高频排查场景下容易出现限流报错。团队自研RoundRobinChatModel负载均衡机制支持配置多个API Key通过事件ID哈希取模固定分配密钥。同一次排查任务的所有LLM调用会复用同一个密钥避免上下文切换同时分散调用压力彻底解决高频限流问题。八、落地效果数据全方位提升运维能力团队统计了系统上线后24天的运行数据从排查效率、结论质量两个维度充分验证了系统的落地价值。排查性能方面告警中位数排查耗时从20分钟降至4.4分钟大幅降低运维人力成本彻底解放人工机械排查工作。结论质量方面AI排查结论首次验收通过率约60%经过一轮修正后的二次通过率约38%仅有2%的极端场景需要兜底处理整体有效准确率达到98%完全满足线上运维使用需求。九、未来迭代规划打造全链路智能运维体系当前Troubleshooter系统已实现告警智能排查和建议输出后续团队将围绕并行排查、智能匹配、自动处置等方向持续迭代进一步提升运维智能化水平。首先是实现多Agent并行排查将日志查询、指标查询等独立工具任务并行执行进一步压缩排查耗时。其次是完善指纹知识库优化相似问题匹配逻辑实现已知问题秒级响应。第三是新增跨服务关联分析能力主动识别服务级联故障精准定位故障源头而非表象。同时团队将推进自动处置能力建设让系统从单纯的排查建议升级为排查加自动修复的全流程能力。最后引入向量语义检索技术摆脱传统指纹精准匹配的限制实现语义级相似故障检索提升未知故障的排查能力。结语Troubleshooter智能告警排查系统的核心价值并非替代运维工程师而是将运维人员从跨平台切换、数据拼凑、经验试错等重复机械的工作中解放出来。让AI承接标准化、流程化的故障排查工作让运维人员专注于故障根因深度优化、架构优化、风险防控等需要深度思考和创新的核心工作。LLM Agent在运维场景的落地是传统运维向智能化运维转型的关键一步。得物技术团队的这套落地方案解决了大模型落地运维场景的幻觉问题、稳定性问题、适配性问题为行业AI运维落地提供了可复用、可参考的实战思路。未来随着技术持续迭代智能化运维将覆盖更多场景彻底重构传统运维工作模式。