核心指标详解：CPU、内存、磁盘、网络四大基础指标
监控告警体系里，最基础也最容易被忽视的，就是这四大件。我见过不少团队，一上来就搞什么业务链路追踪、APM，结果CPU被打爆了都不知道。说白了，地基没打好，上层再花哨也是空中楼阁。
今天咱们就把这四大基础指标彻底聊透。我会结合USE方法和RED方法，把每个指标拆开揉碎了讲。嗯，这些都是我这些年踩坑踩出来的经验，希望能帮你少走弯路。
一、CPU指标：你的服务器在忙什么？
CPU是服务器的“大脑”。它忙不忙，忙在哪里，直接决定了系统的响应速度。
1. 利用率（Utilization）
利用率就是CPU在工作的时间占比。比如80%的利用率，意味着CPU有80%的时间在执行指令，20%的时间在空闲。
我个人的习惯：看CPU利用率，不能只看平均值。我曾经遇到过一台服务器，平均利用率只有30%，但业务高峰期却卡得要死。后来一查，原来是4核CPU里，有3个核在跑批处理任务，只有1个核在处理用户请求。那个核的利用率已经飙到95%了。
关键点：要按CPU核心分别监控，而不是只看整体平均值。
2. 饱和度（Saturation）
饱和度，说白了就是CPU的“排队长度”。当CPU忙不过来时，任务就会排队等待。这个队列越长，说明CPU越饱和。
在Linux里，我们可以用vmstat命令看r列（运行队列）。如果这个值持续大于CPU核心数，那就要警惕了。
# 查看CPU运行队列
vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 0 123456 7890 456789 0 0 10 20 100 200 30 10 60 0 0你看，这里的r值是3，如果这台机器只有2个CPU核心，那就说明有任务在排队了。
我曾经踩过的坑：有一次线上告警说CPU利用率只有60%，但接口响应时间却飙升。我排查了半天，才发现是运行队列已经堆积到20多了。利用率不高，不代表CPU不饱和。记住，饱和度和利用率是两个维度。
3. 错误数（Errors）
CPU错误比较少见，但一旦出现，基本就是硬件问题。比如CPU温度过高、缓存错误、机器检查异常（Machine Check Exception）等。
监控CPU错误，主要看/var/log/mcelog或者dmesg里的硬件错误日志。
二、内存指标：别让OOM Killer找上门
内存是服务器的“工作台”。工作台不够大，东西就得往硬盘上搬，那速度就慢得多了。
1. 利用率（Utilization）
内存利用率就是已使用的内存占总内存的比例。但这里有个坑：Linux会把空闲内存用作文件缓存（Cache），这部分内存其实是可以回收的。
我建议：监控内存利用率时，要关注可用内存，而不是空闲内存。可用内存 = 空闲内存 + 可回收的缓存。
# 查看内存使用情况
free -h
total used free shared buff/cache available
Mem: 15Gi 5.6Gi 2.1Gi 1.2Gi 7.3Gi 8.9Gi你看，虽然used是5.6G，但available还有8.9G，说明内存其实还够用。
2. 饱和度（Saturation）
内存饱和度的直接体现就是交换分区（Swap）的使用。当物理内存不够时，系统会把不常用的内存页换到磁盘上。这个过程叫“换页”（Swapping）。
一旦开始大量换页，性能就会急剧下降。因为磁盘的读写速度比内存慢几个数量级。
关键指标：si（从磁盘换入内存）和so（从内存换出到磁盘）。这两个值如果持续大于0，说明内存已经饱和了。
3. 错误数（Errors）
内存错误主要是OOM Killer（内存溢出杀手）。当系统内存耗尽时，内核会杀掉一些进程来释放内存。
监控OOM Killer，可以看dmesg或者/var/log/kern.log。一旦出现OOM，说明内存已经严重不足，需要立即扩容或优化。
小技巧：我习惯在监控系统里设置一个告警：当available内存低于总内存的10%时，就触发预警。这样可以在OOM发生前，给我们留出处理时间。
三、磁盘指标：IO才是真正的瓶颈
很多人以为磁盘只看空间就够了。其实，磁盘的IO性能才是真正的瓶颈。你想想看，CPU和内存都是纳秒级的，磁盘是毫秒级的，差了三个数量级。
1. 利用率（Utilization）
磁盘利用率，指的是磁盘处理IO请求的时间占比。注意，不是磁盘空间的使用率。
在Linux里，可以用iostat查看%util列。如果这个值接近100%，说明磁盘已经满负荷工作了。
# 查看磁盘IO
iostat -x 1
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
sda 10.0 20.0 100.0 200.0 0.0 0.0 0.00 0.00 5.00 10.00 0.30 10.00 10.00 3.33 10.00这里的%util是10%，说明磁盘还有余量。
我曾经踩过的坑：有一次数据库响应变慢，我看%util只有60%，觉得磁盘没问题。后来才发现，那台机器用的是SSD，60%的利用率对于SSD来说已经很高了。因为SSD的并发能力很强，60%的利用率意味着内部队列已经很长了。所以，不同类型的磁盘，利用率阈值是不一样的。
2. 饱和度（Saturation）
磁盘饱和度，看的是IO等待队列长度（aqu-sz）和IO等待时间（await）。
如果await持续升高，说明IO请求在排队等待处理。这时候，即使%util不高，也说明磁盘已经饱和了。
3. 错误数（Errors）
磁盘错误包括：IO错误、磁盘坏道、文件系统错误等。这些错误通常会在/var/log/messages或dmesg里留下记录。
监控磁盘错误，我建议重点关注IO错误和磁盘重新分配扇区数（SMART指标）。一旦出现，说明磁盘快挂了，需要立即更换。
四、网络指标：别让带宽成为瓶颈
网络是服务器的“血管”。血管堵了，再强的CPU和内存也白搭。
1. 利用率（Utilization）
网络利用率，就是当前流量占带宽的比例。比如你的网卡是1Gbps，当前流量是500Mbps，那利用率就是50%。
我个人的习惯：网络利用率要按方向分别监控。入向流量和出向流量的瓶颈可能完全不同。比如，Web服务器通常是出向流量大（响应数据），而数据库服务器可能是入向流量大（接收查询请求）。
2. 饱和度（Saturation）
网络饱和度的体现是丢包和重传。当网络带宽不够时，数据包会被丢弃，或者因为超时而重传。
监控网络饱和度，主要看netstat里的drop和overrun，以及TCP的重传率。
# 查看网络接口统计
netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 123456 0 0 0 654321 0 0 0 BMRU这里的RX-DRP和TX-DRP就是丢包数。如果持续增长，说明网络已经饱和了。
3. 错误数（Errors）
网络错误包括：CRC校验错误、帧错误、冲突等。这些错误通常意味着物理层有问题，比如网线接触不良、网卡故障等。
小技巧：我习惯在监控系统里设置一个告警：当TCP重传率超过1%时，就触发预警。因为重传率升高，通常意味着网络质量下降，或者带宽不足。
五、USE方法与RED方法：两种思维框架
聊完了四大指标，咱们再来说说两种经典的监控方法论：USE和RED。
1. USE方法（利用率、饱和度、错误数）
USE方法是由Brendan Gregg提出的，适用于基础设施资源的监控。它要求对每个资源，都从利用率、饱和度、错误数三个维度去分析。
说白了，USE方法就是回答三个问题：
- 这个资源忙不忙？（利用率）
- 这个资源有没有排队？（饱和度）
- 这个资源有没有出错？（错误数）
刚才我们讲的CPU、内存、磁盘、网络，都可以用USE方法来分析。这也是我日常排查问题时最常用的方法。
2. RED方法（速率、错误、持续时间）
RED方法是由Tom Wilkie提出的，适用于服务的监控。它关注的是：
- 速率（Rate）：每秒处理多少请求？
- 错误（Errors）：请求失败的比例是多少？
- 持续时间（Duration）：请求处理需要多长时间？
RED方法更适合微服务架构。比如，你监控一个API服务，就可以看：
- QPS（每秒请求数）
- 错误率（5xx比例）
- P99延迟（99%的请求在多少毫秒内完成）
我的经验：USE方法看“资源”，RED方法看“服务”。两者结合，才能全面掌握系统的健康状况。我通常先用USE方法排查资源瓶颈，再用RED方法评估服务质量。
六、知识体系总览
下面这张图，把四大基础指标和两种方法论的关系梳理清楚了。你可以把它当作一个快速参考。
这张图里，上半部分是四大基础指标，中间是USE方法，下面是RED方法。你可以看到，USE方法更关注资源层面的健康，而RED方法更关注服务层面的质量。
在实际工作中，我通常先用USE方法快速定位资源瓶颈，再用RED方法评估对业务的影响。比如，CPU利用率高了，我会看是哪个进程在吃CPU，然后看这个进程对应的服务，它的QPS和延迟有没有变化。这样就能把“资源问题”和“业务影响”关联起来。
公众号:蓝海资料掘金营，微信deep3321