1. Saturation 概念与背景
1.1 什么是 Saturation（饱和度/容量水位）
Saturation（饱和度）在系统监控领域，指资源或服务在当前负载下已使用的容量与总容量的比值。它反映系统距离瓶颈还有多远，是衡量系统“拥挤程度”的核心指标。
与传统的“利用率”不同，饱和度更关注排队效应——当资源接近满负荷时，请求开始排队等待，响应时间急剧上升。饱和度正是捕捉这种“即将过载”状态的关键信号。
核心公式：
Saturation = 当前已使用容量 / 总可用容量 × 100%
例如：CPU 饱和度 = 运行队列长度 / CPU 核心数
Saturation = 当前已使用容量 / 总可用容量 × 100%
例如：CPU 饱和度 = 运行队列长度 / CPU 核心数
1.2 为什么需要监控容量水位
容量水位监控不是“锦上添花”，而是系统稳定性的生命线。以下四个场景说明其必要性：
| 场景 | 不监控的后果 | 监控后的收益 |
|---|---|---|
| 数据库连接池 | 连接耗尽，请求全部超时 | 提前扩容，避免雪崩 |
| 磁盘 I/O | 写入延迟飙升，服务降级 | 发现瓶颈，优化存储策略 |
| 内存使用 | OOM Killer 触发，进程被强制终止 | 及时回收或扩容内存 |
| 网络带宽 | 丢包率上升，连接中断 | 限流或升级带宽 |
经验法则：当饱和度超过 70% 时，系统进入“黄色警戒区”；超过 85% 时，必须立即采取扩容或限流措施。
1.3 Saturation 在系统监控中的核心地位
在业界公认的 USE 方法论（Utilization、Saturation、Errors）中，饱和度与利用率、错误率并列，构成系统健康度的三大支柱。三者关系如下：
- 利用率（Utilization）：资源被占用的时间比例，反映“忙不忙”。
- 饱和度（Saturation）：资源排队等待的程度，反映“挤不挤”。
- 错误率（Errors）：操作失败的次数，反映“坏没坏”。
利用率高不一定出问题（如 CPU 跑满但无排队），但饱和度一旦升高，响应时间必然恶化。因此，饱和度是比利用率更敏感的“预警指标”。
1.4 饱和度 vs 利用率：关键区别
| 维度 | 利用率 | 饱和度 |
|---|---|---|
| 定义 | 资源被占用的时间比例 | 资源排队等待的程度 |
| 典型指标 | CPU 使用率 80% | CPU 运行队列长度 = 4 |
| 对响应时间的影响 | 间接（高利用率不一定延迟） | 直接（排队必然增加延迟） |
| 预警灵敏度 | 低（可能掩盖问题） | 高（提前暴露瓶颈） |
| 监控优先级 | 基础指标 | 核心预警指标 |
常见误区：很多团队只盯着 CPU 利用率，认为“CPU 没到 100% 就没问题”。实际上，当 CPU 运行队列长度超过核心数 2 倍时，即使利用率只有 60%，系统响应时间也可能已经恶化。饱和度才是真正的“温度计”。
1.5 常见资源的饱和度指标
不同资源有各自的饱和度衡量方式，以下列出最常用的 6 类：
- CPU：运行队列长度 / CPU 核心数（>1 表示过载）
- 内存：Swap 使用量、OOM 事件频率
- 磁盘 I/O：I/O 等待队列深度、平均 I/O 延迟
- 网络：发送/接收缓冲区排队长度、丢包率
- 数据库连接池：活跃连接数 / 最大连接数
- 线程池：排队任务数 / 线程池大小