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 | 提升幅度 |
|---|---|---|---|
| 中位耗时 | 20min | 4.4min | 78%↓ |
| 准确率 | 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的修复方案先在其中试运行。通过对比修复前后的监控指标变化，评估方案有效性。
