一、监控体系概述：为什么需要监控、黄金指标与分类层次

大家好，我是你们这门课的老朋友。今天咱们正式开篇，聊聊监控体系。

说实话，我见过太多团队把监控当成「事后诸葛亮」——系统崩了才去看监控，然后拍大腿。这其实完全搞反了。监控不是用来背锅的，它是你掌控系统的眼睛和手。

1.1 为什么需要监控？

先问个问题：你凭什么说你的系统是健康的？

凭感觉？凭用户没投诉？那太危险了。我经历过一次线上事故，数据库连接池被打满，业务接口超时率飙到 60%，但用户反馈还没到，我们完全没察觉。等发现时，已经影响了十几分钟。

监控的核心价值，说白了就三件事：

• 发现异常——在用户骂娘之前，你先知道出事了。
• 定位根因——出事了，能快速找到是哪个环节的锅。
• 指导优化——通过长期趋势，知道哪里该扩容、哪里该重构。

我个人习惯把监控分成两个层面：「可观测性」和「告警」。可观测性让你看得见，告警让你被叫醒。两者缺一不可。

1.2 监控的黄金指标

指标那么多，到底该看哪些？业界有几个经典方法论，我挨个说说。

1.2.1 Four Golden Signals（Google SRE 四大黄金信号）

这是 Google SRE 团队总结的四个核心维度，我当年第一次看到时觉得「就这么点？」，后来发现，真能把这四个维度做扎实的系统，基本不会出大乱子。

信号	含义	典型指标
延迟（Latency）	请求处理耗时	P50/P95/P99 响应时间
流量（Traffic）	系统承载的请求量	QPS、RPS、带宽使用率
错误（Errors）	请求失败率	HTTP 5xx、业务错误码、超时数
饱和度（Saturation）	资源被占用的程度	CPU 使用率、内存占用、连接池水位

1.2.2 USE 方法（Utilization、Saturation、Errors）

这个方法主要针对资源层面，比如 CPU、内存、磁盘、网络。Brendan Gregg 大神提出的，我特别喜欢它的简洁性。

• Utilization（利用率）：资源被使用的百分比。比如 CPU 80%，磁盘 IO 60%。
• Saturation（饱和度）：资源排队等待的程度。比如 CPU 运行队列长度、磁盘 IO 等待队列。
• Errors（错误）：资源层面的错误计数。比如磁盘坏道、网卡丢包。

举个例子，你发现磁盘利用率才 40%，但业务响应很慢。这时候看饱和度——磁盘 IO 等待队列可能已经排了 100 个任务。这就是 USE 方法的威力：帮你找到「看起来不忙，其实已经堵死了」的问题。

1.2.3 RED 方法（Rate、Errors、Duration）

这个方法主要针对服务层面，特别是微服务架构。我自己的团队就在用这套。

• Rate（速率）：每秒请求数。
• Errors（错误）：失败请求数。
• Duration（持续时间）：请求耗时分布。

你看，RED 和 Four Golden Signals 其实很像，只是把「饱和度」去掉了，更聚焦在服务本身的健康度上。饱和度更多是资源层面的关注点。

1.3 监控的分类与层次

监控不是一锅粥，它是有层次的。我习惯把监控体系分成四层，从下往上依次是：

1. 基础设施层——服务器、网络、机房。
2. 系统资源层——CPU、内存、磁盘、网络 IO。
3. 应用服务层——业务接口、中间件、数据库。
4. 业务指标层——订单量、用户活跃度、转化率。

每一层关注的点不一样，告警的紧急程度也不一样。比如基础设施层的「机房断电」是 P0 级事故，而业务指标层的「某渠道转化率下降 5%」可能只是 P3 级观察。

下面这张图可以帮你直观理解这个分层结构：

你想想看，如果只盯着业务指标，发现订单量跌了，但你不知道是数据库慢了还是网络断了，那排查起来就像大海捞针。反过来，如果只盯着 CPU，发现飙到 90%，但业务没受影响，那这个告警其实没什么意义。

所以，监控一定要分层建设，上下打通。上层告警触发时，下层要有对应的指标可以下钻分析。这是我做监控架构最核心的原则。

1.4 小结

这一章我们聊了监控的必要性、三大黄金指标方法论（Four Golden Signals、USE、RED），以及监控的四层分类。说白了，监控不是堆工具、堆指标，而是建立一套从「看得见」到「看得懂」再到「能自动处理」的体系。

嗯，这里要注意：不要试图一开始就把所有指标都接进来。我建议先从四大黄金信号入手，把延迟、流量、错误、饱和度这四类指标跑通，再逐步扩展。贪多嚼不烂，这是很多监控项目失败的原因。