一、监控体系概述：目标、价值与核心指标
做监控这么多年，我最大的感触是：很多人把监控做成了“告警轰炸机”。服务器一抖，全员邮件；磁盘用了80%，半夜电话打起来。结果呢？运维团队疲于奔命，业务方却觉得“你们天天报警，系统也没见多稳”。
说白了，监控不是让你当“救火队员”的。它的真正目标只有三个：早发现、快定位、能预防。我习惯把监控的价值浓缩成一句话——用最小的成本，换取最大的系统可观测性。
监控的核心目标：
- 缩短故障发现时间（MTTD）——别等用户骂了才知道系统挂了
- 缩短故障定位时间（MTTR）——告警来了，能一眼看出问题在哪
- 提供容量规划依据——业务涨了，你知道该加机器还是该优化代码
1.1 黄金指标：四大信号与USE/RED方法论
聊监控指标，绕不开Google那套四大黄金信号。我在2016年第一次接触这个理论时，觉得“这不就是常识吗？”后来踩过坑才明白——常识和落地之间，隔着无数个不眠夜。
| 黄金信号 | 含义 | 典型指标 | 我踩过的坑 |
|---|---|---|---|
| 延迟（Latency） | 请求处理耗时 | P99、P95、平均响应时间 | 只看平均延迟，结果P99已经飙到10秒了 |
| 流量（Traffic） | 系统承载的请求量 | QPS、TPS、带宽使用率 | 流量突增时没告警，数据库连接池先爆了 |
| 错误（Errors） | 请求失败率 | HTTP 5xx、业务错误码、异常堆栈 | 只监控了HTTP状态码，漏掉了业务逻辑错误 |
| 饱和度（Saturation） | 资源耗尽程度 | CPU使用率、内存占用、磁盘IO等待 | CPU 95%才告警，其实80%时系统已经开始排队了 |
除了四大信号，还有两套方法论我经常混着用：USE 和 RED。它们不是互斥的，而是互补的。
我的个人习惯：
- 基础设施层（服务器、网络、存储）→ 用 USE（利用率、饱和度、错误）
- 应用服务层（API、微服务、中间件）→ 用 RED（速率、错误、耗时）
这样分层之后，告警清晰多了。不会出现“CPU高”和“接口慢”混在一起的情况。
1.2 USE方法论：基础设施的“体检报告”
USE是Brendan Gregg提出的，全称是Utilization、Saturation、Errors。说白了就是问三个问题：
- 利用率（Utilization）：资源被用了多少？比如CPU 70%、内存80%。
- 饱和度（Saturation）：资源有没有排队？比如CPU run queue长度、磁盘IO等待队列。
- 错误（Errors）：有没有报错？比如网卡丢包、磁盘坏道。
我曾经接手过一个项目，线上经常“卡死”。团队盯着CPU利用率看了三天，发现才60%，觉得没问题。我让他们查一下CPU run queue，结果队列长度一直在20以上。嗯，利用率低不代表不饱和——这是USE方法论教我最重要的一课。
避坑指南：我曾经只监控CPU利用率，忽略了饱和度指标。结果系统响应慢，CPU却显示“空闲”。后来加了run queue和上下文切换监控，才抓到真凶——频繁的线程上下文切换。
1.3 RED方法论：应用服务的“健康三要素”
RED是Tom Wilkie（Prometheus和Grafana的贡献者）提出的，专为微服务设计。三个字母对应：
- 速率（Rate）：每秒请求数（QPS）
- 错误（Errors）：失败请求数或失败率
- 耗时（Duration）：请求处理时间分布（P50、P95、P99）
你想想看，一个微服务只要盯住这三个维度，90%的问题都能暴露出来。我习惯在每个API网关层都埋上RED指标，配合Grafana做实时看板。有一次线上告警说“订单接口错误率飙升”，我打开看板一看：QPS没变，P99从200ms涨到了5s，错误率从0.1%跳到了15%。立刻定位到是数据库连接池泄漏——这就是RED的价值。
1.4 监控分层架构：从基础设施到业务
监控不能“一锅炖”。我见过很多团队把所有指标塞进一个Prometheus实例，结果查询慢、告警乱。我的建议是按层拆分，每层关注不同的指标和工具。
下面这张图是我自己总结的监控分层架构，你可以把它当成一个“监控地图”：
这张图我用了很多年，每次给团队讲监控架构都拿它当“地图”。从上到下，每一层都有自己关注的指标和工具，互不干扰，又相互关联。
1.5 各层监控的落地要点
光有架构图不够，落地才是硬功夫。我分别说说每层怎么搞：
基础设施层：别只盯着CPU
我见过最典型的错误：CPU告警阈值设成95%，磁盘告警设成90%。结果呢？CPU到80%时系统已经卡得不行了，因为上下文切换和IO等待早就爆了。
- CPU：除了利用率，还要看load average、run queue、上下文切换
- 内存：别只看used%，要看available、swap使用、page fault
- 磁盘：IOPS、吞吐量、await、queue depth——这四个缺一不可
- 网络：带宽、丢包率、重传率、连接数
我的经验：基础设施监控的告警阈值，建议用动态基线而不是固定值。比如CPU利用率，平时30%，突然跳到70%就要告警，而不是等到95%。我曾经用Prometheus的预测算法做过动态基线，效果比固定阈值好太多。
应用层：RED指标是底线
应用层监控，我要求团队必须做到：每个接口都有RED指标。没有例外。
- 速率：QPS突增或突降都要告警——突增可能被攻击，突降可能服务挂了
- 错误：HTTP 5xx、业务错误码、超时——分开统计，别混在一起
- 耗时：P50、P95、P99都要看。P50低但P99高，说明有长尾请求
我记得有一次，一个接口P50只有50ms，但P99到了3秒。业务方说“接口挺快的”，结果用户投诉“经常转圈”。这就是只看平均值的坑。
业务层：让老板也能看懂
业务层监控，说白了就是把技术指标翻译成业务语言。老板不关心CPU利用率，但关心“今天订单量跌了20%”。
- 核心业务指标：订单量、支付成功率、用户注册数、DAU
- 业务SLA：比如“下单成功率99.9%”、“页面加载时间<2秒”
- 告警方式：业务告警别发到技术群，要发到业务群，让产品和运营也能看到
避坑指南：我曾经把业务告警和技术告警混在一个群里，结果半夜告警刷屏，业务方被吵醒，技术方又觉得“这是业务问题，不归我管”。后来分开告警通道，技术告警走PagerDuty，业务告警走企业，世界清净了。
1.6 监控体系的价值：不只是“看数据”
说了这么多，监控体系到底值不值钱？我个人的答案是：值不值钱，取决于你能不能从数据里挖出价值。
我见过最成功的监控落地案例，是一个电商团队。他们通过监控发现：每天晚上8点到10点，数据库连接数飙升，但CPU利用率很低。排查后发现是ORM框架的懒加载导致大量短连接。优化后，数据库连接数降了60%，接口延迟降了40%。
这就是监控的价值——不是让你被动救火，而是让你主动优化。
总结一下本章核心：
- 监控的目标：早发现、快定位、能预防
- 黄金指标：延迟、流量、错误、饱和度
- USE方法论：基础设施层的“利用率、饱和度、错误”
- RED方法论：应用层的“速率、错误、耗时”
- 分层架构：基础设施→应用→业务，每层关注不同指标