📚 课程目录第2章核心指标定义

核心指标定义：延迟、流量、错误、饱和度

做监控这么多年，我见过太多团队一上来就堆指标。CPU、内存、磁盘、网络……铺了一屏，真出问题的时候，谁也说不清到底哪里先崩的。

后来我学乖了。Google 那篇 SRE 经典里提过一个方法，叫「四个黄金信号」。说白了，就是四个维度：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。你把这四个方向盯住了，系统的健康状况基本就捏在手里了。

四个黄金信号，到底在盯什么？

我习惯这么理解：

延迟——用户等多久？
流量——系统扛多少？
错误——哪里在坏？
饱和度——还能撑多久？

嗯，就这么简单。但落地的时候，坑不少。

延迟（Latency）

延迟不是平均值。平均值会骗人。我记得有一次，一个接口平均延迟 50ms，看起来挺漂亮。结果一查 P99，好家伙，2 秒。为什么？因为 99% 的请求都很快，但剩下那 1% 慢到离谱，直接把用户体验拉垮了。

所以我建议，延迟指标至少看三个分位：

分位	含义	典型阈值（参考）
P50	一半用户感受到的延迟	< 200ms
P95	95% 用户都能接受的延迟	< 500ms
P99	最慢 1% 用户的体验	< 1s

注意： 延迟一定要区分「客户端感知延迟」和「服务端处理延迟」。中间可能隔着网络、负载均衡、缓存。我曾经踩过这个坑——服务端延迟 10ms，客户端测出来 800ms，查了半天发现是 CDN 回源配置错了。

流量（Traffic）

流量就是系统的「吞吐量」。对于 Web 服务，看 QPS（每秒请求数）或 RPS（每秒请求数）。对于数据库，看 TPS（每秒事务数）和读写比例。对于消息队列，看吞吐速率和积压量。

流量指标的核心价值，是帮你判断系统是否在「正常范围」内。我习惯把流量拆成三块：

正常流量基线——日常峰值是多少？
异常流量尖刺——突然翻倍了？是促销还是攻击？
流量趋势——周同比、月环比，是涨是跌？

你想想看，如果流量突然掉到零，那比飙高更可怕——说明系统可能已经挂了，连请求都进不来了。

错误（Errors）

错误分两种：显式错误和隐式错误。

显式错误：HTTP 5xx、4xx、超时、连接拒绝。这些一目了然。
隐式错误：HTTP 200 但返回了错误码、业务逻辑异常、数据不一致。这些最坑人。

我曾经遇到过一个问题：接口返回 200，但 body 里有个字段叫 success: false。监控系统没报警，因为只看 HTTP 状态码。结果业务方投诉了两天才发现。从那以后，我要求所有核心接口必须暴露业务错误率指标。

我的习惯： 错误率阈值不要设成 0%。系统总有抖动，设 0% 会频繁误报。一般我会设 0.1% ~ 1%，根据业务容忍度调整。

饱和度（Saturation）

饱和度是最容易被忽略的指标。它告诉你系统「还有多少余量」。CPU 使用率 90% 不代表马上要崩，但说明你离极限很近了。

我常用的饱和度指标：

CPU 使用率 + 负载均值——负载超过 CPU 核数时，说明在排队了。
内存使用率 + 交换分区使用量——开始 swap 就危险了。
磁盘 I/O 队列深度——队列深了，读写延迟必然飙升。
连接池/线程池使用率——池子满了，新请求只能等或丢。

饱和度有个好处：它是「提前量」。延迟和错误是已经发生的事，饱和度是即将发生的事。你盯着饱和度，往往能在用户感知到问题之前就动手。

从指标到 SLO / SLI / SLA

指标有了，怎么用？这就引出了三个概念：SLI、SLO、SLA。很多人搞混，我画个图帮你理清关系。

SLI：你测了什么？

SLI（Service Level Indicator）就是可量化的测量值。从四个黄金信号里选，比如：

延迟 SLI：P99 请求延迟
流量 SLI：每分钟请求数
错误 SLI：5xx 错误率
饱和度 SLI：CPU 使用率

选 SLI 的时候，我有个原则：选用户能感知到的。你内部磁盘 I/O 再高，用户不关心。用户只关心页面打不打得开、数据对不对。

SLO：你承诺了什么？

SLO（Service Level Objective）是目标值。格式一般是：「指标」在「时间窗口」内达到「阈值」。

举个例子：

SLO: P99 延迟 < 500ms，在 30 天滚动窗口内达到 99.9%

什么意思？就是说，过去 30 天里，99.9% 的时间，P99 延迟都在 500ms 以下。剩下 0.1% 的时间（大约 43 分钟）可以超标。

关键点： SLO 不是「永远不超」，而是「超了多久算违约」。你给自己留点余量，别把 SLO 设得太紧，否则天天报警，团队会麻木。

SLA：合同上写了什么？

SLA（Service Level Agreement）是跟客户签的合同。它通常比 SLO 宽松。为什么？因为你要给自己留缓冲。内部 SLO 是 99.9%，对外 SLA 可能只承诺 99.5%。这样即使内部偶尔抖动，也不至于触发赔偿。

我见过最惨的案例：某公司把内部 SLO 直接当 SLA 签了，结果一次故障赔了上百万。嗯，从那以后，他们 CFO 亲自参与 SLA 评审。

如何定义一套可落地的 SLO？

我总结了一个四步法：

选 SLI：从四个黄金信号里挑 3~5 个核心指标。
定阈值：参考历史数据，找到「正常」和「异常」的分界线。
设时间窗口：一般用 28 天或 30 天滚动窗口，避免「月初清零」的错觉。
定目标百分比：从 99% 开始，逐步提升到 99.9%、99.99%。别一步到位。

举个例子，一个典型的 Web 服务 SLO 定义：

SLI	阈值	时间窗口	目标
P99 延迟	< 500ms	30 天滚动	99.9%
错误率	< 0.1%	30 天滚动	99.95%
可用性	服务可访问	30 天滚动	99.99%

小技巧： 刚开始做 SLO 的时候，别追求完美。先定一个「够用」的目标，跑两个月，看看实际达标率，再调整。我第一版 SLO 经常被打脸，但迭代几次后就稳了。

避坑指南

最后，分享几个我踩过的坑：

别只看平均值——平均值会掩盖问题。P99 才是用户真实体验。
别设太多 SLO——3~5 个就够了。超过 10 个，团队根本记不住。
别把 SLO 当 SLA 用——内部目标和外部承诺要分开。
别忘了「错误预算」——SLO 没达标的时间就是你的错误预算。用完了，就该停止发布、全力修 bug。

嗯，这一章的内容差不多就这些。四个黄金信号是基础，SLI/SLO/SLA 是上层建筑。先把指标定义清楚，后面的监控、告警、容量规划才有根。