1. 问题拆解与方案选型告警处理真正卡在哪里1.1 告警不是太少而是太多真正缺的是“信息预消化”凌晨两点半值班群里开始刷屏。第一条是“CPU使用率超过90%”第二条是“API响应时间超过5秒”第三条是“数据库连接数达到阈值”到最后你分不清是三个故障还是一个故障的三个表现。这不是某一家的特殊情况几乎所有监控体系跑过一年以上都会遇到这个问题告警不是太少而是太多多到人已经失去了逐条阅读的耐心。我最早接触这个问题的场景是在维护一套基于Prometheus和Alertmanager的监控体系时收到的上百条“兄弟告警”——同一个服务抖动同一时间窗口内触发了响应时间、错误率、内存使用率、GC暂停等多个指标规则。人工看这些告警时每条都能看懂但你很难在十分钟内把它们拼成一副完整的故障图。传统降噪手段大多是“抑制”和“聚合”解决的是消息变少的问题却没有解决“信息可读性”的问题。所以 AI 读告警这件事我理解的切入点不是“AI创造新规则”而是让大模型摘要、关联分析和值班助手成为一个“前置翻译层”把机器生成的一堆结构化字段变成值班员能快速理解的自然语言解释把分散在时间轴上的相关告警变成一组带因果假设的问题描述把一个需要人肉翻日志的排查过程变成助手给出的建议动作和上下文卡片。这篇文章不会给你一个“AI 接管全部监控”的童话故事。这个项目最值得讨论的是落地边界——哪些环节值得让模型介入哪些环节必须留在规则和人的手里。这既是我在真实监控环境里验证过的方案也是我觉得多数团队能直接抄作业的起点。1.2 为什么“边界”这个词值得单独立项很多团队一上来就让大模型做“根因分析”和“自动恢复”结果基本都翻车了。我一开始也踩过这个坑。后来反思下来AI 读告警里的“边界”至少有四层少想一层都会出问题第一层是能力边界。大模型擅长的是语言理解和模式归纳不擅长精确数值计算也不擅长实时指令下发。它可以把“CPU使用率85%、平均负载32、top进程是java”这段字段翻译成人话但它没法替你判断这个java进程到底是不是批次任务造成的更不该直接帮你执行重启。第二层是成本边界。每条告警都丢给大模型一周下来 token 账单和排队延迟都能让人崩溃。高并发告警场景下必须把最容易去重的部分先用规则处理掉只把真正需要理解的“聚合结果”送进模型。第三层是权限边界。值班助手必须是一个“只读顾问”不能有执行窗口的操作权限。它可以建议“执行预案A”但点击执行的按钮必须由人来按。这不是技术保守而是事故追责和审计链条的基本要求。第四层是责任边界。告警处理最怕“AI 说没事那就没事”。如果模型输出怀疑有未知影响那这个“不确定”必须显式传达到值班员而不是被吞掉。AI 提供的永远是候选项值班员才是最终决策人。这四条边界不是写在设计文档里就完事了它在代码里、Prompt里、监控告警的权限设计里都应当有对应的体现。后面的章节我会逐条展开先说摘要再说关联分析最后是值班助手和避坑经验。2. 大模型告警摘要从模板到自然语言的“翻译层”2.1 模型选型与数据准备先统一“方言”再谈理解告警文本的“方言”问题往往被忽略。不同监控系统输出的字段名五花八门Alertmanager 里是alertname夜莺里可能是rule_name自研系统里可能是event_type。你在 Prompt 里让模型“理解告警字段”之前得先把这些字段归一化成一套固定 schema。我的做法是做一个告警标准化转换层放在 webhook 接入处。无论是 Alertmanager 的 HTTP 回调、夜莺的告警事件推送还是自研系统吐出的 JSON统一转成如下结构再送给模型{ event_id: evt_20250601_001, src: prometheus/alertmanager, rule_name: HighCPUUsage, severity: warning, status: firing, started_at: 2025-06-01T02:10:00Z, labels: { host: web-01, instance: 10.0.1.10:9100, service: order-api }, annotations: { summary: CPU usage 90% for 5m, description: CPU usage has been above 90% (current: 95.2%) for 5 minutes } }字段统一之后再考虑模型部署方式。我的经验是能私有化部署就别用外部 API。不是所有公司都有底气把监控元数据传到云端尤其涉及业务KPI、集群 IP 拓扑这类敏感信息时内网部署一个 7B 到 14B 量级的开源模型是更稳妥的选择。机器配置允许的话我建议直接用 Qwen2.5-14B-Instruct 或同级别模型显存 24GB 以上的单卡就能跑推理响应延迟控制在 2 秒以内没问题。如果你团队已有 GPT/Claude 类 API 接入也可以拿来做摘要试跑对比。真实告警数据测试下来14B 本地模型在摘要任务上的效果并不比大 API 差多少因为摘要本质上是“信息压缩和转述”不是深度推理。2.2 Prompt 设计两阶段抽取加转述比一步生成稳定得多许多人做告警摘要时喜欢一步到位“请根据这段告警生成一段摘要。”试过你就知道模型经常会把“可能原因”脑补进去比如看到磁盘告警就写“可能是日志写入过多”这句猜测一旦出现在摘要里就会误导值班员。要治这个问题我自己现在用的是两阶段方案先抽取结构化事实再基于抽取结果转述。第一阶段 Prompt 长这样你是告警摘要引擎。请从以下告警中抽取结构化事实只抽取输入中明确出现的字段禁止任何推测。 要求 1. 抽取结果用 JSON 输出字段为 event_id, affected_service, affected_host, metric_value, start_time, severity。 2. 如果某个字段在原始告警中不存在填写 unknown。 3. 不要回答任何原始告警之外的信息。 告警输入 {标准化后的JSON}第二阶段 Prompt 基于第一步的抽取结果请根据以下抽取结果生成一段供值班员快速理解的中文摘要。要求 - 不超过80字。 - 先说影响对象再说异常表现最后说持续时间。 - 只转述抽取结果中的事实不得新增原因分析。 - 如果包含 unknown 字段在摘要末尾增加“部分字段缺失”。 抽取结果 {第一阶段的JSON输出}两阶段看起来多了一次调用实际上非常值。抽取阶段把模型限制在“事实提取”这个低风险任务上转述阶段面对的是干净字段几乎没有发挥空间自然也就很少出现幻觉。我实测过直接把原始告警丢给模型生成摘要出现“臆测原因”的比例大约在 12% 到 15%改成两阶段之后这个比例降到了 2% 以内。温度参数也记得调低。做摘要、抽取这类任务temperature0.1甚至0都是合适的我一般固定在 0.1。这个参数不用迷信但你设成默认 0.7 时同一批告警的摘要措辞会飘得厉害。2.3 摘要输出的实践形态不是给人读小说而是给卡片提供“一行字”摘要模型产出的内容最后会进入值班渠道。我们内部用的飞书群机器人一条摘要最终以卡片形式呈现核心是这五块影响对象服务 主机 实例异常表现指标取值、持续时间关联告警数量同规则、同服务的自动归并数建议动作源自预案库非模型生成原始告警链接大模型输出的自然语言摘要只负责“影响对象”和“异常表现”两行的最终表达其他内容由周边系统拼装。这样分工的好处是模型哪怕偶尔句子不通顺也不影响卡片关键动作的执行。还应该给摘要加一个“不确定标记”。我见过一个很有意思的失败案例模型把一条status: firing且annotations里缺失描述的告警转述成“container restarted”“restarted”在源码里根本没出现这纯粹是模型根据容器类告警的惯性补出来的。人眼看不出来但值班员如果根据这句推测就直接判定“重启过了”而跳过处理问题就被放过去了。所以我在两阶段方案里特意保留了unknown的透传并在摘要里提示“部分字段缺失”——这个小小的提示比模型生成 100 字漂亮摘要都重要。3. 关联分析把“一百条告警”变成“三类问题”3.1 先用规则兜底别拿大模型做重复告警合并的脏活我一直强调规则永远是成本最低的过滤器。Alertmanager 的group_by和inhibit_rules、夜莺的告警规则标签、你自研系统里的“同主机同规则聚合窗口”这些机制本身就是在做关联分析。最典型的场景是一个数据库实例挂了上游十几个服务的响应错误告警同时轰炸但所有这些都不如“数据库实例存活”那一条重要。inhibit_rules干的就是这件事让高等级告警抑制低等级衍生告警。真实环境中我建议把预处理逻辑按下面这个顺序固定下来同一alertname且同一监听对象在 5 分钟窗口内自动归并为一条。同一主机或同一服务的多条告警归并到“主机事件”或“服务事件”。命中已知抑制规则例如基础设施宕机抑制业务层告警的直接折叠。经过前三步仍然存在的告警才进入大模型关联分析管道。这四步做完夜间告警风暴里的消息量通常能砍掉 80% 以上。很多项目一上来就搞 embedding 聚类反而忽略了这些搭积木式的规则那是捡了芝麻丢西瓜。3.2 大模型加入后语义关联怎么落地规则归并解决的是“看起来一样”的聚合模型解决的是“看起来不一样但指向同一个故障”的关联。举我实际遇到的一个例子某天凌晨同时出现了三条告警订单服务的数据库连接池使用率告警、数据库实例的活跃会话数告警、另一个服务的慢查询耗时 P99告警。这三条在规则层面没有任何相同的标签但因为数据库慢查询导致连接被占满、业务接口响应变慢它们在因果上是同一件事。要让模型发现这种关联我的做法是分组输入 联合解读。按 30 秒为一个滑动批次把窗口内未被规则合并的告警全部送进模型让模型先做一次粗聚类再对每一组给出联合解释。这里的 Prompt 不能给太多自由否则模型会发明各种玄学关联。我用的提示词核心要求是给定一个时间窗口内的若干告警请考虑 1. 是否有相同的 affected_host 或 affected_service。 2. 是否有明显的依赖关系A 服务的告警可能是 B 服务告警的上游原因。 3. 时间上是否集中在同一分钟。 4. 只输出候选项。不确定是否相关时使用 lower 置信度。 输出格式为 JSON{ groups: [ { reason: 关联原因, event_ids: [], confidence: high|medium|low } ] }需要注意这里让模型做的不是“发现所有隐藏关联”而是“输出候选假设”。置信度字段特别重要。high级别的关联通常是有明确共享主机或服务依赖的medium和low级别的关联只用来在页面上以虚线展示不参与自动合并。另外嵌入向量语义聚类也可以作为基础工具。把每条告警的summary rule_name labels转成 embedding然后算两两相似度。这个方案适合做“同类型故障历史相似”的离线分析比如判断今天这条告警和上周某次故障的描述高度相似可以把历史处置报告推送给值班员。但我不建议把 embedding 相似度作为线上的直接合并依据因为向量空间里的“文本相似”和运维意义上的“因果关联”差距很大宁可保守一点。3.3 边界重申根因定位绝不可全交给模型模型说“慢查询导致连接池耗尽”这是一个假设不是结论。要验证这个假设得看数据库当前processlist、慢日志采样、连接池监控曲线。AI 给值班员的最大价值是把搜索范围收窄到一两个方向而不是直接给出判决。我们内部的底线是不能让模型输出自动触发任何变更。它可以建议“检查数据库慢日志”“查看连接池监控页”但后续每一次资源操作都必须走工单或人工命令。原因很简单告警关联分析里的因果方向有时是完全反的。比如“GC 耗时升高”和“CPU 使用率升高”同时出现除了“高 GC 导致 CPU 飙升”之外也可能是“部署新版本后 CPU 飙升引发更多 GC”。模型只看文本几乎没有能力区分这两种情况人在做验证时反而容易。4. 值班助手落地人机协同的工作流设计4.1 助手的定位是“解读官”而不是“执行者”值班助手这个名字很有迷惑性一开始产品经理想要的是一键处置所有告警的机器人。我明确反对了。我的想法很简单AI 值班助手的用户是值班员不是监控系统本身。它的职责有这么几件在群内以固定格式推送告警摘要和关联分组。给出建议动作列表来自预案库带链接。回答值班员用自然语言提出的追问比如“这个服务昨天有类似告警吗”。记录人工处置结果形成复盘素材。你可以把它想象成一个特别熟悉监控系统的副驾驶负责读仪表盘、念检查单但方向盘始终在主驾驶手里。这个定位如果一开始就讲清楚后面所有产品设计都不太会跑偏。技术上最简单可行的入口是做一个监听群的机器人服务。Alertmanager 或夜莺把告警 webhook 打到这个服务服务完成标准化、摘要、聚合后通过群机器人 API 推送卡片。值班员在群里 助手提问时服务把问题加上当前告警上下文拼成 Prompt再调用本地大模型返回答案。整个链路只需要一个轻量服务和一个模型推理端点。4.2 权限设计只读、建议、可审计的三条铁律值班助手的权限边界我在生产环境里定成三条铁律任何开发需求都不能碰第一助手只能读取告警、监控指标、变更记录等数据不能往任何目标系统写数据。国内很多团队用的夜莺、Prometheus 生态都是只读接口写操作一律封死。第二助手输出里可以出现“建议执行预案重启实例”“建议缩容 2 节点”这类话但按钮必须链接到人工审批流程。意思是模型可以建议流程必须停留在人那里。哪怕有一天模型准确率做到 99%剩下那 1% 的破坏力在任何规模的业务集群上都承受不起。第三所有模型输入输出都要可审计。原始告警 JSON、Prompt 全文、模型回复、值班员最终操作全部落库。这个审计日志不是给安全部门看的是给出事后复盘准备的一旦发现误判可以快速定位是模型理解错了还是标准化环节丢了字段。这里分享一个我们在实现“建议动作”时的细节建议动作不要由模型自由生成而是让模型从预案库中“检索 挑选”。我们在 Prompt 里放入预案库条目要求模型匹配当前告警场景并选择其中一条或几条没有匹配项就输出“当前无匹配预案请人工确认”。自由发挥的 AI 建议有时看着很合理实际是胡说绑定预案库之后路子就正了很多。4.3 值班流程中的消息形态与告警生命周期日常运行时值班助手对一类故障通常只推送两条消息第一条是开始消息告警被标准化后群内立刻出现“故障可能开始”的卡片包含摘要、关联告警列表、置信度和建议动作。第二条是状态更新消息如果告警事件持续超过 15 分钟助手会把模型分析出的最新候选根因、相关指标趋势一并推送提醒值班员升级处理。这样设计是为了避免人看完一条信息量巨大的卡片后精神疲劳。推送节奏本身也是降噪手段。让值班员把目光集中在一开始的判断和超时后的升级决策上比每五分钟推一条新告警更有效。我强烈建议任何做值班助手的团队都把告警的状态机画出来firing、ack、resolved、expired。助手的一切推送都基于状态变化触发。状态不变化即便同一条告警重复触发也不应该打扰值班员。这条原则写进设计文档能省掉后面无数扯皮。5. 常见问题与排查实录我在实际项目里踩过的坑5.1 摘要总漏关键字段十有八九是 schema 和 Prompt 不匹配早期测试摘要功能时经常出现“漏掉主机名”“时间格式变成相对时间”之类的问题。第一反应是模型不行排查来排查去发现根因是两阶段抽取里的字段名描述和标准化字段没有严格对齐。比如标准化层输出的是hostPrompt 里写的是affected_host模型有时能对上有时对不上。解决办法是加一层字段映射表并且在 Prompt 里明确给出字段的合法取值示例。现在我的做法是Prompt 中列出的字段名和标准化 JSON 完全一致不再额外发明新名词同时在抽取阶段带上几个历史样本作为 few-shot。这样改完之后漏字段率从 8% 掉到了 1% 以下。另外要特别注意时间格式。模型默认喜欢输出“5 分钟前”这类相对时间但告警摘要场景必须强制输出 ISO8601 绝对时间否则后续时间轴排序会乱套。5.2 关联分组把无关告警并在一起了怎么办有个案例我印象很深同一时间窗口内一个支付服务和一个消息队列服务同时告警模型因为两个规则名里都包含“timeout”就合并成了一个“关联组”。值班员顺着合并后的解释看了十分钟才发现完全是两个独立故障白白浪费了时间。出现这种情况时不要立刻怪模型先看自己的聚类策略。加一个应用维度约束默认只在同服务、同主机或明确依赖关系的告警之间做语义关联跨服务的关联除非置信度达到 high否则只作为提示展示。再配合一个 3 分钟的滑动窗口不让太早或太晚的告警混进同一批。调完这两个参数误关联的问题基本就绝迹了。5.3 高峰期的延迟和 token 成本怎么控制告警风暴时几百条告警同时进来同步调用大模型一定会把队列打爆。我的解决方式是把摘要任务拆成异步流水线进来先做规则归并归并后的少量任务进入队列每个窗口内只对代表性告警做完整摘要其余告警仅在关联组里保留原始标题模型服务发生排队时自动降级为模板摘要。模板摘要没有大模型的自然语言表达但至少保留了“服务 指标 时间”三要素值班员不至于完全失去上下文。关于成本本地部署模型基本只考虑机器电费外部 API 则要按 token 预估。一条告警标准化后大概 200 到 400 token两阶段调用约 700 token。如果每天 1 万条原始告警经规则归并后送进模型的约 1000 条那么一天大约消耗 70 万 token。这个量级如果全走外部 API月成本不小本地部署反而是长远更稳的方案。5.4 对“AI 读告警”最大的误解AI 不是用来兜底的最后想聊聊这几个月最深的感受。很多团队把 AI 值班助手当成“出了问题它得负责”的系统这是最大的误解。模型一定会产生幻觉准确率不可能 100%它读告警的速度和广度确实超过人类但它的“理解”更多是文字层面的流畅不是系统层面的确定。所以我们在内部坚持了一个原则模型永远只给答案选项给不了最终判断。任何一条告警从出现到关闭至少要有人或既有的自动化预案确认过。AI 存在的意义是让值班员的注意力从“阅读一百条告警”变成“确认几个关键选项”省下来的是时间不是责任。这个心态摆正之后项目的推进反而顺利很多。摘要更敢放开用关联分析也在从候选提示走向半自动标记值班助手的推送频率和内容也越来越受团队认可。如果你也要做类似的事情我建议从最窄的边界开始先做单一维度摘要再谈关联最后才碰助手交互。每一步都稳住了前面那些“边界”才会从口号变成真正有用的护栏。
