监控指标设计

常见误区:监控所有可监控的指标

初学者搭建监控时,最常见的失败模式不是"漏了指标",而是"什么都监控,结果什么都看不出来":

一个仪表盘上挂了 80 个图表:CPU,内存,磁盘,网络,GC 次数,线程数,句柄数,各种内部计数器...凌晨告警触发,面对这 80 张图:哪个才是根因?哪些只是"跟随波动"的伴随现象?信息过载等同于没有信息,关键信号淹没在噪声中.

指标设计的核心不是"采集得多",而是"采集得准"--用尽量少的指标覆盖用户真正关心的系统健康度.要达成这一目标,需要先掌握方法论.而在方法论之前,应先认识指标的"基本构件".

四种指标类型:基本构件

几乎所有监控系统(尤其是第 03 篇将要介绍的 Prometheus)都围绕四种基本指标类型构建.混淆这些类型是初学者最常见的错误,下面逐一说明.

为什么延迟必须用 Histogram,而非平均值

这一点单独展开讨论,因为它至关重要,且在实践中经常被做错.假设要监控"接口延迟",直觉反应是计算平均延迟.但平均值会掩盖真实情况:

1000 个请求:
  990 个耗时 10ms,10 个耗时 5000ms(这 1% 的用户等待了 5 秒)

  平均延迟 = (990×10 + 10×5000) / 1000 ≈ 60ms   ← 看起来正常!
  但那 1% 的用户体验极差,平均值将他们"抹平"了

用户的真实体验隐藏于尾部.因此业界使用**百分位(Percentile)**来衡量:

• P50(中位数):50% 的请求比它快--代表"典型"体验
• P99:99% 的请求比它快,仅最慢的 1% 超过该值--代表"最差体验"的那一批用户

上述例子中,最慢的 1%(那 10 个请求)恰为 5000ms,因此 P99 ≈ 5000ms,立刻暴露了问题.Histogram 的价值正在于能够计算这些百分位--它将每个请求的耗时放入预设的桶(如 <10ms,<100ms,<1s),从分布反推百分位.监控延迟应始终关注 P99/P95,而非平均值.

该监控什么(一):四个黄金信号

了解了基本构件之后,回到核心问题:到底该监控哪些指标? Google SRE 给出的最经典答案是"四个黄金信号(Four Golden Signals)"--如果只能监控四类指标,就监控这四个:

一个常见错误:计算延迟时将失败请求混入统计,会导致严重失真.一次快速失败(如 50ms 即返回 500 状态码)会使延迟指标"看起来变快了"--但实际是错误率在上升.

务必分别统计成功请求和失败请求的延迟,否则两个问题会相互掩盖.

该监控什么(二):RED 与 USE,两个互补视角

黄金信号偏理念层面,落地时有两个更具操作性的方法,分别从"服务"和"资源"两个角度切入--二者恰好互补.

RED:以"服务"为中心

RED 专门面向请求驱动的服务(API,微服务),仅关注三个指标:

• Rate -- 每秒请求数(流量)
• Errors -- 每秒失败请求数(错误)
• Duration -- 请求耗时分布(延迟,关注 P99)

RED 的优势在于通用且统一:无论服务内部逻辑如何,这三个指标都适用.为每个微服务画上 RED 三条曲线,即可获得全局健康视图.回顾第 01 篇凌晨的告警--"下单 P99 超过 2 秒"正对应 RED 中的 D.

USE:以"资源"为中心

USE 面向资源(CPU,内存,磁盘,网络,连接池),关注三个维度:

• Utilization -- 利用率(资源有多忙,如 CPU 80%)
• Saturation -- 饱和度(排队等待程度,如 CPU 运行队列长度)
• Errors -- 错误数(如磁盘 I/O 错误)

将"系统状态"量化为数字:SLI/SLO/SLA

有了指标,还缺少一个关键的判断标准:多好才算"好"? P99 为 200ms 是否达标?错误率 0.5% 是否可接受?没有标准,告警阈值就只能凭感觉设置.SRE 用三个层层递进的概念来定义"好"的标准:

三者的关系:SLI 是实测数据,SLO 是内部设定的及格线,SLA 是写入合同对客户的承诺(通常比 SLO 更宽松,留出缓冲空间). 日常工程实践中最常使用的是 SLI 和 SLO.

错误预算:SLO 最重要的衍生产物

SLO 真正改变工程决策方式的,是由其推导出的错误预算(Error Budget).逻辑简洁但影响深远:

若 SLO = 99.9% 成功率
则允许的失败比例 = 100% - 99.9% = 0.1%
  → 这 0.1% 即"错误预算"

一个月约 43200 分钟,0.1% ≈ 43 分钟
  → 本月"可承受 43 分钟服务异常"而不违反 SLO

错误预算将"稳定性"从模糊的口号转化为可支配的额度,直接指导工程决策:

• 预算充裕 → 可以发布新版本,进行实验,上线有风险的新功能(还有试错空间)
• 预算即将耗尽 → 冻结发布,全力保障稳定,暂缓变更

承上启下

本篇解决了"监控什么,好坏的标准是什么"--这属于设计层面的问题,与具体工具无关.但纸面上的指标设计要转化为实际运行的监控系统,还需要一套机制去采集,存储,查询和告警.下一篇介绍的 Prometheus 正是这一领域的事实标准:Counter/Histogram 如何被采集,P99/错误率如何用 PromQL 计算,SLO 如何转化为一条实际生效的告警规则.