监控指标体系：四大黄金信号与自定义指标设计
聊到监控，很多人第一反应就是「把CPU、内存、磁盘这些基础指标全采了」。嗯，我刚开始做运维时也这么干过。结果呢？告警铺天盖地，真正出问题的时候反而被淹没了。
后来我接触到Google的SRE理念，才明白一个道理：监控不是越多越好，而是越准越好。今天我们就来聊聊监控指标体系的核心——四大黄金信号，以及如何设计自定义指标。
一、四大黄金信号：你的系统健康体检表
Google SRE团队总结出四个最关键的监控维度，说白了就是：快不快、多不多、稳不稳、满不满。
1. 延迟（Latency）——用户感知的第一道门槛
延迟就是请求从发出到收到响应的时间。我习惯把它分成两部分看：
- 服务端延迟：应用处理请求花了多久
- 网络延迟：数据在网络上传输的时间
这里有个坑。我曾经遇到一个案例：接口平均延迟只有200ms，看起来很正常。但仔细一看P99延迟，好家伙，直接飙到5秒。为什么？因为少数慢请求把平均值拉高了，但平均值又把它们「平均」掉了。
关键指标建议：
- P50（中位数）：代表大多数用户的体验
- P95/P99：代表最差情况下的体验
- P999：代表极端情况，一般用于核心交易链路
我个人习惯把P99延迟作为核心告警指标。如果P99超过1秒，说明系统已经出现明显瓶颈了。
2. 流量（Traffic）——系统到底在扛多少活
流量指标回答的是：系统当前处理的请求量有多大？
不同系统有不同的衡量方式：
| 系统类型 | 流量指标 | 说明 |
|---|---|---|
| Web服务 | QPS（每秒请求数） | 最常用的流量指标 |
| 数据库 | TPS（每秒事务数） | 关注读写事务量 |
| 消息队列 | 吞吐量（条/秒） | 生产和消费速率 |
| CDN/网关 | 带宽（Mbps） | 网络流量大小 |
你想想看，如果流量突然暴涨，但延迟没变，说明系统扛得住。如果流量没变，延迟却飙升了，那多半是系统内部出了问题。
3. 错误（Errors）——最不能忽视的信号
错误指标分两类：
- 显式错误：HTTP 5xx、4xx，业务返回的错误码
- 隐式错误：返回码是200，但业务逻辑错了（比如返回了空数据）
我曾经踩过一个坑：有一次线上告警说错误率飙升到5%，我一看全是404。心想404不算服务端错误，就没当回事。结果发现是某个核心接口的URL被改了，前端没同步更新。从那以后，我把4xx也纳入了错误监控范围。
错误率怎么算？我建议用这个公式：
错误率 = 错误请求数 / 总请求数 × 100%一般建议错误率超过1%就触发告警，核心链路可以更严格，比如0.1%。
4. 饱和度（Saturation）——系统还能撑多久
饱和度衡量的是系统资源被占用的程度。说白了就是：你的系统还有多少余量？
常见的饱和度指标：
- CPU使用率：超过80%就要注意了
- 内存使用率：关注的是实际使用量，不是分配量
- 磁盘I/O：iowait高说明磁盘是瓶颈
- 连接数：数据库连接池、线程池的使用率
- 队列长度：请求在排队等待处理的数量
我个人最看重的饱和度指标是队列长度。因为CPU和内存可能瞬间飙升，但队列长度能提前告诉你：系统快撑不住了。
二、自定义指标设计：别被标准指标框住
四大黄金信号是基础，但每个业务都有自己的特殊性。我见过太多团队只盯着CPU和内存，结果业务出问题了还不知道。
1. 什么时候需要自定义指标？
- 标准指标无法反映业务健康度
- 需要监控特定的业务逻辑
- 想提前发现潜在问题
举个例子。我之前负责一个电商平台，标准指标都正常，但用户反馈下单慢。后来我加了一个自定义指标：「从点击下单到收到确认的耗时」。结果发现这个耗时经常超过10秒，但系统层面的延迟只有200ms。问题出在哪？前端到后端的网络链路上。
2. 自定义指标设计原则
我总结了几条经验：
- 业务相关：指标要能反映用户体验或业务状态
- 可量化：必须是数值，不能是「好/坏」这种定性描述
- 可对比：能跟历史数据做对比，看出趋势
- 可告警：能设定阈值，触发告警
设计自定义指标时，我习惯先问自己三个问题：这个指标能帮我发现什么问题？发现问题后我能做什么？这个指标会不会产生太多噪音？
3. 常见的自定义指标类型
| 类型 | 示例 | 说明 |
|---|---|---|
| 业务指标 | 订单转化率、支付成功率 | 直接反映业务健康度 |
| 用户体验指标 | 页面加载时间、首屏渲染时间 | 从用户视角衡量 |
| 依赖指标 | 第三方API调用成功率 | 监控外部依赖的健康状态 |
| 容量指标 | 数据库连接池使用率 | 提前发现资源瓶颈 |
三、指标采集策略：怎么采才靠谱？
指标设计好了，采集方式不对也是白搭。我见过不少团队，指标设计得挺好，但采集策略一塌糊涂。
1. 采集方式选择
目前主流的有三种：
- Pull模式：监控系统主动去拉取指标（Prometheus就是这种）
- Push模式：应用主动把指标推送到监控系统
- 混合模式：两者结合
我个人更推荐Pull模式。为什么呢？因为Push模式容易导致数据丢失——应用挂了，指标就推不出去了。而Pull模式可以知道「这个应用是不是还活着」。
2. 采集频率怎么定？
不是越快越好。采集频率太高，存储和网络开销都大。我一般这样定：
| 指标类型 | 推荐采集频率 | 说明 |
|---|---|---|
| 系统指标（CPU、内存） | 15-30秒 | 变化较快，需要高频采集 |
| 业务指标 | 1-5分钟 | 变化相对缓慢 |
| 自定义指标 | 1-5分钟 | 根据业务重要性调整 |
| 长周期指标 | 5-15分钟 | 比如日活、月活 |
注意：采集频率不是越高越好。我曾经把采集频率设成5秒，结果Prometheus的存储直接爆了。后来改成15秒，数据量降了三分之二，但该发现的问题一个都没漏。
3. 指标命名规范
这个看似小事，但做不好后期维护会非常痛苦。我建议用这种格式：
namespace:metric_name:labels
# 示例
app:request_latency_seconds:method=POST,status=200
db:connection_pool_usage:db_name=orders
business:order_success_rate:region=cn-east命名规范的好处是：一眼就能看出这个指标属于哪个系统、什么类型、有哪些维度。
四、实战经验总结
说了这么多，最后分享几条我踩过的坑：
- 不要只关注平均值：平均值会掩盖问题，一定要看分位值
- 指标不是越多越好：每个指标都要有明确的用途，否则就是噪音
- 告警阈值要动态调整：业务高峰期和低谷期的阈值应该不一样
- 定期清理无用指标：我每季度会做一次指标清理，把没人看的指标删掉
最后说一句：监控体系不是一蹴而就的。先搭好四大黄金信号，再逐步补充自定义指标。别想着一步到位，那样反而容易把自己搞晕。