前两篇我们解决了"慢在哪"和"发生了什么"。但可观测性的闭环还有一个关键动作：问题发生时，系统能不能主动告诉你，而不是等用户投诉或你碰巧在看监控。对大模型接口来说，告警尤其重要——模型厂商限流（429）、推理超时、Token 成本突增，都是会直接影响业务 SLA 的事故。

SkyWalking 的告警体系基于 OAL（Observability Analysis Language）。OAL 是一种声明式指标语言，你用几行表达式描述"想对什么数据做什么聚合"，OAL 引擎就会实时计算出指标流，再交给告警规则判断是否触发。本篇带你从零搭一套面向大模型接口的告警：覆盖慢推理、错误率、限流三个核心场景，并接入 Webhook 推送到钉钉/企微。

1. 为什么大模型接口需要专门告警
2. SkyWalking OAL 与告警核心概念
3. OAL 实战：为大模型接口编写规则
4. 告警处理器与 Webhook 配置
5. 实战：慢推理与限流 429 告警
6. 告警分级与降噪
7. 最佳实践与踩坑

1. 为什么大模型接口需要专门告警

通用接口的告警（CPU、JVM、HTTP 错误率）对大模型不够用，原因有三：

第一，大模型故障形态特殊。它不是"服务挂了"，而是"变慢了""被限流了""开始胡说（内容异常）"。这些在传统阈值告警里看不见。你更需要 `ttft > 3s`、`429 占比 > 5%`、`单请求 token 成本突增` 这类语义化指标。

第二，成本敏感。大模型按 Token 计费，一次异常循环调用（如死循环追问）可能几小时烧掉数万元。对 "token 消耗速率" 做告警，能在财务爆炸前止损。

第三，依赖外部不可控。模型厂商的可用性是黑盒，你的 SLA 却要对用户负责。通过告警第一时间感知厂商抖动，才能快速切备用模型或降级。

所以大模型告警要"语义化 + 业务化"，这正是 OAL 的强项：它能在指标层直接表达"大模型推理 P99 延迟""限流错误率"。

2. SkyWalking OAL 与告警核心概念

OAL 把"数据来源"称为 Scope（作用域），把"聚合方式"称为函数。常见 Scope：

• `Service`：服务级，如 `Service.latency`、`Service.successRate`。
• `Endpoint`：端点级（某个 URL/方法），适合按接口区分。
• `ServiceInstance`：实例级（单 JVM）。
• `ServiceRelation` / `EndpointRelation`：调用关系。

常用聚合函数：`longAvg`（均值）、`longPercentile(n)`（百分位，n=4 即 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 也支持按标签过滤：

// 按模型分组的推理 P99
llm_gpt4o_p99 = from(Endpoint.latency).filter(name like "%/api/chat%" and tag["llm.model"] == "gpt-4o").longPercentile(4);
 

修改 OAL 后需重启 OAP（OAL 在启动期编译为流式计算类）。上线前先在 UI "指标"页确认新指标有数据，再配告警。

4. 告警处理器与 Webhook 配置

指标定义好后，在 `config/alarm-settings.yml` 引用它们。示例如下：

rules:
  llm_p99_rule:
    metrics-name: llm_inference_p99
    op: ">"
    threshold: 3000
    period: 10
    count: 2
    silence-period: 15
    message: "大模型推理 P99 延迟超过 3000ms，当前值 {value}"
  llm_error_rule:
    metrics-name: llm_error_rate
    op: ">"
    threshold: 5
    period: 10
    count: 2
    silence-period: 15
    message: "大模型接口错误率超过 5%，当前值 {value}%"
  llm_429_rule:
    metrics-name: llm_429_count
    op: ">"
    threshold: 20
    period: 5
    count: 1
    silence-period: 10
    message: "大模型接口 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 分钟窗口 > 3000ms，OAP 触发 `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_p99	2500ms	5000ms	推理变慢
llm_error_rate	5%	20%	接口失败
llm_429_count	20/5min	100/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 重试有限，网关侧要对重复告警做幂等（按 `ruleName+name+时间窗` 去重），并支持失败回退到本地日志，防止通知链路本身成单点。

第五，告警消息带上下文。好消息应包含 `name`（哪个接口）、`value`（当前值）、`startTime`，最好附 SkyWalking UI 的 Trace 查询链接，让值班人点开就能排障，而不是再手动拼条件。

第六，别只告警不治理。告警是信号不是终点。每次 critical 告警应回流成一次复盘：是阈值不合理、是模型侧问题、还是自己代码 bug。否则告警量只会随业务增长线性膨胀。

把 OAL 规则 + 分级路由 + Webhook 网关三件套搭好后，大模型接口的"慢、错、限"三大类事故，就能在你喝咖啡时主动弹到面前，而不是等客服转来一句"用户说机器人卡住了"。