3. 服务器硬件监控：CPU、内存、磁盘、网络IO的监控指标与告警阈值设置
各位同学，咱们今天聊聊服务器硬件监控。说实话，很多刚入行的运维同学，一上来就盯着应用日志看，觉得硬件监控没啥技术含量。我当年也这么想过，直到有一次线上事故——磁盘写满了，整个ERP系统卡死，业务部门电话打爆了。从那以后，我再也不敢轻视硬件监控了。
硬件监控，说白了就是给服务器做“体检”。CPU、内存、磁盘、网络IO，这四大件任何一个出问题，系统都可能崩。咱们一个一个说。
3.1 CPU监控：别被“空闲率”骗了
CPU监控，很多人只看一个指标——使用率。嗯，这远远不够。
核心指标：
- CPU使用率（%）：用户态+系统态的总和。我个人习惯看平均负载，而不是瞬时值。
- CPU平均负载（Load Average）：1分钟、5分钟、15分钟。这个指标比使用率更靠谱。
- 上下文切换（Context Switches）：每秒切换次数。过高说明系统在“瞎忙活”。
- CPU等待IO（iowait）：这个很关键。CPU在等磁盘或网络，说明瓶颈不在CPU本身。
重点：CPU使用率100%不一定有问题，但iowait高一定有问题。我在项目中遇到过，数据库服务器CPU才30%，但iowait飙到60%，查了半天发现是磁盘阵列的缓存电池坏了。
告警阈值设置：
| 指标 | 警告阈值 | 严重阈值 | 说明 |
|---|---|---|---|
| CPU使用率 | > 80% 持续5分钟 | > 95% 持续2分钟 | 排除突发峰值 |
| 平均负载 | > CPU核心数×0.7 | > CPU核心数×1.0 | 比如4核CPU，负载>2.8告警 |
| iowait | > 30% | > 50% | 这个要重点关注 |
| 上下文切换 | > 10万次/秒 | > 20万次/秒 | 视CPU型号调整 |
我的小技巧：用top命令看CPU时，按“1”可以看每个核心的使用情况。我曾经发现一个ERP应用，把线程全挤在一个核心上，其他核心闲着。这就是典型的“伪高负载”。
3.2 内存监控：别等OOM才后悔
内存监控，很多人只看“已用内存”。其实Linux的内存管理机制很聪明，它会尽量用空闲内存做缓存。你看到的内存使用率80%，可能有一半是缓存，随时可以释放。
核心指标：
- 物理内存使用率：排除缓存后的真实使用量。
- Swap使用率：这个指标很关键。一旦开始用Swap，性能就崩了。
- 可用内存：free + buff/cache。这才是系统真正能用的。
- 内存页错误（Page Faults）：特别是major page faults，说明内存不够用了。
注意：我曾经遇到一个案例，某ERP系统的内存使用率一直稳定在85%，看起来没问题。但Swap使用率从0%慢慢涨到了5%。我建议他们加内存，没人听。结果一个月后，系统频繁OOM，业务中断了3小时。嗯，从那以后，我把Swap使用率>0%就设为警告阈值。
告警阈值设置：
| 指标 | 警告阈值 | 严重阈值 | 说明 |
|---|---|---|---|
| 物理内存使用率 | > 85% | > 95% | 排除缓存 |
| Swap使用率 | > 0% | > 10% | 只要用了Swap就告警 |
| 可用内存 | < 2GB | < 512MB | 视业务量调整 |
| Major Page Faults | > 100次/秒 | > 500次/秒 | 这个很危险 |
检查命令：free -h看概览，vmstat 1 5看内存动态变化。我个人习惯用cat /proc/meminfo看详细数据。
3.3 磁盘监控：IO才是命门
磁盘监控，很多人只看“磁盘使用率”。其实对于ERP系统来说，磁盘IO比容量更重要。你想想看，磁盘还有50%空间，但IO打满了，系统照样卡死。
核心指标：
- 磁盘使用率（%）：容量监控，别写满了。
- 磁盘IOPS：每秒读写次数。机械盘一般100-200 IOPS，SSD可以到几千。
- 磁盘吞吐量（MB/s）：每秒读写数据量。
- IO等待时间（await）：每次IO的平均等待时间。超过20ms就要注意了。
- IO队列长度（avgqu-sz）：等待处理的IO请求数。超过磁盘并发能力就排队了。
关键点：磁盘使用率到80%就要告警，不是因为马上要满，而是因为文件系统碎片整理、日志增长等因素。我曾经遇到过，磁盘使用率85%时，一个日志文件突然暴涨，10分钟就写满了。
告警阈值设置：
| 指标 | 警告阈值 | 严重阈值 | 说明 |
|---|---|---|---|
| 磁盘使用率 | > 80% | > 90% | 系统盘要更严格 |
| IO等待时间 | > 20ms | > 50ms | 机械盘标准 |
| IO队列长度 | > 2 | > 5 | 单磁盘标准 |
| 磁盘IOPS | > 80%最大IOPS | > 95%最大IOPS | 查磁盘规格 |
排查命令：iostat -x 1看磁盘详情，iotop看哪个进程在读写。我习惯用dstat -d看磁盘IO趋势。
3.4 网络IO监控：别让带宽成为瓶颈
网络IO，ERP系统的命脉。特别是分布式部署的ERP，应用服务器和数据库服务器之间、ERP和各分支机构的网络，任何一个环节出问题，业务就断了。
核心指标：
- 带宽使用率（%）：当前流量/最大带宽。
- 网络延迟（ms）：ping的响应时间。超过100ms就要注意。
- 丢包率（%）：超过1%就严重了。
- TCP连接数：特别是TIME_WAIT状态的连接数。
- 网络错误包：CRC错误、冲突包等。
避坑指南：我曾经遇到一个ERP系统，白天网络正常，每天晚上10点准时卡顿。查了三天，发现是备份脚本把网络带宽占满了。嗯，从那以后，我把带宽使用率>70%设为告警，并且给备份任务做了带宽限制。
告警阈值设置：
| 指标 | 警告阈值 | 严重阈值 | 说明 |
|---|---|---|---|
| 带宽使用率 | > 70% | > 90% | 持续5分钟 |
| 网络延迟 | > 50ms | > 100ms | 内网标准 |
| 丢包率 | > 0.5% | > 1% | 超过1%业务会受影响 |
| TCP TIME_WAIT | > 1万 | > 5万 | 需要优化连接池 |
监控命令：sar -n DEV 1看网络流量，netstat -s看网络统计。我习惯用nload实时看带宽占用。
3.5 综合监控策略：别让告警变成噪音
指标和阈值都设好了，但还有一个问题——告警风暴。你想想看，CPU使用率超过80%就告警，但ERP系统每天早高峰都会超过80%，那这个告警就变成噪音了。
我的建议：
- 设置持续时长：比如CPU使用率>80%持续5分钟才告警，排除瞬时峰值。
- 分级告警：警告级别发邮件，严重级别发短信/打电话。
- 关联分析：CPU高+IO高，可能是磁盘问题；CPU高+内存高，可能是应用问题。
- 业务时段：白天和晚上的阈值可以不同。比如晚上CPU>50%就告警，因为晚上应该空闲。
总结一下：硬件监控不是设几个阈值就完事了。你要理解每个指标背后的含义，知道什么情况是正常的，什么情况是异常。我在项目中见过太多“告警疲劳”的团队，最后真的出问题时，告警反而被忽略了。
好了，这一章就到这里。下一章咱们聊聊操作系统层面的监控，包括进程、文件句柄、系统日志这些。记住，硬件是基础，基础不牢，地动山摇。