三年前我第一次被凌晨3点的电话叫醒原因是某个不太重要的服务发了条探活失败告警等我打开电脑准备处理时它已经自己恢复了。那会儿我就在想告警系统到底是在帮我们发现问题还是在制造更多问题。后来接手值班体系、做告警治理又深入到用大模型做告警摘要与关联分析踩了不少坑也总结了一些真正可落地的经验。这篇就围绕“让 AI 帮你读告警”这件事聊聊大模型摘要、关联分析和值班助手的实际落地边界哪些场景是真提效哪些场景是伪需求以及我自己在实践中用的具体方法和参数。1. 先说一个真实痛点告警不是太少而是太多、太碎、太没上下文在大模型介入之前告警处理的现状可以用三个词概括噪声高、上下文少、协作成本大。我见过很多团队的告警群一天下来上千条消息值班同学真正点开看的可能不到10%而这10%里又有相当一部分是“看一眼不知道发生了什么得去翻监控大盘、看日志、查发布记录”才能勉强定位。等定位完反应时间早就过了SLO红线。这里先定义清楚一个概念告警不等于故障更不等于根因。告警只是“某个指标超过阈值”或“某个事件被触发”的信号它缺少的是上下文——这条告警影响谁、和哪些其他告警相关、最近的变更是什么、历史上有没有出现过。传统告警系统擅长的是“检测与通知”不擅长“解释与关联”。所以我们要引入大模型目标很明确把告警从“信号”变成“可读的线索”把值班同学从“人肉查上下文”里解放出来。但这里有一个非常重要的边界——大模型能做的是增强人的判断而不是替代人的决策。我建议你先用一张表梳理自己团队告警处理的现状环节原始状态痛点大模型可能的介入点告警接收群里刷屏噪声淹没真正的故障聚类、摘要、降噪排序告警理解人工点开看详情缺乏上下文看不懂生成告警解释、关联变更与日志告警关联靠人脑记忆或规则跨系统关联困难时序/语义/拓扑关联分析响应决策值班人拍脑袋历史经验依赖个人推荐处理预案、相似历史案例事后复盘手工写报告耗时且遗漏多自动生成时间线简报有了这张表你会发现大模型不是替代某个岗位而是在“理解与关联”这两个环节做增强。2. 大模型摘要告警不是翻译告警内容而是压缩噪声并补充上下文2.1 摘要的本质把百条告警变成三段话很多人一开始做大模型告警摘要做法是把Alertmanager推送过来的告警列表直接丢给LLM让它“总结一下”。结果往往很失望——模型确实总结出来了但总结的内容和你自己扫一眼看到的信息差不多甚至因为过度概括丢了关键异常指标。我踩了这个坑之后重新梳理了告警摘要的目标。告警摘要不是“翻译”每条告警在说什么而是要回答三个问题当前发生了什么、影响范围是什么、最值得关注的点在哪里。这需要摘要系统具备两方面的能力一是剔除重复与已知噪声二是把多个孤立告警放在同一个上下文里做归纳。以Alertmanager为例它的webhook Payload里包含alert name、labels、annotations、status、startsAt等字段。直接把这个JSON原样丢给LLM有两个问题第一是token浪费比如一个Prometheus告警的labels可能带了一堆环境标签对摘要毫无意义第二是上下文污染模型容易把噪声信息也当成重点。我最终的做法是先做结构化规整再让模型生成摘要。第一步把原始告警按告警名、实例、严重级别做一次预聚类聚类逻辑可以直接复用Alertmanager的group_by配置确保同一批告警是逻辑相关的。第二步对聚类后的告警做关键字段抽取只保留时间戳、告警级别、告警名、实例列表、核心异常值其余全部丢掉。第三步把规整后的数据塞给LLM用一段我反复调过的提示词核心是强制模型按固定结构输出不做无依据推断。这是我在生产环境用的一段提示词框架你是一名SRE值班助手请基于以下告警数据生成简报。 要求 1. 只陈述数据中可确认的事实禁止推测原因。 2. 按“发生了什么事”“影响范围”“建议优先处理的告警”三个维度组织。 3. 如果存在同一实例的同类告警合并说明并在末尾标注“重复次数”。 4. 单条告警描述不超过50字全文不超过300字。 5. 保留关键数值指标阈值、当前值、实例数量。 以下为告警数据 【告警数据】使用这段提示词有几个细节需要注意。第一是必须明确指定“禁止推测原因”否则LLM会基于有限信息自行脑补因果这在告警场景尤其危险它可能会把一条网络抖动告警“推断”为上游业务代码问题。第二是给模型一个固定的输出结构比让它自由发挥要可靠得多也方便后续自动化解析。第三是必须让模型输出结构化标记方便程序做后续处理。2.2 摘要的常见失败模式幻觉、旧闻、错位对接大模型摘要之后我总结过三类典型的失败模式这里说给正要上的人参考。第一类是幻觉型错误。表现是模型给出了告警数据里不存在的“根因分析”比如根据一条CPU使用率高就“分析”出可能是死锁或者内存泄漏。这在我们的人工复核中很容易被识别但如果你把它接入自动通知渠道就会成为误导。解决办法就是我在上节提到的提示词里严格禁止推断必要时可以在系统层面加一道过滤器检测输出里是否包含“可能”“或许”“大概率”这类推测词一旦出现就降级为只展示原始数据。第二类是旧闻型错误。告警是持续刷新的上一轮摘要可能刚生成新一轮告警又进来了。如果你的摘要任务是基于多批告警合并生成的模型可能会重复描述旧的告警状态让值班同学以为故障还在持续实际上早已恢复。我在实践中会对摘要任务传入时间窗口参数只统计窗口内的告警窗口外的历史数据不进模型。第三类是错位型错误。模型把告警级别描述错了比如把Warning说成Critical或者把实例数量算错。这种问题靠提示词很难根治我的做法是在生成摘要后增加一个小程序做关键字段的校验回填把模型摘要中提到的告警名、实例数、级别字段和原始结构化数据做比对不一致时以原始数据为准回写。这三类问题各有解法但理念是一致的大模型在告警场景里只能做“内容生成”不能做“事实裁决”。所有模型输出的事实性字段都要在代码层做二次校验这条原则比任何提示词都重要。3. 告警关联分析把一堆告警变成一条故事线3.1 关联分析为什么难告警之间的因果关系本身是模糊的告警关联分析是大模型在运维场景里最有价值、也最难落地的一块原因是生产环境中的告警因果关系从来不是清晰的。一个微服务挂了可能同时触发依赖它的上游调用失败、下游数据库连接池耗尽、网关5xx飙高、容器重启、磁盘告警……这十几个告警是同一个根因导致的多个表现但它们的label之间并没有一个字段能直接把因果串起来。传统做法是人工配置依赖关系或规则比如“当A服务的错误率告警和B服务的延迟告警同时出现时以A服务为准”这种方式在系统拓扑稳定、变更不频繁的团队有效但一旦架构调整或新增服务规则就过期了维护成本极高。大模型关联分析的思路是让它去做“模式识别”把一批告警放在一起让模型识别它们可能的共同根因。这里有两个关键技术选择。第一种是时序对齐关联。把所有告警按开始时间排序在同一时间窗口内出现的告警归入同一批次然后让模型分析这批告警之间可能的主从关系。比如内网某台主机出现横向渗透的告警时同时段通常会有异常登录、权限变更、进程创建的告警序列模型在理解这类安全场景时有天然的语义优势。我在实际项目中就遇到过这类案例某安全设备的告警伴生了多个主机侧的异常行为告警靠人工一条条看至少要半小时LLM把这些告警按时间线串成故事之后研判效率明显提升这也是告警研判工作流中典型的落地场景。第二种是语义embedding关联。把每条告警的标题、内容、标签转成向量通过相似度计算找出语义相近的告警。比如“MySQL连接数过高”和“数据库连接池耗尽”在字面上不同但语义上可能是同一问题的两个表现embedding可以捕捉这类关系。这种方法适合跨系统、跨词汇的关联但计算成本高而且对embedding模型的选择有要求。在我自己落地的系统里两种方法我都用了时序对齐作为主入口embedding相似度作为辅助信号最终把结果塞给LLM生成关联分析结论。3.2 关联分析的系统设计以Alertmanager为数据源具体到系统实现上我建议把关联分析设计成一个独立的服务不直接侵入Alertmanager的发送链路。整体流程是这样的Alertmanager在收到Prometheus告警后完成基础的group分组通过webhook推送到一个中间服务。这个服务负责数据清洗与窗口切分把告警按时间窗口我是用5分钟和告警维度切分成不同的batch。每个batch的告警先做一次embedding聚类再把聚类结果连同拓扑信息如果有的话拼装成Prompt调用LLM接口返回一个结构化的关联分析结果。这个设计里有一个很关键的选择不能让LLM直接决定哪些告警要合并到一个批次因为LLM调用有延迟和成本全量告警逐个分析不现实。所以批次切分必须用规则和代码完成LLM只负责在已知批次内做“精读”。批次切分的代码逻辑可以参考Prometheus的标签分组思路grouped_alerts {} for alert in alerts_in_window: key (alert[labels].get(alertname), alert[labels].get(job)) grouped_alerts.setdefault(key, []).append(alert)当然这只是最基础的按标签分组实际会更复杂我会增加一个“异常检测标记”——对Prometheus自带的severity、summary做加权再结合告警状态变化firing/resolved去重尽量保证每个批次里的告警是“同一件事”。关联分析产出的是一个JSON结构我称之为“告警故事线”包含以下字段{ incident_id: 202406141030_xxxxx, root_likely: 数据库连接池耗尽, related_alerts: [ {alertname: MySQL连接数过高, role: 表现, confidence: 0.8}, {alertname: 服务响应延迟P99超标, role: 表现, confidence: 0.7} ], timeline: 14日10:30 MySQL连接数升高 - 10:31 服务延迟升高 - 10:32 网关5xx增加, suggested_action: 优先检查数据库连接池配置与慢查询 }这里的“root_likely”字段是LLM的推断结论不是系统确认的事实所以我在使用时会在展示层面明确标注“AI推断”并且设置置信度门槛低于0.6的结果只做提示不做自动处理。3.3 关联分析的边界别让它编故事关联分析有一个很容易被忽视的风险模型会把原本不相干的告警强行编织成一个因果故事。这在“故事线生成”的任务上尤其常见因为模型被训练成倾向于给出连贯、自洽的回答而不会轻易承认“这些告警之间没有明确关联”。我用一个具体例子来说明这个风险。某次有一批告警同时触发一台机器的磁盘使用率超过85%、一个服务的HTTP错误率升高、另一个服务的GC暂停时间变长。这三个告警出现在同一个时间窗口LLM给出的关联结论是“磁盘I/O负载导致服务性能下降进而引发HTTP错误率升高”。但实际情况是磁盘告警的那台机器和HTTP错误率的那个服务根本不在同一节点上纯粹是时间上的巧合。那次之后我在关联分析的提示词里加了一条硬性约束“如果告警之间没有明确的依赖关系、公共资源或拓扑关联请直接输出‘未发现明确关联’不要尝试建立因果链。”同时在系统层面增加一道校验所有LLM提到的关联关系必须有数据支撑——要么是同一实例、要么是同一集群、要么是配置了依赖关系——否则标记为低置信度。4. 值班助手从“读告警”到“帮你判断”之间有多远4.1 值班助手的形态选择群机器人还是独立工作台告警摘要和关联分析本质上是“离线或者半离线”的能力而值班助手是面向实时在线场景的交互系统。在真实落地中我见过两种典型形态各有优劣。第一种是聊天群里的大模型机器人。Alertmanager把告警推送到群里后机器人自动生成摘要并对应值班人。这种方式最轻量用户无需切换工具上下文在群聊里自然沉淀事实上一开始我也是先做了这种形态。它的缺陷是交互深度有限群聊里难以做复杂的研判流程而且如果机器人发言过多反而成了新的噪音源。第二种是独立的值班工作台机器人负责把摘要和关联分析结果推送到页面上值班人在工作台里做确认、标记、升级处理。这种形态重一些需要开发成本但能承载告警状态流转、复盘报告、相似案例匹配等更完整的能力。我在落地中最终的形态是两者结合群里只推简版“一句话摘要详情链接”完整研判在工作台完成。这里我特别建议值班助手的消息推送一定做好降噪控制。一个比较实用的参数是只有当同一group的告警聚合超过N条我常用5条或包含Critical级别时才自动推送摘要否则不推。这个参数和Alertmanager的group_wait、repeat_interval是有配合关系的Alertmanager负责把同一批告警聚合后发出机器人侧再做一次时间窗口内的累积判断。4.2 值班助手能做什么我给它的能力边界清单吃过几次亏之后我把值班助手的能力边界固定为四件事其余的宁可不做也不多做。第一件事是告警解释。值班人收到一条告警可以机器人问“这是什么意思”机器人基于告警内容、监控指标含义、历史处理记录生成通俗解释。这看起来简单但用起来很香尤其是对刚接手值班的同学能节省大量翻文档的时间。第二件事是相似案例检索。当出现一条新告警时机器人从历史告警库中检索相似案例并给出当时处理动作和最终结论。这里要强调的是相似案例检索的质量依赖于历史数据的标注质量如果你的团队没有维护处理记录的习惯这个功能就形同虚设。第三件事是处理建议生成。机器人综合告警详情、关联分析结果、相似案例生成“建议先检查什么、再看什么”的操作步骤。注意是建议不是决策我会在界面上明确标注“参考建议”避免值班人盲目执行。第四件事是离线简报。每天早上9点将过去24小时的告警按服务、类型、级别聚合生成一份告警日报。这部分是纯异步任务不占用在线交互资源价值是帮助技术团队负责人快速掌握系统健康状态。4.3 值班助手不能做的决策兜底与人肉复核与能做什么同等重要的是明确它不能做什么。我在这里划定的边界是值班助手不做任何最终决策不自动执行任何变更操作不直接关闭或屏蔽告警。有一次我做了一个实验性的功能——让机器人根据告警级别自动选择处理预案不仅推荐检查步骤还准备自动触发一些常规的“恢复操作”。实验阶段就发现一个严重问题在某个变更窗口期间有一个服务的实例由于发布顺序问题导致短暂不可用触发的告警正好命中了机器人预设的“重启服务”预案如果自动化执行会把发布中的新版本全部重启回滚造成更长时间的业务中断。那次之后我彻底下架了自动化操作相关的能力改为机器人把处理建议推送给值班人值班人确认后再执行。这也是所有告警系统落地时都应该守住的一条底线AI可以帮你读告警但拍板的人必须是真人。5. 落地过程中最实际的几个问题成本、幻觉、延迟、效果评估5.1 Token成本摘要不是每条告警都做用大模型处理告警最容易被团队质疑的就是成本问题。很多人在方案评审阶段就会问“一天几千条告警每条都让大模型总结一下一个月得多少钱”我的答案是不要让大模型处理每条告警。告警摘要和关联分析都只针对“聚合后的批次”执行而且批次也要分级。设计如下先让Alertmanager的group分组和group_wait做第一层收敛把5分钟内同一类别的告警合并为一批。中间服务对每一批做一次规则判断只有满足以下任一条件的才调用LLM批内告警数大于等于5条、包含Critical级别、包含安全类告警标签如内网横向渗透相关。其余的低级别低频告警直接用模板生成一行文本推送即可不走大模型。以我自己团队的体量为例每天原始告警大概2000条经过Alertmanager收敛后约300批再经过条件过滤后每天调用LLM的数量约80-120次按单次调用输入的token在800-1500之间计算每天消耗约15万token。用中档模型的定价一个月成本大约几百元人民币。如果团队告警量大可以再叠加本地小模型过滤进一步降低成本。5.2 幻觉控制提示词工程之外需要系统兜底告警场景里幻觉的代价比普通内容生成场景高很多因为告警摘要会影响值班人的判断甚至影响故障处理方向的决策。除了在第2节提到的提示词约束外建议再加三道系统兜底防线。第一道是事实字段校验程序我之前提过的回填校验。在LLM输出后程序用正则表达式抽取摘要中出现的实例名、服务名、告警级别和输入的结构化数据做match不一致则强制用输入数据覆盖。第二道是置信度自我评估输出。我在提示词里要求模型在每个关联结论后面附带confidence字段0到1之间的一个数。这个数即便不是百分之百可靠但能有效帮助我们建立“低置信度结果不自动展示”的规则。第三道是人工抽查反馈闭环。每周抽10条AI生成的摘要由资深值班同学打分标注错误数据回流到样本库中定期用这批数据对提示词或模型做评测。这种反馈机制的价值远超在办公室里面想prompt怎么写因为生产环境的数据才是最好的“考试卷”。5.3 延迟与并发别让AI成为告警链路的新瓶颈告警处理是典型的低延迟场景从告警产生到值班人看到摘要中间的时间预算通常只有几十秒。引入LLM调用后网络延迟和推理延迟是绕不开的问题。我给出的参考设计是异步化处理Alertmanager推来的告警先落库立即推一条“原始告警”到群里确保信息及时触达。同时后台异步调用LLM生成摘要生成完成后追加一条“AI摘要”到对应线程。这样即使LLM耗时10到20秒也不影响第一条通知的及时性。并发控制方面我建议给LLM调用加一个简单的信号量限流避免告警洪峰时把所有请求同时打出去。我用的参数是最大并发5个超过的请求排队等待。这个值需要根据你的模型服务能力调整太低了会造成积压太高了可能出现限流报错导致摘要丢失。如果摘要生成失败系统要有fallback机制——直接推送原始聚合告警数据而不是让值班人什么都看不到。5.4 效果评估用“信息增益”而不是“处理时长”来衡量最后是值班效率提升的度量。很多项目在复盘时喜欢用“平均故障处理时长MTTR下降了多少”来体现价值但AI摘要对MTTR的影响往往被很多其他因素干扰衡量并不准确。我建议用一个更直接的指标叫“信息增益命中率”——即值班人在看到AI摘要后是否比只看原始告警更快地做出了正确判断。落地方法是让值班人在处理完告警后顺手打一个标签AI摘要“有帮助定位”“帮助确认方向”“无参考价值”三选一。每周统计“有帮助”的占比这个指标比MTTR更能真实反映摘要质量。跑了一段时间之后我个人的体会是大模型在告警领域真正的价值不在于替代人做决策而在于把值班人从“信息洪流”中解放出来让他们把时间花在真正需要人脑判断的地方。告警摘要能帮你5秒理解发生了什么关联分析能帮你勾勒出问题的大致范围值班助手能帮你调出历史案例和参考预案但最终那句“现在要不要切流量、要不要重启服务、要不要叫醒研发同学”仍然要由人来决定。想落地这个方向的朋友我建议从最小的场景切入先把Alertmanager的告警接过来只做一个群机器人摘要把准确率测准了再往关联分析和自动化的方向走。数据清了、边界划了、流程顺了AI就能真正成为值班体系里最得力的那个副驾驶。