前两篇我们解决了慢在哪和发生了什么。但可观测性的闭环还有一个关键动作问题发生时系统能不能主动告诉你而不是等用户投诉或你碰巧在看监控。对大模型接口来说告警尤其重要——模型厂商限流429、推理超时、Token 成本突增都是会直接影响业务 SLA 的事故。SkyWalking 的告警体系基于 OALObservability Analysis Language。OAL 是一种声明式指标语言你用几行表达式描述想对什么数据做什么聚合OAL 引擎就会实时计算出指标流再交给告警规则判断是否触发。本篇带你从零搭一套面向大模型接口的告警覆盖慢推理、错误率、限流三个核心场景并接入 Webhook 推送到钉钉/企微。为什么大模型接口需要专门告警SkyWalking OAL 与告警核心概念OAL 实战为大模型接口编写规则告警处理器与 Webhook 配置实战慢推理与限流 429 告警告警分级与降噪最佳实践与踩坑1. 为什么大模型接口需要专门告警通用接口的告警CPU、JVM、HTTP 错误率对大模型不够用原因有三第一大模型故障形态特殊。它不是服务挂了而是变慢了被限流了开始胡说内容异常。这些在传统阈值告警里看不见。你更需要 ttft 3s、429 占比 5%、单请求 token 成本突增 这类语义化指标。第二成本敏感。大模型按 Token 计费一次异常循环调用如死循环追问可能几小时烧掉数万元。对 token 消耗速率 做告警能在财务爆炸前止损。第三依赖外部不可控。模型厂商的可用性是黑盒你的 SLA 却要对用户负责。通过告警第一时间感知厂商抖动才能快速切备用模型或降级。所以大模型告警要语义化 业务化这正是 OAL 的强项它能在指标层直接表达大模型推理 P99 延迟限流错误率。2. SkyWalking OAL 与告警核心概念OAL 把数据来源称为 Scope作用域把聚合方式称为函数。常见 ScopeService服务级如 Service.latency、Service.successRate。Endpoint端点级某个 URL/方法适合按接口区分。ServiceInstance实例级单 JVM。ServiceRelation / EndpointRelation调用关系。常用聚合函数longAvg均值、longPercentile(n)百分位n4 即 P99因 10^n、count计数、sum、percent比率、histogram直方图、distinctCount去重计数。OAL 指标再被 alarm-settings.yml 引用。一条告警规则包含metrics-name对应 OAL 定义的指标、op比较符、threshold阈值、period统计窗口单位分钟、count连续触发次数、silence-period沉默期避免重复打扰。数据流是探针埋点 → OAP 接收 → OAL 实时计算指标 → 告警规则判定 → 告警处理器Webhook / 钉钉 / 企微 / Grafana→ 通知人。3. OAL 实战为大模型接口编写规则SkyWalking 的 OAL 文件在 config/oal/*.oal。我们新建 config/oal/llm.oal定义面向大模型的指标。// 大模型推理 P99 延迟端点级匹配 chat 接口llm_inference_p99 from(Endpoint.latency).filter(name like %/api/chat%).longPercentile(4);// 大模型接口平均耗时llm_endpoint_avg from(Endpoint.latency).filter(name like %/api/chat%).longAvg();// 大模型接口错误率HTTP 状态码非 2xx 占比llm_error_rate from(Endpoint.latency).filter(statusCode 400).percent();// 限流错误计数429 占比用 count 近似配合比率规则llm_429_count from(Endpoint.latency).filter(statusCode 429).count();说明OAL 的 filter 支持字符串匹配like / matches与数值比较。上面的 name like %/api/chat% 会把所有 chat 端点聚成一条指标。若你按子标题里的 llm.model Tag 区分模型OAL 也支持按标签过滤// 按模型分组的推理 P99llm_gpt4o_p99 from(Endpoint.latency).filter(name like %/api/chat% and tag[llm.model] gpt-4o).longPercentile(4);修改 OAL 后需重启 OAPOAL 在启动期编译为流式计算类。上线前先在 UI 指标页确认新指标有数据再配告警。4. 告警处理器与 Webhook 配置指标定义好后在 config/alarm-settings.yml 引用它们。示例如下rules:llm_p99_rule:metrics-name: llm_inference_p99op: threshold: 3000period: 10count: 2silence-period: 15message: 大模型推理 P99 延迟超过 3000ms当前值 {value}llm_error_rule:metrics-name: llm_error_rateop: threshold: 5period: 10count: 2silence-period: 15message: 大模型接口错误率超过 5%当前值 {value}%llm_429_rule:metrics-name: llm_429_countop: threshold: 20period: 5count: 1silence-period: 10message: 大模型接口 5 分钟内 429 限流超过 20 次当前值 {value}webhooks 段配置推送地址webhooks:- http://alert-gateway/internal/notify告警触发时OAP 向 Webhook POST 一段 JSON{scopeId: 2,name: POST:/api/chat,id: xx,ruleName: llm_p99_rule,alarmMessage: 大模型推理 P99 延迟超过 3000ms当前值 4120,startTime: 1723000000000}你的网关服务解析后转成钉钉/企微 Markdown 消息即可。5. 实战慢推理与限流 429 告警把上面配置落到环境后重点验证两类最典型的告警。慢推理告警模拟把 max_tokens 调大或模型侧排队制造 P99 升高。当 llm_inference_p99 连续两个 10 分钟窗口 3000msOAP 触发 llm_p99_rule。此时你应能在 UI 告警页看到记录同时 Webhook 收到通知。注意阈值不要拍脑袋。先观察一周的基线取 P99 基线的 1.5~2 倍作为阈值。例如基线 P99 是 1200ms阈值设 2500ms 更合理避免误报。限流 429 告警模型厂商配额耗尽时网关会大量返回 429。配置 llm_429_count 20/5min 触发提醒你扩容配额或切备用模型。这里用 count 而非 percent因为 429 在小流量下占比会失真比如只调 2 次就 1 次 429占比 50% 但绝对值低用绝对次数更稳。一个常用的分级阈值对照表指标预警阈值严重阈值含义------------llm_inference_p992500ms5000ms推理变慢llm_error_rate5%20%接口失败llm_429_count20/5min100/5min厂商限流llm_avg_token_cost基线 1.5x基线 3x成本突增6. 告警分级与降噪告警最大的敌人不是漏报而是狼来了——每天几百条没人看。SkyWalking 本身提供 silence-period 抑制重复但系统级降噪还要做三件事第一分级。用不同 ruleName 前缀区分 warn_ / critical_Webhook 网关据此路由到不同群预警群 vs 电话群。严重级别才打电话。第二聚合。同一服务短时间多条告警在网关侧按 ruleName name 聚合为一条摘要避免刷屏。第三收敛到根因。大模型告警常是结果而非原因429 触发 → 错误率涨 → 延迟涨。网关侧可做因果排序只推送最早那条429其余折叠。下表是推荐的分级路由策略级别触发示例通知方式响应要求------------提示(info)P99 轻度超基线机器人静默记录次日复盘预警(warn)错误率 5%企微群 值班30 分钟内确认严重(critical)429 超 100/5min电话 群立即处理7. 最佳实践与踩坑第一先有基线再设阈值。没有历史数据就设 3000ms很可能要么常年不响阈值过高要么天天误报阈值过低。建议用 OAP 的 metrics 先观察 1~2 周。第二OAL 改完必须重启 OAP。OAL 在启动期编译运行时改文件不生效。且改 OAL 会改变指标名旧数据不可比变更要记录在案。第三count 与 period 配合调灵敏度。count: 2, period: 10 表示连续两个 10 分钟窗口都超阈值才告警能过滤毛刺count: 1 则对偶发也敏感适合 429 这类快速恶化场景。第四Webhook 要幂等与可重试。OAP 重试有限网关侧要对重复告警做幂等按 ruleNamename时间窗 去重并支持失败回退到本地日志防止通知链路本身成单点。第五告警消息带上下文。好消息应包含 name哪个接口、value当前值、startTime最好附 SkyWalking UI 的 Trace 查询链接让值班人点开就能排障而不是再手动拼条件。第六别只告警不治理。告警是信号不是终点。每次 critical 告警应回流成一次复盘是阈值不合理、是模型侧问题、还是自己代码 bug。否则告警量只会随业务增长线性膨胀。把 OAL 规则 分级路由 Webhook 网关三件套搭好后大模型接口的慢、错、限三大类事故就能在你喝咖啡时主动弹到面前而不是等客服转来一句用户说机器人卡住了。