4. 异常检测的指标体系：成功率、延迟、错误率、吞吐量
做线上异常检测，说白了就是盯着几个数字看。你不盯也行，等用户骂上门来再盯——但我劝你别这么干。
我个人习惯把指标分成四类：成功率、延迟、错误率、吞吐量。它们就像车上的四个仪表盘，少一个都可能翻车。
4.1 成功率 — 用户侧的金标准
成功率是最直接的。用户请求发出去，得到正常响应，就算成功。我一般用这个公式：
success_rate = total_success / total_requests * 100%你可能会问：那什么样的响应算“正常”？HTTP 200？业务返回码0？嗯，这里要注意，单纯看协议层成功是不够的。
我在项目中遇到过：有一次接口返回 HTTP 200，但业务 body 里塞了个 {"code":50001,"msg":"系统繁忙"}。前端照常渲染页面，用户却看到一片空白。如果你只盯 HTTP 状态码，根本发现不了问题。所以我建议：成功率必须分层监控。
- 协议层成功率 — 4xx/5xx 比例。
- 业务层成功率 — 调用方定义的业务成功标识。
- 用户感知成功率 — 页面加载/核心操作完成比例。
4.2 延迟 — 体验的体温计
延迟是最容易被误解的指标。平均值是个骗人的东西。你想想看：99%的请求都在 100ms 内完成，剩余1%卡了 30 秒，平均延迟还是漂亮的 400ms。你敢信吗？
所以我只看分位值：P50、P99、P999。日常监控我用这几个：
| 分位 | 含义 | 常用报警阈值（参考） |
|---|---|---|
| P50 | 一半请求比这个快 | 视服务而定，通常 100-500ms |
| P90 | 90%的请求比这个快 | 200-1000ms |
| P99 | 99%的请求比这个快 | 500-3000ms |
| P999 | 千分之九千九百九十九的请求比这个快 | ≥ 2000ms 基本就要告警了 |
我记得有一次：P50 稳如老狗，但 P99 从 300ms 飚到 8s。查了半天，发现是一个慢 SQL 没加索引，触发全表扫描。如果只看平均延迟，那根索引可能现在还躺在代码里。
4.3 错误率 — 出事的红色警报
错误率不只是 HTTP 500。我把它拆成三类：
- 协议错误：4xx 是客户端问题，5xx 是服务端问题。5xx 占比 > 1% 我就提告警。
- 业务错误：比如订单重复、余额不足。这类错误即使返回 200，也要计入错误率。
- 超时/熔断：调用下游超时、断路器等。这些往往是雪崩的前兆。
举个例子，一个接口平时 1000 QPS，错误率 0.5%。突然降到 10 QPS 时，一次错误就变成 10% 了。嗯，这时候报警，其实问题不大。所以我会加一个流量下限条件：错误率 > 1% 且 QPS > 50 才报警。
4.4 吞吐量 — 流量的水位线
吞吐量常用 QPS（每秒请求数）或 TPS（每秒事务数）。我不单看值，更关注变化趋势。
- 突增：可能被刷接口、活动引流、再或者是 DDoS。
- 突降：上游限流、上游挂掉、链路故障。
- 正常波动：业务周期性（白天高、凌晨低）。
我习惯把吞吐量跟成功率、延迟一起画在同一张时间轴上。你会看到很有意思的关联：
- 吞吐量上升 + 延迟下降 → 大概率是缓存生效了。
- 吞吐量上升 + 延迟上升 + 错误率上升 → 系统扛不住了。
- 吞吐量下降 + 成功率下降 → 上游或者网络有问题。
4.5 四指标联动：一张图看清全貌
单独的指标只能告诉你“这里不对劲”，但没法告诉你“为什么”。你需要把成功率、延迟、错误率、吞吐量放在一起看，才能定位根因。
下面这张 异常检测指标体系关联图 就是我日常诊断时脑海里自动浮现的画面：
4.6 实战：怎么建立指标体系？
我给新手团队的建议是：先上成功率+延迟P99，再加错误率和吞吐量。贪多嚼不烂。
- 第一步：每个接口记录耗时、结果码、请求量。用 Prometheus + Grafana 简单可视化。
- 第二步：设定第一层告警：成功率 < 99% 或 P99 > 2000ms 或 5xx > 1%。
- 第三步：加第二层告警：吞吐量突降 50% 或突增 3 倍（配合基线）。
- 第四步：做关联分析面板，把四个指标画在一张图上，人工找规律。
嗯，指标就这些。别觉得简单。越简单的东西，越容易在压力下变形。下次上线前，先问问自己：这四个仪表盘，你都盯着了吗？