监控体系概述：为什么需要监控？
说实话，我刚开始做运维那会儿，对监控这事儿挺不以为然的。
觉得不就是装个软件，配几个告警嘛。直到有一次，凌晨三点被电话吵醒——线上服务挂了，日志全丢，连什么时候挂的都不知道。嗯，从那以后，我再也不敢轻视监控了。
监控说白了，就是给系统装个“仪表盘”。你开车不看仪表盘，油表亮了都不知道，迟早抛锚。系统也一样。没有监控，你就是在盲开。
我个人习惯把监控的价值归纳为三点：
- 发现问题——服务挂了、磁盘满了、内存泄漏了，你得第一时间知道
- 定位问题——出问题了，是代码的锅？还是资源的锅？监控数据帮你说话
- 预测问题——比如磁盘使用率每天涨5%，三天后肯定爆，提前扩容才是高手
监控的分类：白盒 vs 黑盒
很多新手会问：监控到底要监控什么？其实就两大类——白盒和黑盒。
黑盒监控
黑盒监控，就是站在用户视角看系统。我不关心你内部怎么实现的，我只关心你对外提供的服务是不是正常的。
举个例子：我访问你的网站，返回200还是502？响应时间是1秒还是10秒？这就是黑盒。
我在项目中经常用黑盒监控来做“烟雾测试”——每隔几分钟模拟一次用户请求，看看服务是不是活着。说白了，用户能感知到的，才是真问题。
白盒监控
白盒监控，是站在系统内部看自己。CPU高不高？内存够不够？JVM的GC次数是不是异常？
白盒监控的价值在于“提前发现”。比如我遇到过的一个案例：某服务的GC时间突然从50ms涨到500ms，黑盒监控完全没反应（因为服务还能响应），但白盒数据已经报警了。等黑盒报警的时候，服务其实已经快挂了。
监控的核心指标：USE 和 RED 方法
指标那么多，到底该看哪些？这里有两个经典方法论，我几乎每天都在用。
USE 方法（面向资源）
USE 是 Brendan Gregg 提出的，适用于基础设施层（CPU、内存、磁盘、网络）。
- Utilization（利用率）——资源忙了多久？比如CPU使用率80%
- Saturation（饱和度）——资源排队了没？比如CPU的run queue长度
- Errors（错误）——资源出错了没？比如磁盘I/O错误
说白了，你检查任何一台服务器，先看这三个维度就够了。我排查性能问题的时候，第一件事就是打开USE仪表盘，基本能定位80%的问题。
RED 方法（面向服务）
RED 是 Tom Wilkie 提出的，适用于微服务和应用层。
- Rate（速率）——每秒多少请求？
- Errors（错误）——请求失败了多少？
- Duration（持续时间）——请求耗时多长？
你想想看，一个接口的RED数据如果都正常，那这个服务基本就是健康的。我曾经用RED方法帮一个团队定位过慢查询问题——Rate正常，但Duration突然飙升，最后发现是数据库索引失效了。
Prometheus vs Zabbix vs Nagios 对比
选监控工具，是每个团队都要面对的问题。这三款我都用过，说说我的真实感受。
| 维度 | Prometheus | Zabbix | Nagios |
|---|---|---|---|
| 数据模型 | 多维时间序列（标签） | 传统数值型 | 插件式，数据格式不统一 |
| 采集方式 | 拉模式（Pull） | 推模式（Push） | 推/拉均可 |
| 扩展性 | 强，支持联邦集群 | 中，分布式部署较复杂 | 弱，单机为主 |
| 告警能力 | 强（Alertmanager） | 中（内置告警） | 弱（插件依赖） |
| 容器支持 | 原生支持K8s | 需额外配置 | 基本不支持 |
| 学习曲线 | 中（PromQL需学习） | 低（界面配置） | 高（配置文件复杂） |
| 社区活跃度 | 极高（CNCF毕业项目） | 中 | 低（已逐渐边缘化） |
我个人习惯这样选型：
- 新项目、云原生、K8s环境——无脑选Prometheus。我在多个K8s集群里都用它，配合Grafana，体验非常好。
- 传统IDC、网络设备监控——Zabbix更合适。它的模板库很丰富，交换机、防火墙直接套用就行。
- Nagios——说实话，我现在基本不推荐了。除非你维护的是十年以上的老系统，否则别给自己找麻烦。
好了，这一章就聊到这儿。下一章我们会深入Prometheus的架构和数据模型，到时候我会分享一些我在生产环境中踩过的坑，保证让你少走弯路。