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

大家好，我是你们的运维老司机。今天咱们聊聊监控体系——这个听起来有点虚、但实际干起来全是坑的话题。

说实话，我见过太多团队了。一上来就装 Prometheus、配 Grafana，整得花里胡哨的。结果呢？线上挂了，翻半天仪表盘，啥也没看出来。为什么？因为根本不知道自己要监控什么。

所以这一章，咱们先把地基打牢。搞清楚三个问题：为什么要监控？监控什么？怎么组织监控？

1.1 为什么需要监控？—— 别等用户骂你才醒

你可能觉得，监控不就是看看 CPU、内存吗？嗯，没那么简单。

我个人的理解是：监控是运维的眼睛和耳朵。没有监控，你就是在黑灯瞎火里修机器。

具体来说，监控解决三个核心问题：

• 发现问题 —— 系统挂了，你得第一个知道，而不是等用户投诉。
• 定位问题 —— 是数据库慢了？还是网络堵了？监控能帮你缩小范围。
• 预测问题 —— 磁盘快满了、流量在暴涨，提前预警，别等崩了再救火。

1.2 监控的黄金指标 —— 到底该看什么？

好，既然要监控，那看什么指标？业界有三大经典方法论，我一个个说。

1.2.1 USE 方法 —— 资源视角

USE 是 Brendan Gregg 大佬提出的，专门针对资源的监控。说白了就是看每个资源：

• Utilization（利用率） —— 资源忙不忙？比如 CPU 用了 90%。
• Saturation（饱和度） —— 资源排队了没？比如磁盘 I/O 队列长度。
• Errors（错误） —— 出错了没？比如网卡丢包。

举个例子，看一台服务器：

资源	利用率	饱和度	错误
CPU	85%	运行队列 3	0
内存	70%	Swap 使用 200MB	0
磁盘	60%	I/O 等待 5%	磁盘坏道 1

你看，一眼就能看出磁盘有错误，赶紧换盘。这就是 USE 的威力。

1.2.2 RED 方法 —— 服务视角

RED 是 Google 的 SRE 团队提出的，针对服务的监控。三个字母：

• Rate（速率） —— 每秒多少请求？
• Errors（错误） —— 请求失败了多少？
• Duration（持续时间） —— 请求耗时多久？

说白了，就是看你的 API 接口：

• QPS 多少？
• 5xx 错误率多少？
• P99 延迟多少？

1.2.3 四大黄金信号 —— 全局视角

Google SRE 还提出了四大黄金信号，比 RED 更全面：

1. 延迟 —— 请求处理时间。慢就是罪。
2. 流量 —— 系统负载。比如 QPS、带宽。
3. 错误 —— 显式错误（5xx）和隐式错误（返回成功但内容不对）。
4. 饱和度 —— 系统还能承受多少？比如 CPU、内存、磁盘。

我个人习惯把这四个信号作为监控仪表盘的首页。一打开 Grafana，先看这四个，心里就有底了。

1.3 监控体系的分层架构 —— 别把所有鸡蛋放一个篮子里

好，指标选好了，怎么组织？我建议按分层来搞。就像盖楼，一层一层来。

我一般把监控体系分成四层：

层级	监控对象	举例
基础设施层	服务器、网络、存储	CPU、内存、磁盘、网卡
中间件层	数据库、缓存、消息队列	MySQL QPS、Redis 命中率、Kafka 堆积
应用层	业务服务、API	接口延迟、错误率、JVM 内存
业务层	用户行为、交易数据	订单量、注册数、支付成功率

为什么要分层？因为不同层的问题，需要不同的工具和告警策略。

• 基础设施层，用 Prometheus + Node Exporter 就够了。
• 中间件层，每个中间件有自己的 Exporter。
• 应用层，需要接入 APM（比如 SkyWalking、Pinpoint）。
• 业务层，往往需要自定义埋点。

1.4 总结 —— 监控不是终点，是起点

好了，这一章咱们聊了：

• 监控为什么重要 —— 发现问题、定位问题、预测问题。
• 黄金指标 —— USE（资源）、RED（服务）、四大黄金信号（全局）。
• 分层架构 —— 基础设施、中间件、应用、业务，各层独立又协同。

最后说一句：监控不是为了看数据，而是为了做决策。数据摆在那，你得知道下一步该干嘛。下一章，咱们就动手搭建第一个监控组件——Prometheus。到时候手把手教你配。

嗯，今天就到这儿。有问题欢迎留言，咱们下章见。