监控CPU和内存，核心看两类数据：CPU的使用率、负载和排队情况，内存的容量余量、回收和交换活动。 具体看哪些指标，不是丢给你一个top就完事，而是要分场景、分维度去判断瓶颈到底卡在哪,下面我把这套逻辑拆开讲透。
CPU监控指标到底看哪些数据
CPU监控指标有很多，但真正需要每天盯着看的，其实不超过五个，其余那些千奇百怪的计数器,大多是排查深层次问题时才用得上。
使用率不是唯一答案，还要看负载和队列
很多人习惯性只看一个“CPU使用率”，高了就说CPU满，低了就说没事，这个判断太粗糙，先看使用率，但要拆成用户态、系统态、I/O等待三块，用户态高说明正在算东西，系统态高说明内核在忙，可能是系统调用频繁或进程调度太猛，I/O等待高则要另说，这往往不是CPU的问题,而是磁盘拖了后腿。
然后看负载平均值，也就是load average，这个数务必结合CPU核数来读，行业共识认为，负载值持续大于机器核数的数倍，才算真正的过载，但负载高不等于CPU忙，因为不可中断睡眠的进程也会算进负载里，如果你看到load飙高而CPU使用率很低，先查有没有大量I/O卡住的进程。
每个核的利用率比总利用率更诚实
多核机器里，整体使用率40%不代表没有瓶颈，一个四核机器，如果只有一个核被占满，总使用率只有25%，但应用可能已经卡出天际了，所以要监控每个CPU核心的使用率，用mpstat -P ALL就能看到单核状况，这一步能帮你发现那些“只吃一个核”的单线程程序。
上下文切换和中断是隐藏信号
上下文切换每秒次数，以及软中断、硬中断占用的CPU时间，在低延时服务里非常关键，如果你用vmstat观察，cs列的数字如果动辄几万甚至几十万，说明系统里的线程和进程在疯狂抢占调度，真正的业务计算反而拿不到时间片，软中断高通常和网络收发有关，大流量时经常看到某一个核被软中断打满,其他核闲着。
内存监控指标怎么看才靠谱
内存监控的坑比CPU更多，很多人的第一反应是看“还有多少空闲内存”，但Linux下的free命令里，那个free列常常可怜兮兮，而buff/cache却大得吓人,这并不代表内存不够。
可用内存比已用内存更有参考价值
Linux内存管理的原则是“闲着也是闲着，不如拿来缓存”，所以buff/cache占得多，恰恰说明系统在积极提升I/O性能，真正要盯的是available这一列，它是衡量当前还有多少内存可以随时分给应用的指标，只要available没有持续见底,就不用慌。
交换分区和内存回收驱动要重点盯
swap的变化是内存短缺的硬信号，看vmstat输出里的si和so两个数字，分别表示从磁盘换入和换出到磁盘的流量，当这两个数字持续非零，说明物理内存已经不够用，系统沦落到靠磁盘扮演临时内存,性能会肉眼可见地崩塌。
另一个容易被忽略的是缺页中断，尤其是major page fault，进程访问的页不在物理内存里，需要从磁盘读，这种缺页代价极高，可以用pidstat -r或者perf去查，当你发现应用的周转时间变慢，而内存使用率并不高时,多看看这个字段。
内存带宽和延迟什么时候需要关注
普通业务场景很少直接看内存带宽，因为系统瓶颈通常出现在容量不足上，但如果你跑的是大规模科学计算、视频编解码或高频交易，那么内存带宽和NUMA跨节点访问延迟就很重要了，这类场景下，可以看numastat或Intel PCM工具，确认内存是不是真的跑在满速，对于大多数运维和开发来说，内存监控做到容量、swap、缺页这三层就足够了。
不同场景下CPU和内存监控重点完全不同
同样是看使用率，nginx反向代理和MySQL数据库的关注点差异极大,下面说两个最常见的场景。
高并发Web服务器的监控侧重
高并发Web服务器上，CPU的user态是主力，因为大量请求在做页面渲染或JSON序列化，这时候要看每秒请求数对队列的影响，一旦发现load上升、响应时间拉长，就去看进程的CPU时间分布和上下文切换，内存在这个场景里主要看可用内存和socket缓冲区，当大量短连接建立时，内存碎片和连接队列容易出现异常，业内专家指出，这类机器上如果swap非零，就该立刻扩容或调参,没有第二种解释。
数据库服务器的内存监控重点
数据库服务最大的特点是自己管理内存，比如MySQL的innodb_buffer_pool，Redis的所有数据，系统内存监控反而要退到第二线，你需要关注的是这些进程有没有大量使用操作系统的page cache做额外缓存，以及swap是否出现，另一个关键指标是页错误率和I/O等待，如果数据库进程的CPU消耗大量时间在等待内存页从磁盘加载，说明buffer pool配小了。
容器环境下的监控差异
容器里的CPU和内存监控和物理机不一样，你在容器内看到的/proc/stat和/proc/meminfo往往是宿主机全局的视图，而不是你容器的配额，真正要看的指标是cgroup里的cpuacct.usage和memory.usage_in_bytes，以及容器运行时给你的CPU限额，如果容器超出限制，不是被终止就是被限流,表现为CPU使用率被强制压到阈值。
Linux下用命令实操监控
理论说多了容易飘，直接上命令，以下都是Linux系统里最常用的监控套路,建议搭配实际环境跑一遍。
第一梯队：top和vmstat
top提供全局快照，按大写P按CPU排序，按大写M按内存排序，重点关注顶部的load average和%Cpu的us、sy、wa、hi、si值。vmstat 1 5则提供连续采样，第一行是历史平均，后面才是实时数据,需要看的列：
- r：运行队列中的进程数,持续大于CPU核数说明CPU饱和。
- b：不可中断睡眠的进程数，长期大说明I/O有阻塞。
- si/so：swap换入换出,非零就要警惕。
- cs：上下文切换次数,异常高要考虑线程模型。
第二梯队：mpstat和pidstat
单核视角用mpstat -P ALL 1，每一行是一个核心，观察有没有某个核被压满，进程视角用pidstat -u -r 1，既能看CPU百分比，也能看内存变化，而且能按进程精确排查，比如你想知道nginx里哪个worker进程在偷跑,用它就能逮到。
第三梯队：free和sar
查看内存直观感受用
free -h，注意available那一列，要记录历史趋势，用系统自带的sar。sar -r看内存分页，sar -q看负载，sar -w看每秒上下文切换，这些数据能帮你判断资源压力是持续性的还是偶发的,比单次快照更有价值。
更细的进程级内存怎么看
如果进程有内存泄漏嫌疑，用pmap -x 进程号看每个进程的内存映射表，或者cat /proc/进程号/smaps统计私有内存，日常监控不需要这么细，但如果你的JVM或Node进程内存只涨不跌,这些命令就是排查利器。
关于监控指标的最常问问题
CPU使用率100%和负载高是一回事吗
不是，CPU使用率100%表示算力被吃满，但负载高还可能来自磁盘中断或不可中断进程，有时候CPU使用率只有30%，load却超过核数，那是因为大量进程卡在I/O上，排队等待，反过来，CPU使用率100%时负载可能只有个位数，那说明只有一个或少量核心在忙,其余核心空闲。
free命令显示buff/cache很大，是不是内存不够了
不是，buff/cache是Linux把空闲内存拿来缓存磁盘和文件系统数据，属于正常世界，如果available列仍然充足，应用也稳定运行，就不需要处理，只有当available持续缩小，并且swap发生波动时，才考虑内存不足，你甚至可以用echo 3 > /proc/sys/vm/drop_caches手动释放缓存,但通常没必要强制清理。
容器里的内存监控和宿主机一样吗
不一样，容器内用free看到的宿主机全局内存，而非自己的限制，应该在cgroup目录里看memory.current和memory.max，或者直接用cat /sys/fs/cgroup/memory.current获取当前使用量，如果容器超出memory.max，进程可能会被OOM killer杀掉，这时宿主机看起来内存还很充足,但容器就是不升反降。
监控这件事，最怕就是看着一堆数字却不知道哪个能说明问题，CPU和内存的指标之间不是孤立的，上下文切换高了会引起CPU系统态上升，swap活跃会拖慢CPU进程，把本文提到的这些指标在你自己的机器上跑一遍，结合业务表现做横向对比,才能真正读懂它们。