告警规则怎么设计
告警围绕四类信号设置：延迟分位、错误率、KV 水位与硬件状态。阈值应当基于自身基线来定，例如「P95 相对基线上升多少比例并持续多久」，而不是照抄示例数字。每条告警都要挂上处置动作，值班收到的应该是可执行的事项，而不是需要自行猜测的曲线。
基本信息
| 四类信号 | 延迟分位、错误率、KV 水位与排队、硬件（温度/功耗/ECC） |
|---|---|
| 阈值来源 | 自身业务基线，例如基线 P95 的上浮比例 |
| 抑制抖动 | 用持续时间条件过滤瞬时波动 |
| 配套内容 | 严重级别与 Runbook 处置入口 |
| 维护节奏 | 定期复核误报率与阈值有效性 |
典型使用场景
- 服务上线前：把关键信号全部纳入告警，避免只靠人工巡检
- 压制告警风暴：给阈值加持续时间条件，抖动不再触发通知
- 值班交接：每条告警链接到处置步骤，交接不依赖口头经验
- 演练验证：人为制造故障，确认告警能在用户投诉之前触发
- 复盘对照：回看故障时间线，检查告警是否比用户反馈更早
规则骨架
规则骨架
groups:
- name: llm
rules:
# 指标名以本机 /metrics 实际输出为准，升级后需复核
- alert: LLMErrorRateHigh
expr: <错误率表达式> > 0.05
for: 5m
- alert: LLMQueueDepthHigh
expr: <等待请求数> > <基线阈值>
for: 10m
# 每条规则都写清严重级别与 Runbook 链接规则设计的四个问题
| 问题 | 示例答案 | 作用 |
|---|---|---|
| 触发条件 | 错误率超过阈值 | 定义什么算异常 |
| 持续多久 | 连续 5 分钟 | 滤掉瞬时抖动 |
| 严重级别 | P1 立即响应 / P2 工作时间处理 | 决定响应方式 |
| 做什么 | 扩容、回滚、切换兜底 | 让值班能直接动作 |
告警应当带上处置入口：Runbook 链接或值班群命令，把「怎么办」从人的记忆转移到系统里。
定期回看误报率：频繁误报的规则会被习惯性忽略，等同于没有告警；宁可先放宽阈值再加回，也不要长期挂着噪声。