3. 基础设施监控：CPU、内存、磁盘IO、网络带宽的监控指标与告警阈值设定
说到基础设施监控，我脑子里第一个蹦出来的画面，就是几年前一个深夜的线上事故。
那会儿我们刚上线一套新的因子计算集群，跑着跑着，突然所有任务都卡住了。我登录上去一看，CPU 使用率才 30%，内存也够，但磁盘 IO 等待时间飙到了 90% 以上。说白了，就是磁盘成了瓶颈，CPU 都在排队等数据。
从那以后，我对基础设施监控就再也不敢马虎了。今天咱们就聊聊，在因子工厂这种高频计算场景下，CPU、内存、磁盘 IO、网络带宽到底该怎么盯，阈值怎么设。
核心观点：基础设施监控不是为了看数据，而是为了在故障发生前，提前嗅到危险的味道。
3.1 CPU 监控：别只看使用率
很多人监控 CPU，就盯着一个「使用率」指标。其实这远远不够。
我个人的习惯是，至少看三个维度：
- CPU 使用率（user + system）：这个最直观，但要注意区分 user 和 system。如果 system 占比过高，说明系统调用太频繁，可能是锁竞争或者 IO 操作太多。
- CPU 负载（load average）：这个指标反映的是等待队列的长度。如果负载远高于 CPU 核心数，说明任务在排队，系统已经过载了。
- 上下文切换次数（context switches）：这个容易被忽略。我在项目中遇到过，某个因子计算模块用了大量短线程，上下文切换每秒几十万次，CPU 全耗在切换上了，实际计算效率极低。
我的经验：对于因子计算这种 CPU 密集型任务，CPU 使用率超过 85% 就要警惕了。超过 95% 基本意味着系统已经接近饱和，随时可能抖动。
告警阈值怎么设？我一般这样定：
| 指标 | 警告阈值 | 严重阈值 | 说明 |
|---|---|---|---|
| CPU 使用率 | > 80% 持续 5 分钟 | > 95% 持续 2 分钟 | 因子计算通常吃 CPU，阈值可以适当放宽 |
| CPU 负载/核心数 | > 3.0 持续 5 分钟 | > 5.0 持续 2 分钟 | 负载超过核心数 3 倍，基本已经卡死了 |
| 上下文切换 | > 5 万次/秒 | > 10 万次/秒 | 这个值因机器而异，需要根据基线调整 |
注意：不要用绝对值一刀切。不同 CPU 型号、不同内核版本，表现差异很大。我建议先跑一周基线数据，再动态调整阈值。
3.2 内存监控：小心 OOM 杀手
内存监控，很多人只看「已用内存」。但 Linux 的内存管理机制比较复杂，你看到的「已用」可能并不准确。
举个例子，Linux 会把空闲内存用作文件缓存（cache），这部分内存其实是可以被回收的。所以真正需要关注的，是 可用内存 = 空闲内存 + 缓存 + 缓冲区。
我一般监控这几个指标：
- 可用内存百分比：低于 20% 就要注意了。
- Swap 使用率：如果 Swap 开始被大量使用，说明物理内存已经不够了。因子计算这种场景，一旦开始用 Swap，性能会断崖式下跌。
- OOM Killer 事件：这个必须监控。一旦触发 OOM Killer，进程会被直接杀掉，数据可能丢失。
避坑指南：我曾经遇到过，某台机器内存使用率一直 70% 左右，看起来挺正常。但仔细一看，Swap 已经用了 4GB。原来是有个进程偷偷在泄漏内存，物理内存不够了就开始用 Swap。所以，内存监控一定要把 Swap 也盯上。
阈值设定参考：
| 指标 | 警告阈值 | 严重阈值 | 说明 |
|---|---|---|---|
| 可用内存 | < 20% 持续 5 分钟 | < 10% 持续 2 分钟 | 因子计算内存需求大，建议预留更多 |
| Swap 使用率 | > 0% 持续 10 分钟 | > 50% 持续 5 分钟 | 只要用了 Swap，基本就是异常 |
| OOM Killer | 无 | 发生即告警 | 这个必须 0 容忍 |
3.3 磁盘 IO：最容易被忽视的瓶颈
磁盘 IO 监控，说实话，是很多人的盲区。CPU 和内存用得好好的，但磁盘一慢，整个系统就跟着慢。
因子工厂里，大量因子数据需要读写磁盘。如果磁盘 IO 跟不上，CPU 再快也没用。
我重点看这几个指标：
- IOPS（每秒读写次数）：对于随机读写场景，IOPS 是关键。比如因子数据的小文件读取。
- 吞吐量（MB/s）：对于顺序读写场景，比如日志写入、大文件加载。
- IO 等待时间（await）：这个指标非常关键。它表示一次 IO 请求从发出到完成的时间。如果超过 100ms，说明磁盘已经严重过载。
- 队列长度（avgqu-sz）：等待处理的 IO 请求数量。如果长期大于 1，说明磁盘忙不过来了。
我的经验：SSD 和 HDD 的阈值完全不同。SSD 的 await 超过 50ms 就算异常，而 HDD 可能 200ms 都算正常。所以一定要根据磁盘类型来设定。
阈值参考：
| 指标 | 警告阈值 | 严重阈值 | 说明 |
|---|---|---|---|
| await（SSD） | > 50ms | > 100ms | SSD 延迟应该很低 |
| await（HDD） | > 200ms | > 500ms | HDD 机械结构，延迟高一些 |
| avgqu-sz | > 2 | > 5 | 队列太长，IO 已经排队了 |
| 磁盘使用率 | > 80% | > 95% | 磁盘快满了，会影响写入性能 |
3.4 网络带宽：别让数据堵在路上
因子工厂里，节点之间需要频繁交换数据。网络带宽不够，或者延迟太高，都会拖慢整体计算速度。
我主要监控这几个：
- 带宽使用率（入站/出站）：看看是不是快跑满了。如果长期超过 80%，说明网络可能是瓶颈。
- 丢包率：这个很关键。哪怕丢包 0.1%，在大量数据传输时也会导致重传，严重影响性能。
- TCP 重传率：如果重传率超过 1%，说明网络质量有问题，可能是链路不稳定或者带宽不够。
- 连接数：特别是 ESTABLISHED 状态的连接数。如果连接数过多，可能是有连接泄漏。
我曾经踩过的坑：有一次，因子计算突然变慢，查了半天，发现是网络带宽被一个日志备份任务占满了。所以，网络监控一定要区分流量来源，知道是谁在吃带宽。
阈值设定：
| 指标 | 警告阈值 | 严重阈值 | 说明 |
|---|---|---|---|
| 带宽使用率 | > 70% 持续 10 分钟 | > 90% 持续 5 分钟 | 预留一些余量应对突发流量 |
| 丢包率 | > 0.1% | > 0.5% | 丢包对性能影响很大 |
| TCP 重传率 | > 1% | > 3% | 重传意味着网络质量下降 |
| 连接数 | 超过基线 50% | 超过基线 100% | 需要根据业务场景设定基线 |
3.5 一张图看懂基础设施监控体系
说了这么多，我画了一张图，把整个监控体系串起来。你一看就明白了。
这张图把四个维度的监控指标和告警流程串在了一起。你想想看，任何一个环节出问题，告警引擎都能第一时间通知你。
3.6 一些实用的小建议
最后，分享几个我在实战中总结出来的经验：
- 不要用默认阈值：很多监控工具都有默认阈值，但那些值不一定适合你的场景。因子计算是 CPU 密集型，和 Web 服务的阈值肯定不一样。
- 先跑基线，再设阈值：新系统上线后，先跑一周数据，看看正常情况下的指标范围，再根据这个范围来设定告警阈值。
- 告警要分级：不要所有问题都发告警。小问题发警告，大问题才发严重告警。否则运维人员会麻木的。
- 关联分析很重要：单个指标异常可能说明不了什么。比如 CPU 高 + 磁盘 IO 高 + 网络带宽高，那可能是某个任务在大量读写数据。但如果只有 CPU 高，其他都正常，那可能是计算逻辑有问题。
嗯，这里要注意：告警不是越多越好。我曾经见过一个团队，一天收到上千条告警，结果真正重要的问题反而被淹没了。所以，告警要精，不要多。
好了，基础设施监控这块就聊到这儿。记住，监控不是为了看数据，而是为了在故障发生前，提前发现风险。把 CPU、内存、磁盘 IO、网络带宽这四个维度盯好了，你的因子工厂就能稳定运行。