Linux系统资源监控需围绕稳定性、性能瓶颈和故障定位，分层观测CPU、内存、磁盘I/O、网络等关键指标：CPU关注us/sy/wa/si/hi及load average；内存重在Active/Inactive比例、pgmajfault、slab和OOM日志；磁盘需结合await、%util、avgqu-sz与blktrace；网络要分析TCP重传率、连接状态、socket缓冲区及ICMP/UDP错误；所有指标须带主机、角色等标签以支持归因。
Linux系统资源监控的核心在于明确“监控什么”和“怎么衡量”。指标设计不是堆砌数据，而是围绕稳定性、性能瓶颈和故障定位三个目标，聚焦可采集、可告警、可归因的关键维度。
CPU使用率：不只是一个百分比
CPU指标不能只看top里的整体%us或%id。需分层观测：
- 用户态（%us）与内核态（%sy）失衡：若%us低但%sy持续高于30%，可能有频繁系统调用、锁竞争或中断风暴；
- 等待I/O（%wa）突增：结合iostat看是否磁盘响应延迟升高，而非单纯CPU空闲；
- 软中断（%si）/硬中断（%hi）异常：网卡收包过载、定时器密集触发时易升高，需关联/proc/interrupts分析；
- 每核负载（load average）与CPU数比值：load > CPU核心数×1.5 持续5分钟，说明任务排队严重，需查runnable进程数（procs.R）。
内存：关注压力而非总量占用
避免只盯free -h的"used"。关键看是否触发回收及代价：
- 活跃内存（Active(file/anon)）与非活跃内存（Inactive）比例：Inactive占比长期低于10%，说明页面回收频繁，可能内存不足；
- 页回收速率（pgpgin/pgpgout）与缺页中断（pgmajfault）：majfault/s > 100 且持续，常指向内存不足或大页未启用；
- slab内存占用（尤其是dentry/inode缓存）：slabtop中SUnreclaim过高，可能文件句柄泄漏或目录遍历过多；
- OOM Killer触发日志（dmesg | grep -i "killed process"）：是内存问题的最终证据，需前置监控/proc/meminfo中MemAvailable趋势。
磁盘I/O：区分吞吐、延时与队列深度
iostat默认输出易误导。必须组合三项指标交叉判断：
- await > r_await/w_await：说明读写混合导致调度延迟，非单一方向瓶颈；
- %util接近100%但svctm远低于await：表明I/O请求在队列中等待，可能是应用并发过高或存储后端拥塞；
- avgqu-sz（平均队列长度）持续 > 队列深度（如NVMe一般为64+）：硬件已饱和，需降负载或扩容；
- 直接监控blktrace或iosnoop：定位具体进程的随机读写模式，例如数据库redo log刷盘抖动。
网络与连接状态：从协议栈纵深观测
netstat/ss仅看连接数远远不够：
- TCP重传率（netstat -s | grep -i "retransmitted"）：> 0.5%需排查丢包或接收窗口不足；
- 连接状态分布（ESTABLISHED/SYN_RECV/TIME_WAIT）：SYN_RECV突增可能SYN Flood；TIME_WAIT过多需调优net.ipv4.tcp_tw_reuse；
- socket缓冲区丢包（ss -i 输出中的"rcv_space"与"rwnd"差异）：接收窗口长期小于应用读取速度，导致发送方限速；
- /proc/net/snmp中ICMP/UDP错误计数：如UdpNoPorts飙升，说明UDP包发往无监听端口，可能是配置错误或扫描行为。
指标设计要匹配采集粒度与存储成本。高频指标（如CPU每秒）可采样聚合，低频指标（如OOM事件）必须原始记录。所有指标需带标签（主机名、实例角色、挂载点、网卡名），否则无法下钻归因。
