云栈社区»论坛 › 站务中心「 Forum Service 」 › Linux系统监控：CPU、内存、磁盘IO性能指标解析与实战排查 ...

发回帖发新帖

704 积分	0 好友	96 主题

发消息

Linux系统监控：CPU、内存、磁盘IO性能指标解析与实战排查

发表于 14 小时前 | 查看: 1| 回复: 0

一、概述

1.1 背景介绍

系统监控是运维工作的核心环节，它直接关系到业务的稳定性和故障响应的效率。Linux 系统提供了丰富的性能指标采集机制，通过 /proc 和 /sys 这两个虚拟文件系统，内核将运行时的数据暴露出来。再配合各类监控工具，我们就能实现对 CPU、内存、磁盘 IO、网络等关键资源的实时观测。

在云原生架构下，单机监控已经演变为分布式可观测性体系的关键组成部分。掌握底层监控指标的含义和采集方法，是构建有效告警策略、进行性能调优、快速定位故障根因的基础能力。本文将从 SRE 的工程实践角度出发，系统地梳理 Linux 核心监控指标的技术原理与分析方法。

1.2 技术特点

内核级数据源：所有监控指标均来源于 Linux 内核通过 procfs/sysfs 暴露的实时数据，具备高精度和低开销的特性。
多维度覆盖：涵盖 CPU 调度、内存管理、块设备 IO、网络协议栈等核心子系统，支持全栈性能分析。
工具链成熟：从基础的 vmstat、iostat 到高级的 perf、eBPF，形成了完整的监控工具生态。
标准化输出：指标格式遵循 POSIX 规范，便于与 Prometheus、Grafana 等现代监控平台集成。

1.3 适用场景

容量规划：通过分析历史监控数据中的资源使用趋势，预测扩容时机，避免资源瓶颈影响业务。
性能调优：识别出 CPU 密集型或 IO 密集型的工作负载特征，从而针对性地优化系统参数和应用配置。
故障诊断：结合多维度的指标进行关联分析，快速定位系统异常的根因，缩短 MTTR（平均修复时间）。
SLA 保障：建立基于监控指标的告警体系，实现故障预警和自动化响应。

1.4 环境要求

组件	版本要求	说明
操作系统	CentOS 8+/Ubuntu 20.04+/Debian 11+	内核版本建议 4.15 以上，支持完整的 cgroup v2 和 eBPF 特性
procps-ng	4.0+	提供 ps、top、vmstat、free 等基础工具
sysstat	12.7+	提供 iostat、mpstat、sar 等性能统计工具
htop	3.3+	增强型交互式进程监控工具
iotop	0.6+	磁盘 IO 实时监控工具
perf	与内核版本匹配	Linux 性能分析框架

二、详细步骤

2.1 准备工作

2.1.1 系统环境检查

# 检查内核版本，确认支持所需特性
uname -r
# 预期输出：5.15.0-91-generic 或更高版本

# 检查procfs挂载状态
mount | grep proc
# 预期输出：proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

# 验证sysfs可用性
ls /sys/class/block/
# 预期输出：列出所有块设备

# 检查cgroup版本
cat /sys/fs/cgroup/cgroup.controllers 2>/dev/null && echo "cgroup v2" || echo "cgroup v1"

2.1.2 监控工具安装

RHEL/CentOS/Rocky Linux 系统：

# 安装sysstat工具包
dnf install -y sysstat

# 安装htop增强监控
dnf install -y epel-release
dnf install -y htop iotop

# 安装perf性能分析工具
dnf install -y perf

# 启用sysstat数据采集服务
systemctl enable --now sysstat

Debian/Ubuntu 系统：

# 更新软件源
apt update

# 安装完整监控工具集
apt install -y sysstat htop iotop linux-tools-common linux-tools-$(uname -r)

# 启用sysstat定时采集
sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
systemctl restart sysstat

2.1.3 数据源目录结构

Linux 监控数据主要来源于以下虚拟文件系统：

# CPU相关信息
/proc/stat # CPU时间统计
/proc/loadavg # 系统负载
/proc/cpuinfo # CPU硬件信息

# 内存相关信息
/proc/meminfo # 内存使用详情
/proc/vmstat # 虚拟内存统计
/proc/buddyinfo # 内存碎片信息

# 磁盘IO相关信息
/proc/diskstats # 块设备IO统计
/sys/block/*/stat # 单设备IO统计
/proc/io # 进程级IO统计（需要root权限）

# 网络相关信息
/proc/net/dev # 网络接口统计
/proc/net/snmp # 协议层统计

2.2 CPU监控指标详解

2.2.1 CPU时间片分布

CPU 时间按使用类型划分为多个维度，理解各维度的含义是性能分析的基础。

# 查看原始CPU统计数据
cat /proc/stat | head -1
# 输出格式：cpu user nice system idle iowait irq softirq steal guest guest_nice

# 使用mpstat查看格式化输出（每秒刷新，共5次）
mpstat -P ALL 1 5

CPU时间维度说明：

指标	含义	正常范围	异常诊断方向
%user	用户态 CPU 时间（不含 nice 调整进程）	0-70%	高值表示应用计算密集，检查热点函数
%nice	nice 值调整后的用户态时间	0-5%	高值检查是否有大量低优先级任务
%system	内核态 CPU 时间	0-30%	高值可能存在频繁系统调用或内核 bug
%iowait	等待 IO 完成的 CPU 时间	0-20%	高值表示 IO 瓶颈，需分析磁盘性能
%irq	硬中断处理时间	0-5%	高值检查网卡中断、磁盘中断分布
%softirq	软中断处理时间	0-10%	高值常见于高网络流量场景
%steal	虚拟化环境被宿主机占用的时间	0-5%	高值表示虚拟机资源争抢严重
%idle	CPU 空闲时间	20-100%	低值需结合其他指标判断瓶颈类型

2.2.2 系统负载（Load Average）

系统负载反映了运行队列中等待 CPU 的任务数量，是评估系统繁忙程度的关键指标。

# 查看系统负载
cat /proc/loadavg
# 输出：0.52 0.48 0.45 2/1089 28754
# 含义：1分钟/5分钟/15分钟负载 运行进程数/总进程数 最近创建的PID

# 使用uptime查看负载
uptime
# 输出：10:23:45 up 45 days, 3:21, 2 users, load average: 0.52, 0.48, 0.45

# 获取CPU核心数用于负载评估
nproc
# 或
grep -c processor /proc/cpuinfo

负载评估原则：

负载值 < CPU 核心数：系统资源充足
负载值 = CPU 核心数：系统满载运行
负载值 > CPU 核心数 × 1.5：存在资源争抢，需要关注
负载值 > CPU 核心数 × 2：系统过载，可能影响响应时间

#!/bin/bash
# 负载趋势分析脚本
CORES=$(nproc)
LOAD=$(awk '{print $1}' /proc/loadavg)
RATIO=$(echo "$LOAD / $CORES" | awk '{printf "%.2f", $1/$2}')

echo "CPU Cores: $CORES"
echo "Current Load: $LOAD"
echo "Load Ratio: $RATIO"

if (( $(echo "$RATIO > 1.5" | bc -l) )); then
  echo "WARNING: System is overloaded!"
fi

2.2.3 CPU使用率实时监控

# 使用top命令监控（按1键展开各CPU核心）
top -bn1 | head -20

# 使用htop获得更友好的交互界面
htop

# 监控特定进程的CPU使用
pidstat -u 1 5

# 按CPU使用率排序进程
ps aux --sort=-%cpu | head -10

top 命令关键字段解读：

top - 10:30:45 up 45 days,  3:28,  2 users,  load average: 1.23, 0.98, 0.76
Tasks: 287 total,   2 running, 285 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.2 us,  2.1 sy,  0.0 ni, 91.5 id,  0.8 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :  15896.4 total,   1234.5 free,   8765.4 used,   5896.5 buff/cache
MiB Swap:   4096.0 total,   4096.0 free,      0.0 used.   6543.2 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1234 mysql     20   0 12.5g   8.2g  12345 S  45.2  52.8  12345:67 mysqld
 5678 nginx     20   0  256m   128m   4567 S  12.3   0.8    234:56 nginx

2.3 内存监控指标详解

2.3.1 内存使用全景视图

Linux 内存管理涉及物理内存、虚拟内存、缓存等多个层面，/proc/meminfo 提供完整的内存状态信息：

# 查看完整内存信息
cat /proc/meminfo

# 使用free命令查看摘要（-h人性化显示）
free -h
# 输出示例：
#               total        used        free      shared  buff/cache   available
# Mem:           15Gi       8.5Gi       1.2Gi       256Mi       5.8Gi       6.4Gi
# Swap:         4.0Gi          0B       4.0Gi

# 持续监控内存变化（每2秒刷新）
watch -n 2 free -h

关键内存指标解析：

指标	含义	计算方式	监控建议
MemTotal	物理内存总量	硬件配置	基准值，用于计算使用率
MemFree	完全空闲内存	未被任何进程使用	不建议作为告警依据
MemAvailable	可用内存估算	Free + 可回收缓存	推荐作为内存告警指标
Buffers	块设备缓冲区	内核缓冲区	通常较小，几十 MB 级别
Cached	页面缓存	文件系统缓存	可被回收，不算真正占用
SwapTotal	交换空间总量	配置值	建议为物理内存的 0.5-1 倍
SwapFree	可用交换空间	未使用的 Swap	持续减少需关注

2.3.2 内存使用率计算

#!/bin/bash
# 文件名：mem_usage.sh
# 正确的内存使用率计算方法

# 从/proc/meminfo提取关键值（单位：kB）
MEM_TOTAL=$(awk '/MemTotal/ {print $2}' /proc/meminfo)
MEM_AVAILABLE=$(awk '/MemAvailable/ {print $2}' /proc/meminfo)
MEM_BUFFERS=$(awk '/Buffers/ {print $2}' /proc/meminfo)
MEM_CACHED=$(awk '/^Cached/ {print $2}' /proc/meminfo)

# 计算实际使用内存
MEM_USED=$((MEM_TOTAL - MEM_AVAILABLE))

# 计算使用率
USAGE_PERCENT=$(echo "scale=2; $MEM_USED * 100 / $MEM_TOTAL" | bc)

echo "Total Memory: $((MEM_TOTAL / 1024)) MB"
echo "Available Memory: $((MEM_AVAILABLE / 1024)) MB"
echo "Used Memory: $((MEM_USED / 1024)) MB"
echo "Memory Usage: ${USAGE_PERCENT}%"

2.3.3 vmstat内存监控

# vmstat综合监控（每秒采样，共10次）
vmstat 1 10

# 输出字段说明：
# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
#  1  0      0 1234567  89012 5678901    0    0    12    34  567  890  5  2 92  1  0

vmstat 内存相关字段：

swpd：已使用的交换空间（KB）
free：空闲物理内存（KB）
buff：用作缓冲区的内存（KB）
cache：用作缓存的内存（KB）
si：从磁盘换入内存的速率（KB/s）
so：从内存换出到磁盘的速率（KB/s）

# 监控Swap活动（si/so非零表示内存压力）
vmstat 1 | awk 'NR>2 {if($7>0 || $8>0) print "SWAP Activity Detected: si="$7" so="$8}'

2.4 磁盘IO监控指标详解

2.4.1 iostat基础监控

# 查看所有磁盘IO统计（扩展模式，每秒刷新）
iostat -xz 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       12.34   56.78  123.45  567.89    0.12    1.23   0.96   2.12    1.23    2.34   0.12    10.00    10.00   0.56  12.34
# nvme0n1  234.56  123.45 2345.67 1234.56    0.00    0.00   0.00   0.00    0.12    0.23   0.01    10.00    10.00   0.12   5.67

iostat 关键指标解析：

指标	含义	正常范围	异常诊断
r/s， w/s	每秒读写请求数	依设备而定	突增需关注业务变化
rkB/s， wkB/s	每秒读写吞吐量	依设备而定	接近设备上限需扩容
r_await， w_await	读写平均响应时间 (ms)	HDD<20ms, SSD<5ms	高延迟表示 IO 瓶颈
aqu-sz	平均请求队列长度	<2	高值表示 IO 饱和
%util	设备利用率	<70%	持续高值需优化或扩容

2.4.2 块设备原始统计

# 查看块设备原始IO统计
cat /proc/diskstats

# 字段说明（以sda为例）：
#   8    0 sda 12345 678 901234 5678 90123 4567 890123 4567 0 8901 23456 0 0 0 0
# 主设备号 次设备号 设备名 读完成数 读合并数 读扇区数 读耗时(ms) 写完成数 写合并数 写扇区数 写耗时(ms) 当前IO数 IO耗时(ms) 加权IO耗时(ms)

# 单设备统计
cat /sys/block/sda/stat

2.4.3 iotop进程级IO监控

# 实时监控进程IO（需要root权限）
iotop -o  # 仅显示有IO活动的进程

# 批处理模式输出
iotop -b -n 5 -d 1

# 按IO排序进程
iotop -o -P -a

三、示例代码和配置

3.1 完整配置示例

3.1.1 Prometheus Node Exporter配置

Node Exporter 是采集 Linux 系统指标的标准组件，以下为生产环境推荐配置：

# 文件路径：/etc/systemd/system/node_exporter.service
[Unit]
Description=Prometheus Node Exporter
Documentation=https://prometheus.io/docs/guides/node-exporter/
After=network-online.target

[Service]
Type=simple
User=node_exporter
Group=node_exporter
ExecStart=/usr/local/bin/node_exporter \
--web.listen-address=:9100 \
--web.telemetry-path=/metrics \
--collector.filesystem.mount-points-exclude="^/(sys|proc|dev|host|etc)($$|/)" \
--collector.netclass.ignored-devices="^(veth|docker|br-).*" \
--collector.diskstats.device-exclude="^(ram|loop|fd|dm-).*" \
--collector.cpu.info \
--collector.meminfo \
--collector.diskstats \
--collector.netdev \
--collector.loadavg \
--collector.vmstat \
--collector.filesystem \
--collector.pressure \
--no-collector.wifi \
--no-collector.nvme \
--no-collector.infiniband

Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

配置参数说明：

--collector.filesystem.mount-points-exclude：排除虚拟文件系统，减少无效指标。
--collector.diskstats.device-exclude：排除虚拟磁盘设备。
--collector.pressure：启用 PSI（Pressure Stall Information）采集，内核 4.20+ 支持。
--no-collector.wifi：禁用不需要的采集器，降低资源消耗。

3.1.2 Prometheus告警规则配置

# 文件路径：/etc/prometheus/rules/node_alerts.yml
groups:
- name: node_resource_alerts
  interval: 30s
  rules:
  # CPU使用率告警
  - alert: HighCpuUsage
    expr: |
          100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "CPU使用率过高 (实例: {{ $labels.instance }})"
      description: "CPU使用率持续5分钟超过85%，当前值: {{ $value | printf \"%.1f\" }}%"

  # 内存使用率告警
  - alert: HighMemoryUsage
    expr: |
          (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 90
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "内存使用率过高 (实例: {{ $labels.instance }})"
      description: "内存使用率持续5分钟超过90%，当前值: {{ $value | printf \"%.1f\" }}%"

  # 磁盘空间告警
  - alert: DiskSpaceLow
    expr: |
          (1 - node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes) * 100 > 85
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "磁盘空间不足 (实例: {{ $labels.instance }})"
      description: "磁盘 {{ $labels.mountpoint }} 使用率超过85%，当前值: {{ $value | printf \"%.1f\" }}%"

  # 磁盘IO延迟告警
  - alert: HighDiskLatency
    expr: |
          rate(node_disk_read_time_seconds_total[5m]) / rate(node_disk_reads_completed_total[5m]) * 1000 > 50
          or
          rate(node_disk_write_time_seconds_total[5m]) / rate(node_disk_writes_completed_total[5m]) * 1000 > 50
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "磁盘IO延迟过高 (实例: {{ $labels.instance }})"
      description: "磁盘 {{ $labels.device }} IO延迟超过50ms"

  # 系统负载告警
  - alert: HighLoadAverage
    expr: |
          node_load15 / count without(cpu, mode) (node_cpu_seconds_total{mode="idle"}) > 1.5
    for: 15m
    labels:
      severity: warning
    annotations:
      summary: "系统负载过高 (实例: {{ $labels.instance }})"
      description: "15分钟负载与CPU核心数比值超过1.5，当前值: {{ $value | printf \"%.2f\" }}"

  # Swap使用告警
  - alert: SwapUsageHigh
    expr: |
          (node_memory_SwapTotal_bytes - node_memory_SwapFree_bytes) / node_memory_SwapTotal_bytes * 100 > 50
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "Swap使用率过高 (实例: {{ $labels.instance }})"
      description: "Swap使用率超过50%，可能存在内存压力，当前值: {{ $value | printf \"%.1f\" }}%"

3.2 实际应用案例

案例一：MySQL数据库服务器性能诊断

场景描述：生产环境 MySQL 服务器响应变慢，需要通过系统监控指标定位瓶颈。

诊断脚本：

#!/bin/bash
# 文件名：mysql_server_diagnosis.sh
# 功能：MySQL服务器性能快速诊断

echo "========== MySQL Server Performance Diagnosis =========="
echo "Time: $(date '+%Y-%m-%d %H:%M:%S')"
echo ""

# 1. 系统负载检查
echo ">>> System Load Average"
uptime
CORES=$(nproc)
LOAD1=$(awk '{print $1}' /proc/loadavg)
echo "CPU Cores: $CORES, Load/Core Ratio: $(echo "scale=2; $LOAD1/$CORES" | bc)"
echo ""

# 2. CPU使用分布
echo ">>> CPU Usage Distribution (5s sample)"
mpstat 1 5 | tail -1
echo ""

# 3. 内存状态
echo ">>> Memory Status"
free -h
echo ""
echo "MySQL Process Memory:"
ps aux | grep -E "^mysql|^USER" | head -2
echo ""

# 4. IO状态检查
echo ">>> Disk IO Status"
iostat -xz 1 3 | grep -E "^Device|^sd|^nvme|^vd"
echo ""

# 5. MySQL进程IO
echo ">>> MySQL Process IO (requires root)"
if [ $(id -u) -eq 0 ]; then
    iotop -b -n 3 -d 1 -P | grep -i mysql
else
  echo "Skip: requires root privilege"
fi
echo ""

# 6. Swap活动检查
echo ">>> Swap Activity Check"
vmstat 1 5 | awk 'NR==1 || NR==2 || NR>2 {print}'
echo ""

# 7. 网络连接状态
echo ">>> MySQL Network Connections"
ss -tn state established '( dport = :3306 or sport = :3306 )' | wc -l
echo "Active MySQL connections: $(ss -tn state established '( dport = :3306 or sport = :3306 )' | wc -l)"
echo ""

echo "========== Diagnosis Complete =========="

运行结果分析：

========== MySQL Server Performance Diagnosis ==========
Time: 2026-01-15 14:30:45

>>> System Load Average
 14:30:45 up 120 days,  5:23,  3 users,  load average: 8.52, 7.89, 6.45
CPU Cores: 8, Load/Core Ratio: 1.06

>>> CPU Usage Distribution (5s sample)
Average:     all    2.34    0.00   12.56    0.00   45.67    0.12    1.23    0.00   38.08

>>> Memory Status
              total        used        free      shared  buff/cache   available
Mem:           62Gi        58Gi       512Mi       1.2Gi       3.8Gi       2.1Gi
Swap:         8.0Gi       2.3Gi       5.7Gi

>>> Disk IO Status
Device     r/s     w/s   rkB/s   wkB/s  r_await w_await  %util
sda      456.78  234.56  4567.8  2345.6    12.34   45.67  89.12

诊断结论：

CPU iowait 高达 45.67%：表明存在严重 IO 等待，CPU 大量时间消耗在等待磁盘。
内存可用仅 2.1GB：62GB 总内存几乎耗尽，已开始使用 Swap。
磁盘利用率 89.12%：接近饱和，写延迟 45.67ms 远超正常值。
根因判断：内存不足导致 MySQL buffer pool 无法完全缓存热数据，频繁磁盘读取造成 IO 瓶颈。

优化建议：扩展内存至 128GB，或优化 MySQL innodb_buffer_pool_size 配置。

案例二：Web应用服务器CPU飙升排查

场景描述：Nginx+PHP-FPM 架构的 Web 服务器 CPU 突然飙升至 95% 以上，需要快速定位问题进程。

排查步骤：

# 步骤1：查看整体CPU状态
top -bn1 | head -15

# 步骤2：按CPU排序查看进程
ps aux --sort=-%cpu | head -20

# 步骤3：查看PHP-FPM进程状态
ps aux | grep php-fpm | grep -v grep | wc -l
echo "PHP-FPM worker count: $(ps aux | grep 'php-fpm: pool' | wc -l)"

# 步骤4：检查是否存在异常进程
ps aux --sort=-%cpu | awk '$3>50 {print $0}'

# 步骤5：使用pidstat定位具体进程
pidstat -u 1 10 | sort -k8 -rn | head -20

实际输出：

# ps aux --sort=-%cpu | head -10
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
www-data 23456 98.2  2.1 456789 123456 ?       R    14:25  15:23 php-fpm: pool www
www-data 23457 95.6  2.0 456123 121234 ?       R    14:25  14:56 php-fpm: pool www
www-data 23458 94.8  1.9 455678 119876 ?       R    14:26  14:12 php-fpm: pool www
nginx    12345  5.2  0.3  98765  34567 ?       S    09:00   2:34 nginx: worker

进一步分析：

# 使用strace追踪高CPU进程的系统调用
strace -c -p 23456 -f -e trace=all 2>&1 | head -30

# 查看进程打开的文件
ls -la /proc/23456/fd | wc -l

# 检查进程当前执行的PHP脚本
cat /proc/23456/cmdline

根因定位：通过 strace 发现进程在执行大量正则匹配操作，结合访问日志分析，确认是某个 API 接口存在正则表达式性能问题（ReDoS 漏洞）。

四、最佳实践和注意事项

4.1 最佳实践

4.1.1 监控指标采集优化

合理的采集策略能够平衡监控精度与系统开销：

# 优化sysstat采集频率配置
# 文件：/etc/cron.d/sysstat

# 生产环境推荐：每分钟采集一次
*/1 * * * * root /usr/lib64/sa/sa1 1 1

# 每天23:53生成日报
53 23 * * * root /usr/lib64/sa/sa2 -A

采集频率建议：

实时告警指标：10-30 秒采集间隔，用于快速故障发现。
趋势分析指标：1-5 分钟采集间隔，用于容量规划。
历史归档指标：按小时/天聚合存储，降低存储成本。

# Node Exporter采集性能优化
# 限制采集器数量，减少不必要的指标
node_exporter \
  --collector.disable-defaults \
  --collector.cpu \
  --collector.meminfo \
  --collector.diskstats \
  --collector.filesystem \
  --collector.loadavg \
  --collector.netdev

4.1.2 告警阈值设置原则

避免告警风暴和漏报的关键在于合理的阈值设计：

资源类型	警告阈值	严重阈值	持续时间	说明
CPU 使用率	80%	95%	5 分钟	排除短暂峰值干扰
内存使用率	85%	95%	5 分钟	基于 MemAvailable 计算
磁盘使用率	80%	90%	10 分钟	预留扩容时间窗口
磁盘 IO 延迟	30ms	100ms	3 分钟	SSD 标准，HDD 适当放宽
系统负载	核心数 × 1.2	核心数 × 2	10 分钟	考虑业务峰值特征
Swap 使用	30%	60%	10 分钟	任何 Swap 使用都需关注

4.1.3 监控数据保留策略

# Prometheus存储配置示例
# 文件：/etc/prometheus/prometheus.yml

global:
  scrape_interval: 15s
  evaluation_interval: 15s

storage:
  tsdb:
    path: /var/lib/prometheus/data
    retention.time: 30d # 原始数据保留30天
    retention.size: 100GB # 存储空间上限

# 配合Thanos实现长期存储
# 降采样后的数据可保留1年以上

4.2 注意事项

4.2.1 监控盲区规避

常见的监控盲区及应对策略：

短时峰值遗漏：采集间隔过长可能错过瞬时异常，关键指标建议 10 秒级采集。
聚合数据失真：平均值掩盖极端情况，应同时监控 P95/P99 分位数。
容器环境特殊性：cgroup 限制下的资源视图与宿主机不同，需使用容器感知的采集方式。

# 容器内正确获取CPU限制
cat /sys/fs/cgroup/cpu.max  # cgroup v2
# 输出：100000 100000 表示可用100%的1个CPU核心

# 容器内正确获取内存限制
cat /sys/fs/cgroup/memory.max  # cgroup v2

4.2.2 常见误区

误区	正确理解	影响
MemFree 低就是内存不足	应关注 MemAvailable，缓存可回收	误报告警
CPU idle 低就是性能问题	需区分 user/system/iowait 占比	误判瓶颈类型
磁盘 util 100% 就是瓶颈	NVMe 设备可并行处理，util 参考价值有限	过度优化
负载高于核心数就异常	IO 密集型负载正常偏高	误报告警

4.2.3 虚拟化环境注意事项

虚拟机和容器环境下的监控存在特殊性：

# 检测是否运行在虚拟化环境
systemd-detect-virt
# 输出：kvm/vmware/xen/docker/lxc 等

# 虚拟机环境关注steal时间
mpstat 1 5 | awk '{print $NF}' # 查看%steal列

# 容器环境使用cAdvisor采集
docker run -d \
  --name=cadvisor \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --publish=8080:8080 \
  gcr.io/cadvisor/cadvisor:latest

五、故障排查和监控

5.1 故障排查

5.1.1 日志查看

# 查看系统日志（systemd环境）
journalctl -xe --no-pager | tail -100

# 按时间范围查看日志
journalctl --since "2026-01-15 10:00:00" --until "2026-01-15 12:00:00"

# 查看内核日志（OOM、硬件错误等）
dmesg -T | tail -50

# 查看OOM Killer记录
dmesg -T | grep -i "out of memory"
journalctl -k | grep -i oom

5.1.2 CPU问题排查

问题一：CPU使用率持续100%

# 诊断命令：定位高CPU进程
top -bn1 -o %CPU | head -15

# 查看进程线程级CPU使用
top -H -p $(pgrep -f "进程名")

# 使用perf分析热点函数
perf top -p $(pgrep -f "进程名")

解决方案：

确认是用户态还是内核态消耗。
用户态高：检查应用代码逻辑，使用 profiler 定位热点。
内核态高：检查系统调用频率，可能存在锁竞争或驱动问题。

问题二：iowait异常升高

# 诊断命令：确认IO等待来源
iostat -xz 1 5

# 定位产生IO的进程
iotop -o -b -n 5

# 查看进程IO详情
cat /proc/$(pgrep -f "进程名")/io

解决方案：

检查是否存在大量随机读写。
评估是否需要增加内存以提升缓存命中率。
考虑升级存储设备（HDD 升级 SSD）。

5.1.3 内存问题排查

问题一：OOM Killer触发

# 查看OOM事件详情
dmesg -T | grep -A 20 "Out of memory"

# 分析被杀进程
journalctl -k | grep -E "Killed process|oom-kill"

# 查看当前内存压力
cat /proc/pressure/memory

解决方案：

分析 OOM 日志确定被杀进程和触发原因。
调整进程 oom_score_adj 保护关键服务。
增加物理内存或优化应用内存使用。

问题二：内存泄漏检测

# 监控进程内存增长趋势
pidstat -r 60 1440 > /tmp/mem_trend.log &

# 查看进程内存映射详情
pmap -x $(pgrep -f "进程名") | tail -1

# 使用smaps分析内存组成
cat /proc/$(pgrep -f "进程名")/smaps_rollup

5.2 性能监控

5.2.1 关键指标监控

#!/bin/bash
# 文件名：system_health_check.sh
# 综合性能监控脚本

echo "===== System Health Check ====="
echo "Time: $(date '+%Y-%m-%d %H:%M:%S')"
echo ""

# CPU状态
echo "[CPU]"
mpstat 1 1 | tail -1 | awk '{printf "User: %.1f%% System: %.1f%% IOWait: %.1f%% Idle: %.1f%%\n", $3, $5, $6, $12}'

# 内存状态
echo "[Memory]"
free -h | awk 'NR==2 {printf "Total: %s Used: %s Available: %s\n", $2, $3, $7}'

# 磁盘IO
echo "[Disk IO]"
iostat -xz 1 1 | awk '/^[sv]d|^nvme/ {printf "%s: util=%.1f%% await=%.1fms\n", $1, $NF, $10}'

# 系统负载
echo "[Load]"
cat /proc/loadavg | awk '{printf "1min: %s 5min: %s 15min: %s\n", $1, $2, $3}'

5.2.2 监控指标说明

指标名称	正常范围	告警阈值	说明
CPU 使用率	0-70%	>85% 持续 5 分钟	排除 idle 后的总使用率
内存使用率	0-80%	>90% 持续 5 分钟	基于 MemAvailable 计算
磁盘 IO 延迟	SSD<5ms, HDD<20ms	>50ms	读写平均响应时间
磁盘利用率	0-70%	>85%	注意 NVMe 设备特殊性
系统负载	< 核心数	> 核心数 × 1.5	15 分钟平均值
网络丢包率	0%	>0.1%	任何丢包都需关注

5.3 备份与恢复

5.3.1 监控数据备份策略

#!/bin/bash
# 文件名：prometheus_backup.sh
# 功能：Prometheus TSDB数据备份

BACKUP_DIR="/backup/prometheus"
DATA_DIR="/var/lib/prometheus/data"
DATE=$(date +%Y%m%d)

# 创建快照
curl -X POST http://localhost:9090/api/v1/admin/tsdb/snapshot

# 获取快照目录
SNAPSHOT=$(ls -t ${DATA_DIR}/snapshots/ | head -1)

# 压缩备份
tar -czf ${BACKUP_DIR}/prometheus_${DATE}.tar.gz \
    -C ${DATA_DIR}/snapshots ${SNAPSHOT}

# 清理7天前的备份
find ${BACKUP_DIR} -name "prometheus_*.tar.gz" -mtime +7 -delete

# 清理快照
rm -rf ${DATA_DIR}/snapshots/${SNAPSHOT}

echo "Backup completed: prometheus_${DATE}.tar.gz"

5.3.2 恢复流程

# 1. 停止Prometheus服务
systemctl stop prometheus

# 2. 解压备份数据
tar -xzf /backup/prometheus/prometheus_20260115.tar.gz \
    -C /var/lib/prometheus/data/

# 3. 验证数据完整性
promtool tsdb analyze /var/lib/prometheus/data/

# 4. 重启服务
systemctl start prometheus

# 5. 验证恢复结果
curl -s http://localhost:9090/api/v1/query?query=up | jq .

六、总结

6.1 技术要点回顾

CPU 监控核心：区分 user/system/iowait/steal 等时间维度，结合负载评估系统繁忙程度，iowait 高需关注 IO 子系统。
内存监控要点：使用 MemAvailable 而非 MemFree 评估可用内存，关注 Swap 活动作为内存压力信号。
IO 监控关键：await 延迟和 util 利用率是核心指标，NVMe 设备需结合 IOPS 和吞吐量综合判断。
工具链选择：基础监控使用 vmstat/iostat/free，深度分析使用 perf/eBPF，生产环境推荐 Prometheus+Grafana 体系。

6.2 进阶学习方向

eBPF 性能分析
- 学习资源：BPF Performance Tools (Brendan Gregg 著)
- 实践建议：从 bcc 工具集入手，逐步掌握 bpftrace 编写自定义追踪脚本。
分布式追踪
- 学习资源：OpenTelemetry 官方文档
- 实践建议：结合 Jaeger/Zipkin 实现跨服务调用链追踪。
AIOps 智能运维
- 学习资源：时序数据异常检测算法
- 实践建议：基于历史监控数据训练异常检测模型，实现智能告警。

6.3 参考资料

Linux Kernel Documentation - procfs - 内核官方 procfs 文档
Brendan Gregg‘s Linux Performance - Linux 性能分析权威资源
Prometheus Documentation - Prometheus 官方文档
Node Exporter GitHub - Node Exporter 项目主页
sysstat Documentation - sysstat 工具集文档

对于系统监控这类深度技术话题，持续学习与交流至关重要。如果你在实践中遇到了其他有趣的案例或有独到的见解，欢迎在云栈社区的相关板块参与讨论，与更多开发者一同探索运维领域的深层技术。

附录

A. 命令速查表

# CPU监控
mpstat -P ALL 1 5         # 查看各CPU核心使用率
pidstat -u 1 10           # 进程级CPU监控
perf top                  # 实时热点函数分析

# 内存监控
free -h                   # 内存使用摘要
vmstat 1 10               # 内存和Swap活动
pmap -x <pid>             # 进程内存映射

# 磁盘IO监控
iostat -xz 1 5            # 磁盘IO统计
iotop -o                  # 进程级IO监控
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT  # 块设备列表

# 系统综合
top -bn1                  # 系统概览快照
htop                      # 交互式进程监控
sar -A                    # 历史性能数据
dmesg -T | tail -50       # 内核日志

B. /proc文件系统关键文件

文件路径	内容说明	常用场景
/proc/stat	CPU 时间统计	计算 CPU 使用率
/proc/loadavg	系统负载	负载监控告警
/proc/meminfo	内存详细信息	内存使用分析
/proc/vmstat	虚拟内存统计	页面换入换出监控
/proc/diskstats	块设备 IO 统计	磁盘性能分析
/proc/net/dev	网络接口统计	网络流量监控
/proc/[pid]/stat	进程状态	进程级监控
/proc/[pid]/io	进程 IO 统计	进程 IO 分析
/proc/pressure/*	PSI 压力指标	资源压力评估

C. 术语表

术语	英文	解释
负载	Load Average	运行队列中等待 CPU 的平均任务数，反映系统繁忙程度
iowait	I/O Wait	CPU 等待 IO 操作完成的时间占比
上下文切换	Context Switch	CPU 从一个进程/线程切换到另一个的操作
缺页中断	Page Fault	访问的内存页不在物理内存中，需要从磁盘加载
OOM	Out of Memory	内存耗尽，内核触发 OOM Killer 终止进程
PSI	Pressure Stall Information	Linux 4.20+ 引入的资源压力量化指标
IOPS	I/O Operations Per Second	每秒 IO 操作次数，衡量存储性能
吞吐量	Throughput	单位时间内传输的数据量
延迟	Latency	请求发出到响应返回的时间间隔
利用率	Utilization	资源被使用的时间占比

上一篇：警惕！两款下载量超150万的VS Code AI扩展被曝暗中窃取源代码
下一篇：Dify技术VP周宇：从CTF冠军到AI架构师的技术演进与安全实践

Linux, 系统监控, 性能分析, 运维, 故障诊断

Linux系统监控：CPU、内存、磁盘IO性能指标解析与实战排查

一、概述

1.1 背景介绍

1.2 技术特点

1.3 适用场景

1.4 环境要求

二、详细步骤

2.1 准备工作

2.1.1 系统环境检查

2.1.2 监控工具安装

2.1.3 数据源目录结构

2.2 CPU监控指标详解

2.2.1 CPU时间片分布

2.2.2 系统负载（Load Average）

2.2.3 CPU使用率实时监控

2.3 内存监控指标详解

2.3.1 内存使用全景视图

2.3.2 内存使用率计算

2.3.3 vmstat内存监控

2.4 磁盘IO监控指标详解

2.4.1 iostat基础监控

2.4.2 块设备原始统计

2.4.3 iotop进程级IO监控

三、示例代码和配置

3.1 完整配置示例

3.1.1 Prometheus Node Exporter配置

3.1.2 Prometheus告警规则配置

3.2 实际应用案例

案例一：MySQL数据库服务器性能诊断

案例二：Web应用服务器CPU飙升排查

四、最佳实践和注意事项

4.1 最佳实践

4.1.1 监控指标采集优化

4.1.2 告警阈值设置原则

4.1.3 监控数据保留策略

4.2 注意事项

4.2.1 监控盲区规避

4.2.2 常见误区

4.2.3 虚拟化环境注意事项

五、故障排查和监控

5.1 故障排查

5.1.1 日志查看

5.1.2 CPU问题排查

5.1.3 内存问题排查

5.2 性能监控

5.2.1 关键指标监控

5.2.2 监控指标说明

5.3 备份与恢复

5.3.1 监控数据备份策略

5.3.2 恢复流程

六、总结

6.1 技术要点回顾

6.2 进阶学习方向

6.3 参考资料

附录

A. 命令速查表

B. /proc文件系统关键文件

C. 术语表

相关帖子