监控指标体系设计：如何定义API服务的核心SLA指标？
说实话，我刚带团队那会儿，最头疼的就是跟业务方对SLA。他们总问：「你们的API到底稳不稳？」我要是回一句「挺稳的」，那基本等于没说话。后来我学乖了——得把「稳」拆成几个能拿数字说话的东西。
今天咱们就聊聊这四个核心指标：延迟、错误率、吞吐量、数据新鲜度。这四兄弟，你盯住了，API服务的基本盘就稳了。
延迟（Latency）：用户等得起吗？
延迟说白了，就是用户发一个请求，到收到响应，中间花了多久。我习惯把它分成三块看：
- 网络延迟：数据在链路上跑的时间。这个往往不归你管，但得心里有数。
- 服务处理延迟：你的代码真正干活的时间。这是优化的主战场。
- 排队延迟：请求到了，但线程池满了，在队列里等着。嗯，这个最容易出幺蛾子。
我一般不会只看平均值。为什么？因为平均值会骗人。你想想看，99%的请求都在10ms内返回，突然有一个请求卡了5秒，平均值一拉，好像还行。但那个等了5秒的用户，可能已经骂娘了。
我的建议是：重点关注 P99（99分位延迟） 和 P999（99.9分位延迟）。P99告诉你，最慢的1%请求有多慢。P999告诉你，最慢的0.1%有多离谱。
举个例子，我之前维护过一个订单查询API。P50延迟只有20ms，看着挺美。但P99经常跳到800ms。一查，发现是某些大商户的订单数据量特别大，查询走了全表扫描。后来加了索引，P99直接降到80ms。你看，不看分位值，你根本不知道问题在哪。
| 指标 | 含义 | 我常用的阈值 |
|---|---|---|
| P50 | 一半请求比这个快 | ≤ 100ms |
| P99 | 99%请求比这个快 | ≤ 500ms |
| P999 | 99.9%请求比这个快 | ≤ 2s |
一个小技巧：监控延迟时，把时间窗口设成1分钟。太短了抖动大，太长了问题发现不及时。1分钟刚好能看出趋势，又不会太敏感。
错误率（Error Rate）：到底崩没崩？
错误率这个指标，看着简单，其实坑不少。很多人只盯着5xx，觉得只要5xx不高，服务就是健康的。但你想过没有，4xx算不算错误？
我个人习惯把错误分成三类：
- 客户端错误（4xx）：比如参数传错了、鉴权失败了。这类错误通常不算服务故障，但如果突然飙升，说明客户端可能出了bug，或者有人在扫你的接口。
- 服务端错误（5xx）：这才是真正的「服务挂了」。500、502、503，每一个都值得你半夜爬起来看。
- 业务错误（自定义错误码）：比如「库存不足」、「余额不够」。这类错误HTTP状态码可能是200，但业务逻辑上失败了。我见过最惨的一次，业务方说「接口返回都是200啊」，结果一看body里的错误码，90%都是「查询超时」。
我曾经踩过一个坑：只监控了HTTP 5xx，没监控业务错误码。结果有一次数据库连接池满了，所有请求都返回了HTTP 200，但body里全是「服务繁忙，请稍后重试」。业务方投诉了半小时，我才发现。从那以后，我所有的监控都加上了业务错误码的维度。
错误率的阈值怎么定？我一般这么设：
- 5xx错误率：超过0.1%就要告警。超过1%就是严重事故。
- 4xx错误率：超过5%需要关注，但不用半夜处理。
- 业务错误率：这个得看具体业务。比如支付接口，业务错误率超过1%就得马上排查。
吞吐量（Throughput）：能扛住多大流量？
吞吐量，就是单位时间内你的API能处理多少请求。常用的单位是QPS（每秒查询数）或RPS（每秒请求数）。
这里有个常见的误区：很多人觉得吞吐量越高越好。其实不对。吞吐量必须跟延迟放在一起看。你想想看，如果吞吐量上去了，但P99延迟从100ms飙到了2s，那这个吞吐量有什么意义？
我习惯用「吞吐量-延迟曲线」来判断系统的真实容量。简单说，就是逐步加压，看延迟什么时候开始急剧上升。那个拐点，就是系统的最佳负载点。
我的经验是：生产环境的实际QPS，最好不要超过压测得出的最佳负载点的70%。留30%的余量，给突发流量和故障恢复用。
举个例子，我之前做过一个压测：
| QPS | P99延迟 | 状态 |
|---|---|---|
| 1000 | 50ms | 正常 |
| 2000 | 80ms | 正常 |
| 3000 | 200ms | 拐点出现 |
| 3500 | 1.2s | 过载 |
你看，3000 QPS的时候延迟开始明显上升。所以这个系统的最佳负载就是3000 QPS，生产上我建议控制在2100 QPS以内。
数据新鲜度（Data Freshness）：数据够「新」吗？
这个指标，很多做API监控的人会忽略。但如果你做的是数据类API——比如用户画像、实时推荐、库存查询——数据新鲜度比延迟还重要。
数据新鲜度，衡量的是从数据产生，到API能查到这条数据，中间隔了多久。说白了，就是数据延迟。
我遇到过最典型的场景：电商大促期间，库存API的数据新鲜度从5秒降到了5分钟。结果用户下单时显示有货，支付完却被告知「库存不足」。那场面，客服电话直接被打爆。
数据新鲜度的监控，我一般分三步走：
- 定义数据源：你的数据是从哪来的？数据库？消息队列？缓存？
- 标记时间戳：每条数据写入时，带上一个「数据产生时间」。API返回时，带上一个「数据查询时间」。
- 计算差值：数据新鲜度 = 数据查询时间 - 数据产生时间。
一个小建议：在API的响应头里加一个自定义字段，比如 X-Data-Freshness，直接返回当前数据的新鲜度（单位秒）。这样客户端也能感知到数据是不是够新，方便做降级或提示。
数据新鲜度的阈值，我一般这么设：
- 实时类API（如库存、价格）：新鲜度 ≤ 10秒。
- 准实时类API（如订单状态）：新鲜度 ≤ 1分钟。
- 离线类API（如报表、统计）：新鲜度 ≤ 1小时。
四个指标的关系：一张图说清楚
这四个指标不是孤立的。它们互相影响，牵一发而动全身。我画了张图，帮你理清它们的关系：
怎么给这四个指标定SLA？
指标定义清楚了，接下来就是定SLA。我见过很多团队，SLA定得特别「完美」，但根本执行不了。为什么？因为没考虑成本。
你想想看，要把P99延迟从100ms降到50ms，可能得加机器、改架构、上缓存。这些都要钱。所以SLA不是越高越好，而是在成本和用户体验之间找到平衡。
我一般这么定：
- 核心API（比如登录、支付、下单）：P99 ≤ 200ms，错误率 ≤ 0.1%，可用性 ≥ 99.99%。
- 重要API（比如商品详情、用户信息）：P99 ≤ 500ms，错误率 ≤ 0.5%，可用性 ≥ 99.9%。
- 普通API（比如历史记录、配置查询）：P99 ≤ 2s，错误率 ≤ 1%，可用性 ≥ 99.5%。
注意：SLA不是定完就完事了。你得定期复盘。我每个季度都会拉一次SLA达成率，看看哪些指标经常「亮红灯」。如果某个指标连续三个月都达标，我会考虑是不是定得太松了。反过来，如果某个指标总是告警，那就得想想，是系统真的扛不住，还是SLA定得太严了。