1. 监控体系概述
大家好，我是你们的老朋友。今天咱们聊聊监控——这个听起来基础、但实际坑特别多的领域。
我刚开始做运维那会儿，对监控的理解特别简单：不就是装个Zabbix，画几个CPU、内存的图吗？后来踩了不少坑才明白，监控远不止这些。说白了，监控是你系统的眼睛和耳朵。没有它，你就像在黑夜里开车——出了事才知道，但已经晚了。
1.1 什么是监控
监控，就是持续收集、分析系统的运行数据，判断系统是否健康。它回答三个问题：
- 系统现在怎么样？——实时状态
- 系统过去怎么样？——历史趋势
- 系统未来会怎么样？——预测分析
我个人习惯把监控分成三层：
- 基础设施监控：服务器、网络、存储这些硬件层面的东西
- 应用监控：业务接口、中间件、数据库这些软件层面的东西
- 业务监控：订单量、用户活跃度、转化率这些跟钱挂钩的东西
你想想看，如果只盯着CPU，业务挂了都不知道。反过来，只看业务指标，服务器宕机了也发现不了。三层都得看，缺一不可。
1.2 为什么需要监控
这个问题我问过不少新人，答案五花八门。有人说「为了出问题能发现」，有人说「老板要看报表」。都对，但不够全面。
我总结一下，监控的核心价值就四点：
- 快速发现故障：别等用户投诉了才知道系统挂了
- 定位根因：出问题了，能快速找到是哪个环节的锅
- 容量规划：知道什么时候该扩容，什么时候该缩容
- SLA保障：跟客户签了99.9%的可用性，你得有数据证明
重要提醒：监控不是为了监控而监控。它的最终目的是保障用户体验和业务连续性。如果监控系统本身比被监控的系统还复杂、还容易出问题，那就本末倒置了。
1.3 监控的核心目标：MTTR 与 MTBF
做监控，有两个指标你必须刻在脑子里：MTTR 和 MTBF。
| 指标 | 全称 | 含义 | 目标 |
|---|---|---|---|
| MTBF | Mean Time Between Failures | 平均无故障时间 | 越长越好 |
| MTTR | Mean Time To Repair | 平均修复时间 | 越短越好 |
MTBF 衡量的是系统的可靠性。比如你的服务平均每运行1000小时才出一次故障，那MTBF就是1000小时。这个值越高，说明系统越稳定。
MTTR 衡量的是故障恢复速度。从你发现故障到系统恢复正常，花了多长时间。这个值越低，说明你的应急响应能力越强。
我的经验：很多团队只盯着MTBF，拼命做高可用、做冗余，却忽略了MTTR。我曾经遇到一个项目，系统架构做得特别牛，但出故障后排查流程一团糟，恢复时间长达2小时。后来我们优化了告警规则、做了自动化恢复脚本，MTTR从2小时降到了15分钟。效果立竿见影。
所以，监控的核心目标就两个：
- 提升MTBF——让系统更稳定
- 降低MTTR——让故障恢复更快
1.4 监控的黄金信号
Google的SRE团队总结了一套方法论，叫「四个黄金信号」。我用了这么多年，觉得特别实用。它们分别是：延迟、流量、错误、饱和度。
1.4.1 延迟（Latency）
延迟就是请求从发出到收到响应的时间。它直接反映用户体验。
注意，延迟要看分位数，别只看平均值。平均值会骗人——比如100个请求里，99个是1ms，1个是10s，平均值才100ms，看起来还行。但那个10s的请求，用户已经骂娘了。
我个人习惯看P99（99分位延迟），也就是最慢的那1%请求的延迟。如果P99超过500ms，就该报警了。
1.4.2 流量（Traffic）
流量衡量系统的负载。对Web服务来说，就是QPS（每秒请求数）。对数据库来说，就是TPS（每秒事务数）。
流量监控能帮你做两件事：
- 发现异常流量——比如被攻击了，或者某个活动导致流量暴增
- 做容量规划——流量涨到多少需要扩容，心里有数
避坑指南：我曾经遇到过流量突增导致数据库连接池被打满的情况。当时只监控了CPU和内存，完全没发现连接数异常。后来加了连接池使用率的监控，才避免了类似问题。记住，流量监控要细化到每个组件。
1.4.3 错误（Errors）
错误包括显式错误和隐式错误。
- 显式错误：HTTP 500、超时、异常堆栈——这些一眼就能看出来
- 隐式错误：返回了200，但业务逻辑错了。比如下单成功但库存没扣，或者返回了空数据
隐式错误最难发现。我建议对关键业务接口做业务校验——比如下单接口，不仅要看HTTP状态码，还要检查返回的订单号是否有效。
1.4.4 饱和度（Saturation）
饱和度衡量系统资源的使用程度。CPU、内存、磁盘、网络带宽、连接数——这些都是资源。
关键是要知道什么时候会满。比如磁盘用了80%，看起来还行。但按每天增长1%的速度，20天后就满了。这时候就该提前告警了。
我一般设置两级阈值：
- 警告阈值：80%——开始关注，准备扩容
- 严重阈值：95%——立即处理，否则马上出问题
1.5 知识体系总览
下面这张图，是我自己总结的监控体系框架。你可以把它当成整个课程的地图：
这张图把整个监控体系串起来了。从上到下，从目标到落地，一层层展开。后面的课程，我们会逐一深入每个模块。
1.6 本章小结
嗯，这一章的内容就这些。总结一下重点：
- 监控是系统的眼睛和耳朵，分基础设施、应用、业务三层
- 核心目标是提升MTBF、降低MTTR
- 四个黄金信号：延迟、流量、错误、饱和度——一个都不能少
- 监控不是为了看数据，而是为了保障用户体验和业务连续性
我记得刚入行时，前辈跟我说过一句话：「没有监控的系统，就像没有仪表盘的飞机。」当时觉得夸张，现在回头看，一点不假。希望这一章能帮你建立起对监控的正确认知。后面的内容，咱们一步步深入。
一句话记住本章：监控不是装饰品，它是你系统的生命线。MTBF和MTTR是衡量这条生命线好坏的标准，四个黄金信号是判断系统是否健康的体检指标。