1. 告警排查的现状与痛点在分布式系统运维中告警排查一直是让工程师头疼的问题。每次收到告警通知工程师需要像侦探一样在日志系统、监控平台、链路追踪工具之间来回切换手动拼凑线索。根据得物技术团队的实测数据单次告警排查平均耗时10-30分钟且结果高度依赖个人经验——新手和老手排查同一问题的效率可能相差数倍。这种传统方式存在三个致命缺陷信息碎片化关键数据分散在不同系统需要人工关联分析。比如一个API延迟告警可能需要同时查看Prometheus的指标、ELK的日志和SkyWalking的调用链才能定位到是某个数据库查询出了问题。经验不可复制资深工程师的排查思路往往存在大脑里团队难以沉淀和复用。当人员变动时排查效率会明显下降。响应延迟人工操作存在物理极限在凌晨告警时尤为明显。我曾经历过一个真实案例一个简单的磁盘空间告警因为值班人员睡过头导致服务不可用2小时。2. LLM Agent的技术选型逻辑2.1 为什么选择LLM Agent传统自动化方案如规则引擎在告警排查中早已有应用但它们存在两个根本局限规则维护成本高每新增一种告警类型就需要编写新的规则。在微服务架构下服务迭代频繁规则库很快就会变得臃肿不堪。泛化能力差无法处理规则库未覆盖的长尾问题。而实际生产中真正造成严重影响的往往就是这些异常场景。LLM Agent的核心优势在于自然语言理解可以直接处理非结构化的日志和告警信息推理能力能模仿人类工程师的排查思路逐步缩小问题范围零样本学习对未见过的告警类型也能给出合理推测2.2 架构设计关键点得物技术的Troubleshooter采用分层架构设计这是经过多次迭代验证的最优方案[告警输入层] ↓ [数据采集层] ←→ 日志系统/APM/监控平台 ↓ [推理引擎层] ←→ LLM Agent集群 ↓ [行动执行层] → 自动修复/人工介入每层设计都有其深思熟虑数据采集层使用适配器模式统一不同数据源的访问接口。我们在实践中发现约70%的排查时间其实花在数据收集上。推理引擎层采用小模型(7B参数)与大模型(70B参数)协同工作小模型处理简单问题大模型攻坚复杂场景这样平衡成本与效果。行动执行层设置人工确认环节避免自动修复引发二次事故。这是用血的教训换来的设计——曾经有个Agent误判导致批量重启服务。3. 核心实现细节揭秘3.1 数据预处理的关键技巧原始日志和监控数据不能直接喂给LLM需要经过精心处理时间对齐将不同系统的数据按精确到毫秒的时间戳对齐。我们开发了时间漂移补偿算法解决各系统时钟不同步问题。噪声过滤使用正则表达式启发式规则去除无关日志。例如过滤掉健康检查请求、心跳日志等干扰信息。关键信息提取通过NER模型识别IP、traceId、错误码等实体这些是后续关联分析的关键。一个实际的处理示例def preprocess_log(raw_log): # 移除颜色代码 clean_log re.sub(r\x1b\[[0-9;]*m, , raw_log) # 提取关键字段 entities ner_model.predict(clean_log) # 标准化时间格式 std_time convert_time_format(entities[timestamp]) return { timestamp: std_time, service: entities[service_name], trace_id: entities[trace_id], content: clean_log }3.2 提示词工程实战LLM的表现高度依赖提示词设计。经过数百次测试我们总结出告警排查的最佳提示结构角色设定明确告知模型它是一名资深SRE工程师排查步骤要求模型按照现象描述→可能原因→验证方法→结论的流程思考工具说明列出可用的数据源及其查询方式输出格式规定必须包含置信度评分和证据引用示例提示词片段你是一名有8年经验的SRE专家正在处理一个生产告警。请按照以下步骤分析 1. 首先描述观察到的异常现象 2. 列出3-5个最可能的根本原因按可能性排序 3. 对每个原因说明需要查看哪些数据来验证 4. 最终给出最可能的根因及置信度(0-100%) 可用数据源 - 日志系统/search?query... - 指标监控/graph?q... - 链路追踪/trace/... 请用JSON格式回复包含analysis_steps和conclusion字段。4. 落地效果与优化历程4.1 性能指标变化上线三个月内的关键指标对比指标人工排查LLM Agent提升幅度中位耗时20min4.4min78%↓准确率85%92%7%↑24/7可用性60%99.9%39.9%↑新人上手时间2周2天86%↓特别值得注意的是对于复杂分布式事务问题Agent的表现反而优于人类。因为它能同时追踪数十个微服务的状态变化这是人脑难以做到的。4.2 遇到的典型问题在落地过程中我们踩过几个值得分享的坑幻觉问题早期版本会虚构不存在的日志条目。解决方案是在最终结论前增加证据校验步骤要求Agent必须引用具体的数据点。长上下文丢失当分析需要跨越很长的日志时模型会忘记前面的内容。我们通过以下方法缓解分段摘要每处理100行日志生成一个摘要关键信息缓存单独存储重要实体如error_code递归总结像人类做笔记一样层层抽象供应商API限流曾因集中调用导致LLM服务被限流。现在采用本地小模型优先请求队列指数退避多供应商故障转移5. 进阶优化方向当前系统仍有改进空间我们正在尝试以下方向多模态分析除了文本日志也开始处理图表形式的监控数据。使用CLIP等模型将曲线特征转化为文字描述再交给LLM分析。实时流处理现有方案是定时批处理下一步要实现from kafka import KafkaConsumer consumer KafkaConsumer(alerts) for msg in consumer: process_alert(msg.value)知识库增强将历史排查案例向量化存储遇到类似问题时快速检索参考。这相当于给Agent装了个经验存储器。验证沙盒为防止自动修复出错正在构建一个隔离环境让Agent的修复方案先在其中试运行。通过对比修复前后的监控指标变化评估方案有效性。