性能监控的核心目标不是“把所有指标都收集起来”，而是用最少的指标、在最早的时间点发现问题、在最短的时间内定位到最可能的资源瓶颈。
以下是目前生产环境中（尤其云原生、容器化、微服务场景）最常使用、最有诊断价值的指标体系，按资源类型分类，每项都说明：
- 指标含义
- 采集来源（/proc、sysfs、工具）
- 关键阈值 / 异常表现（经验参考）
- 它真正能告诉你什么（诊断价值）
- 对应最常见的根因
1. CPU 相关核心指标
| 指标名称 | 来源 / 命令 | 含义与计算方式 | 关键阈值（经验） | 诊断价值与常见根因 |
|---|
| load average (1/5/15min) | uptime /proc/loadavg | 过去 1/5/15 分钟内处于 Running 或 Uninterruptible 的任务平均数 | > 核数×1.5–2.0 开始关注 > 核数×3.0 严重过载 | 综合压力最直观指标；高但 CPU 使用率低 → 大量等待（IO/锁/网络） |
| %usr + %sys | top / mpstat / sar -u | 用户态 + 内核态 CPU 使用率 | 持续 > 80–90% → 计算密集 | 真正 CPU 计算饱和；usr 高 → 应用代码，sys 高 → 内核栈/中断 |
| %iowait / %wa | top / vmstat / mpstat | CPU 等待磁盘 IO 的时间占比 | > 15–30% 持续 → 明显 IO 瓶颈 | 最经典的“假高负载、真 IO 瓶颈”指标 |
| %steal / %st | mpstat / top（虚拟化可见） | 被 hypervisor 偷走的 CPU 时间（云主机专属） | > 5–10% 持续 → 宿主机超卖或 noisy neighbor | 云上机器特有；高 steal 常伴随响应抖动 |
| runq-sz / r | vmstat / sar -q | 当前可运行（就绪）但未调度上的任务数 | 持续 > 核数×1.5–2.0 → CPU 调度压力大 | 比 load 更精确的“CPU 真的不够用”指标 |
| cs (context switch) | vmstat / pidstat -w | 每秒上下文切换次数 | > 10k–50k/s 开始关注 > 100k/s 严重 | 高 cs + load 高但 CPU 不满 → 锁竞争 / 线程过多 |
2. 内存相关核心指标
| 指标名称 | 来源 / 命令 | 含义 | 关键阈值（经验） | 诊断价值与常见根因 |
|---|
| MemAvailable | free -wh / /proc/meminfo | 系统实际还能给新应用分配的内存（最重要！） | < 总内存 10–15% 持续下降 → 真的缺内存 | 唯一真正判断“内存是否够用”的指标；不要只看 used |
| Committed_AS | /proc/meminfo | 当前已承诺（malloc 但未实际使用）的内存总量 | > 总内存 100–120% → 可能触发 OOM | 预测未来 OOM 风险，比 used 更有前瞻性 |
| AnonPages | /proc/meminfo | 匿名页（进程堆、栈、mmap 私有）占用 | 持续快速增长 → 内存泄漏 | 区分是应用真实使用还是 page cache |
| Dirty + Writeback | /proc/meminfo | 脏页 + 正在回写的页面 | Dirty > 几 GB 且持续上升 → 写压力大 | 脏页堆积会导致 kswapd 活跃、IO 阻塞 |
| Slab / SReclaimable | /proc/meminfo / slabtop | 内核 slab 缓存（dentry/inode/slub） | dentry/inode 几 GB → 元数据压力 | 高并发小文件场景常见；vfs_cache_pressure 可调 |
| Swap Used / si/so | free -h / vmstat | 已用 swap + 每秒 swap in/out | si/so 非零且持续 → 内存压力已很严重 | swap 抖动是延迟毛刺最常见元凶之一 |
3. 磁盘 IO 核心指标
| 指标名称 | 来源 / 命令 | 含义 | 关键阈值（经验） | 诊断价值与常见根因 |
|---|
| %util | iostat -x | 磁盘忙碌时间百分比（最重要！） | > 80–90%（单个盘）→ 饱和 | IO 瓶颈最直接指标；接近 100% 几乎一定有问题 |
| await | iostat -x | 平均每次 IO 完成时间（包括队列等待） | > 10–20ms（SSD）> 50–100ms（机械盘） | await >> svctm → 队列排队严重；await 极高 → 单次 IO 很慢 |
| r/s + w/s | iostat -x | 每秒读/写次数 | r/s > 几千 → 随机读密集 | 判断是随机还是顺序 IO |
| rMB/s + wMB/s | iostat -x | 每秒读/写吞吐量 | 远低于磁盘规格 → 随机 IO 主导 | 吞吐低但 %util 高 → 随机小块 IO 瓶颈 |
| avgqu-sz | iostat -x | 平均 IO 队列长度 | > 1–2（单盘）持续 → 排队严重 | 队列积压是延迟抖动主因 |
4. 网络核心指标
| 指标名称 | 来源 / 命令 | 含义 | 关键阈值（经验） | 诊断价值与常见根因 |
|---|
| retransmitted segments | ss -s / netstat -s | TCP 重传段数 | 持续增长 > 1–5% → 网络质量差 | 最直接的网络拥塞 / 丢包指标 |
| listen drops / overflows | ss -s / netstat -s | listen 队列溢出 | 非零且持续增长 → 连接建立被拒绝 | 新连接建立慢最常见原因 |
| tcp_tw_buckets / TIME_WAIT | ss -s | TIME_WAIT 数量 | > 几万–十几万 → 端口耗尽可能 | 高并发短连接场景常见；调 tcp_tw_reuse / fin_timeout |
| rx/tx errors / drops | sar -n DEV / ip -s link | 网卡硬件层丢包 / 错误 | 非零且增长 → 网卡 / 驱动 / 物理链路问题 | 硬件层问题最直接证据 |
5. 系统整体压力指标
| 指标名称 | 来源 | 含义 | 关键阈值 | 诊断价值 |
|---|
| Pressure Stall Information (PSI) | /proc/pressure/{cpu,memory,io} | 任务因资源不足被 stall 的时间占比 | some > 10–20%，full > 1–5% → 严重压力 | cgroup v2 时代最敏感的“系统真实压力”指标 |
| nr_running / nr_iowait | /proc/stat | 当前运行中 + 等待 IO 的进程数 | nr_iowait 持续 > 0 → IO 等待 | 与 load average 类似但更精确 |
| procs_blocked | vmstat / /proc/stat | 当前处于 D 状态（不可中断睡眠）的进程数 | > 0 且持续 → IO 或其他阻塞 | D 状态进程是“假高负载”的经典证据 |
推荐的核心监控指标组合（Grafana / Prometheus 常用 Dashboard）
必须监控的 Top 10（生产环境建议至少覆盖这些）：
- load1 / load5 / load15 per core
- CPU: %usr + %sys + %iowait + %steal
- MemAvailable percentage + Swap Used
- Disk: %util, await, r/s, w/s, rMB/s, wMB/s（每个盘单独）
- Network: tcp_retransmit rate, listen drops, TIME_WAIT count
- PSI: cpu.some/full, memory.some/full, io.some/full
- Context Switches / sec
- Softirq NET_RX / NET_TX
- Dirty Pages + Writeback
- OOM killer events（counter）
你现在最关心哪一类指标？ （CPU？内存？磁盘 IO？网络？还是想做一套完整的 Prometheus + Grafana 监控？）
