限流上线之后：API 网关该盯的三个指标

上篇聊了限流的三层设计（单机、分布式、入口），有个问题被留到了今天：限流上线只是起点，出了事「到底是谁被限了、为什么被限」答不上来，限流就只是一颗随时会被挑战的定时炸弹。

这篇文章给网关可观测性划个最小集合：三个指标，一套结构化日志，两个告警原则。

指标一：限流拒绝率（按路由维度）

拒绝率 = 被限流请求 / 总请求，必须按路由（而不是全局）统计。

全局拒绝率是个安慰剂：核心交易路由被限 3% 和边缘爬虫路由被限 30%，在全站大盘上都可能只是「0.8% 的毛刺」。按路由拆开后，每一条突增都能回答一个问题——

• 同步突增 + 上游变慢：大概率是上游服务拖长了请求周期，并发配额被占满，先查上游再骂限流
• 突增 + 上游正常：要么是流量攻击，要么是某个调用方重试风暴，去看调用方指纹
• 平稳抬升：业务真实增长撞到配额天花板，该调阈值了

指标二：上游饱和度

网关限的是并发，饱和度看的是水位：当前并发连接数 / 最大并发配额。

这个指标回答「限流阈值定得对不对」。长期水位低于 30% 说明配额给多了在浪费；长期高于 80% 说明阈值贴着天花板，任何一个上游抖动都会被放大成大面积拒绝。

实践上建议同时记录队列等待时间：请求从进入网关到拿到上游连接的间隔。它涨了，说明请求在网关里排队——用户体验已经开始劣化，但拒绝率还是零。这是最容易被忽略的「隐性限流」。

指标三：P99 分段延迟

把一次请求的耗时拆成三段分别打点：网关自身处理、上游服务响应、网络传输。只看总 P99 的话，三段的锅混在一起，排查时永远在吵架。

分段之后结论非常干净：网关段稳定、上游段抖动 = 下游服务的锅；网关段跟着并发水位一起涨 = 网关自身到瓶颈了；两段都稳但总延迟高 = 查网络和序列化。

结构化日志：三个指标的落地载体

指标是聚合视图，排查靠明细。网关访问日志至少要带这些字段：路由 ID、调用方标识、限流动作（通过/拒绝/排队）、三段耗时、上游状态码。有了这些，一次「某调用方反馈偶发超时」的排查从翻日志变成一条过滤查询。

两个告警原则

1. 拒绝率告警看变化率不看绝对值：每条路由的正常水位不同，静态阈值天天误报。环比突增 3 倍再报警，噪音小得多
2. 饱和度告警要分两档：80% 预警（该评估扩容了）、95% 紧急（马上要影响请求了）。挤成一档的告警等于没有告警

一个真实案例的形状

某次拒绝率从 0.2% 爬到 5%，按上面的路径查：上游饱和度 96% —— 上游连接池被慢查询拖住 —— 请求在网关排队后超时拒绝。根因不在网关也不在限流，在一条漏了索引的 SQL。如果只看「被限数量」这个单一指标，这口锅会在网关和业务团队之间来回飞一周。

限流管住了流量，可观测性管住了真相。三个指标 + 一份带字段的日志，是我在两次事故学费之后保留的最小集合。