一、监控体系总览：为什么需要监控？

说实话，我见过太多团队把监控当成「事后诸葛亮」——系统挂了才想起来看监控。这其实是个误区。监控不是用来背锅的，它是你运维工作的「仪表盘」。

我记得刚带团队那会儿，有个核心服务半夜挂了，报警电话打到我手机上。我爬起来一看，CPU 跑满了，内存也快爆了。但问题是——这些指标我平时根本不看。为什么？因为没人告诉我哪些指标真正重要。

后来我花了整整两周，把整个监控体系重新梳理了一遍。今天这第一节课，我就把当时总结出来的核心思路分享给你。

1.1 为什么需要监控？

说白了，监控就干三件事：

• 发现问题：系统出故障了，你得第一时间知道。不是等用户投诉了才后知后觉。
• 定位问题：知道出问题了还不够，你得能快速找到根因。是数据库慢了？还是网络抖了？
• 预测问题：这是高阶玩法。通过趋势分析，在故障发生前就提前干预。比如磁盘快满了，提前扩容。

1.2 监控的黄金指标

指标那么多，到底该看哪些？我个人的习惯是，先记住三套经典方法论：USE、RED 和 Four Golden Signals。

USE 方法（资源视角）

USE 是 Brendan Gregg 提出的，专门用来分析资源瓶颈。每个字母代表一个维度：

字母	含义	说明
Utilization	利用率	资源被使用的百分比。比如 CPU 使用率 80%
Saturation	饱和度	资源还有多少余量。比如 CPU 运行队列长度
Errors	错误数	资源层面的错误计数。比如网卡丢包数

我举个例子。有一次线上 MySQL 响应变慢，我第一反应是看 CPU 利用率——才 30%，不高。但再看饱和度，磁盘 I/O 等待队列排了上百个任务。嗯，问题找到了：磁盘 I/O 是瓶颈，不是 CPU。

RED 方法（服务视角）

RED 是 Tom Wilkie 提出的，专门用来监控微服务。它关注的是请求维度的三个指标：

字母	含义	说明
Rate	请求速率	每秒处理多少请求（QPS）
Errors	错误率	请求失败的百分比
Duration	响应时长	请求处理耗时（通常看 P99、P95）

我记得有一次排查线上问题，Rate 正常，Errors 也正常，但用户就是觉得卡。后来一看 Duration 的 P99——从 200ms 飙到了 2s。原来是有少量慢查询拖垮了整体体验。

Four Golden Signals（Google SRE 视角）

Google 的 SRE 团队总结了四个黄金信号，可以说是监控界的「宪法」：

1. 延迟（Latency）：请求处理耗时。注意区分成功请求和失败请求的延迟。
2. 流量（Traffic）：系统承载的请求量。比如 QPS、带宽使用量。
3. 错误（Errors）：显式错误（如 HTTP 500）和隐式错误（如返回了错误数据但状态码是 200）。
4. 饱和度（Saturation）：系统资源还有多少余量。比如内存使用率、磁盘 I/O 等待。

你想想看，这四个信号覆盖了从用户感受到资源瓶颈的全链路。我每次搭建新系统的监控，都会先问自己：这四个信号我都能采集到吗？

1.3 监控体系分层架构

指标有了，但怎么组织？我习惯把监控体系分成三层：指标（Metrics）、日志（Logs）、链路（Traces）。业内也叫「可观测性三大支柱」。

下面这张图是我自己画的，帮你快速理解这三层的关系：

第一层：指标（Metrics）

指标是数字化的、可聚合的数据。比如 CPU 使用率、QPS、P99 延迟。它的特点是：轻量、高效、适合告警。

我一般用 Prometheus 采集指标，Grafana 做可视化。这套组合拳打了好多年，稳得很。

第二层：日志（Logs）

日志是离散的、带时间戳的事件记录。比如应用打印的 error log、Nginx 的 access log。它的特点是：信息丰富、适合排查细节。

但日志有个坑——量太大了。我曾经见过一个团队，每天产生 10TB 日志，结果 Elasticsearch 集群直接被打爆。所以日志一定要做采样和分级。

第三层：链路（Traces）

链路追踪记录一个请求从入口到出口经过的所有服务。比如你用 Jaeger 或 Zipkin，能看到请求在 A 服务花了 100ms，在 B 服务花了 500ms——瓶颈一目了然。

我记得有一次排查一个跨服务调用超时的问题。指标显示整体延迟高，日志里也没报错。最后是链路追踪告诉我：请求在 C 服务阻塞了，因为 C 服务连的数据库连接池满了。没有链路，这个根因我可能要找半天。

1.4 三层如何协同？

这三层不是孤立的。我举个例子你就明白了：

1. 指标告警：Grafana 弹出告警，说订单服务的 P99 延迟从 200ms 涨到了 2s。
2. 日志排查：你登录到订单服务的日志里搜索 ERROR，发现大量数据库连接超时的报错。
3. 链路定位：打开 Jaeger，找到一条慢请求的 trace，发现是订单服务调用了库存服务，库存服务又调用了数据库——数据库响应时间占了 1.8s。

你看，指标告诉你「出问题了」，日志告诉你「是数据库连接超时」，链路告诉你「具体是哪个调用链慢」。三层配合，根因定位效率翻倍。