一、监控体系概述：为什么需要监控、黄金指标与分层架构
大家好，我是你们的讲师。今天咱们聊聊监控体系。
说实话，我见过太多团队把监控当成「装个 Prometheus + Grafana 就完事了」。结果呢？线上出了故障，翻半天仪表盘找不到根因。为什么？因为没搞懂监控的本质。
这一章，我会把监控的「为什么」、「看什么」、「怎么搭」讲透。嗯，都是我在生产环境里摔过的坑换来的经验。
1.1 为什么需要监控？
先问个问题：没有监控，你能活吗？
能。但活不久。
我早年带过一个项目，上线后一切正常。直到有一天，用户反馈「页面打不开」。我们登录服务器一看——磁盘满了。日志文件把 500GB 的盘撑爆了。你说尴尬不尴尬？
监控的核心价值，说白了就三件事：
- 发现问题：别等用户骂上门，你才知道系统挂了
- 定位问题：出故障了，能快速缩小范围，而不是全员瞎猜
- 预测问题：磁盘快满了、内存快爆了，提前告警，别等崩了再救
一句话总结：监控不是给老板看的仪表盘，而是你作为 SRE 的「眼睛」和「手」。
1.2 监控的黄金指标
指标那么多，看哪些才管用？
业界总结了三套方法论：USE、RED、四大黄金信号。我一个个说。
1.2.1 USE 方法（资源视角）
USE 是 Brendan Gregg 提出的，专门用来排查资源瓶颈。三个字母对应：
- Utilization（利用率）：资源忙了多久？比如 CPU 90%
- Saturation（饱和度）：资源排队了没？比如 CPU 运行队列长度
- Errors（错误）：资源出错了没？比如磁盘 I/O 错误
我习惯用 USE 来快速判断「是不是资源问题」。举个例子：
有一次线上接口变慢，我第一反应是看 CPU 利用率——不高。再看磁盘饱和度——IO 队列深度飙到 200+。嗯，找到根因了：磁盘 I/O 饱和。加个 SSD 缓存就解决了。
我的经验：USE 适合基础设施层（服务器、网络、存储）。应用层不太适用。
1.2.2 RED 方法（服务视角）
RED 是 Google 的 SRE 团队提出的，专门看服务健康度：
- Rate（速率）：每秒多少请求？
- Errors（错误）：失败请求占比多少？
- Duration（持续时间）：响应时间多长？
说白了，RED 就是问三个问题：
- 你的服务忙不忙？（Rate）
- 你的服务稳不稳？（Errors）
- 你的服务快不快？（Duration）
我在项目中，每个微服务必须暴露 RED 指标。没有这三个，别想上线。
1.2.3 四大黄金信号
Google 在《SRE 运维解密》里还提了四大黄金信号，比 RED 更全面：
| 信号 | 说明 | 我常用的指标 |
|---|---|---|
| 延迟（Latency） | 请求处理耗时 | p50、p95、p99 延迟 |
| 流量（Traffic） | 系统负载量 | QPS、TPS、带宽 |
| 错误（Errors） | 显式/隐式错误 | HTTP 5xx、超时、业务错误码 |
| 饱和度（Saturation） | 资源耗尽程度 | CPU 队列、内存使用率、磁盘 IO 等待 |
避坑指南：我曾经只监控平均延迟，结果 p99 延迟已经 10 秒了，平均值才 200ms。后来我改成监控 p95 和 p99，才真正看到问题。
1.3 监控系统的分层架构
监控系统不是一个大锅烩。我习惯把它分成四层，每一层各司其职。
下面这张图是我自己画的，你看完就明白了：
这四层，每一层都有讲究：
第1层：数据采集层
这是最底层，也是最容易被忽视的。我见过有人用 shell 脚本采集指标，结果采集器本身把 CPU 打满了。嗯，这里要注意：采集器要轻量，不能影响业务。
- 指标采集：Prometheus Exporter、Node Exporter、cAdvisor
- 日志采集：Filebeat、Fluentd、Logstash
- 链路采集：Jaeger Agent、SkyWalking Agent
第2层：数据传输与处理层
数据量大了，直接写存储会崩。所以中间要加一层缓冲和处理。
- 缓冲：Kafka 扛住突发流量
- 过滤：去掉无用日志，减少存储成本
- 聚合：比如 1 秒内的指标聚合成 1 分钟平均值
我的经验：曾经日志量太大，ES 集群直接 OOM。后来加了 Kafka 做削峰填谷，再也没出过问题。
第3层：存储与计算层
这一层是核心。选型很关键：
- 时序数据：Prometheus（适合指标）、InfluxDB（适合 IoT）
- 日志数据：Elasticsearch（全文搜索强）
- 链路数据：Jaeger、Zipkin
告警规则也在这里评估。比如「CPU > 80% 持续 5 分钟」就触发告警。
第4层：可视化与告警层
数据存好了，得让人看得懂。Grafana 是标配。告警通知要分级：
- P0 故障：电话 + 短信，5 分钟内必须响应
- P1 警告：钉钉/企微群，30 分钟内处理
- P2 通知：邮件，日清
避坑指南：我曾经把所有告警都发到同一个群，结果大家全麻木了，真正出故障反而没人看。后来我按级别分群，P0 单独拉群，效果好了很多。
1.4 小结
这一章，我们聊了：
- 监控的三大目的：发现问题、定位问题、预测问题
- 黄金指标：USE（资源）、RED（服务）、四大黄金信号（全面）
- 分层架构：采集 → 传输 → 存储 → 可视化，每一层都有坑
你想想看，如果连「为什么监控」都没想清楚，直接上 Prometheus，那跟闭着眼睛开车有什么区别？
下一章，我会手把手带你搭建一套生产级的监控系统。嗯，到时候咱们再细聊。