前面几篇讲的是「单点工具」——查 CPU 用mpstat，查磁盘用iostat。但真实运维里，你需要的是一套能长期采集、随时回看、自动告警的监控体系。单机排查靠top，线上监控靠全家桶。这一篇把sar、dstat、glances三个单机工具和Prometheus这套现代监控系统串起来，帮你从「事后救火」走向「事前预警」。

一、监控的三个层次

先建立一张地图，知道每个工具在哪一层：

top的问题在于它不留痕——你不在的时候发生了什么，它不记录。而线上事故往往发生在凌晨没人看屏的时候，所以历史采集和告警才是生产监控的核心。

二、sar：历史数据的瑞士军刀

sar（System Activity Reporter）是sysstat套件的核心，它的价值在于：后台默默采样，你要的时候能查任意历史时刻的数据。

工作原理

sysstat服务（或 cron）默认每 10 分钟采集一次系统数据，写到/var/log/sysstat/（Debian/Ubuntu）或/var/log/sa/（CentOS/Rocky），文件名形如sa15（15 号）。默认保留约一个月。

先确保采集开启

# Ubuntu/Debian：编辑 /etc/default/sysstat，把 ENABLED 改成 true sudo sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat sudo systemctl restart sysstat # CentOS/Rocky：确认 cron 里有 sysstat 任务 systemctl status sysstat

语法格式

sar [选项] [间隔] [次数] sar [选项] -f /var/log/sa/saDD # 查看历史某天

常用参数（按子系统）

示例与预期输出

实时看 CPU（每秒，共 3 次）：

sar -u 1 3

10:40:01 AM CPU %user %nice %system %iowait %steal %idle 10:40:02 AM all 6.20 0.00 2.10 0.40 0.00 91.30

回看今天上午的负载趋势：

sar -q

10:00:01 AM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 10:00:01 AM 1 210 0.85 0.60 0.52 10:30:01 AM 12 260 8.50 7.20 5.10 <-- 负载飙升 11:00:01 AM 2 215 1.10 2.00 3.50

一眼定位到「10:30 负载突然起来」，这就是sar的杀手锏——事后复盘的时间机器。

看历史某天的内存：

sar -r -f /var/log/sa/sa15

⚠️ 常见错误

• 没开 sysstat 服务，发现/var/log/sa/是空的。sar本身不采集，采集是sysstat服务干的。
• 默认只存一个月，重要数据要定期归档或接入 Prometheus。
• 采样间隔太粗（默认 10 分钟），短时尖峰可能采不到，关键业务可以调密。

三、dstat：多合一实时监控

dstat把vmstat+iostat+netstat+mpstat的能力合到一个命令里，输出彩色、带单位，是「实时看页面」的利器。

安装

sudo apt install dstat -y # Ubuntu sudo dnf install dstat -y # Rocky/CentOS

语法格式

dstat [选项] [间隔] [次数]

常用参数

示例与预期输出

dstat -tcmnd --top-cpu --top-io 1 5

预期输出：

----system---- ----total-cpu-usage---- -dsk/total- -net/total- ---most-expensive--- time |usr sys idl wai hiq siq| read writ| recv send| cpu process io 15-01 10:41:02| 6 2 91 0 0 0| 12k 156k| 0 0 |java 12% mysqld 15-01 10:41:03| 8 3 88 1 0 0| 0 204k| 5k 3k |java 10% rsync

一屏之内，CPU、磁盘、网络、最耗资源的进程全有了，比开五个终端切来切去强太多。

典型用法

# 只看某块盘和网卡的 IO dstat -cd --disk-util --fs /data -N eth0 1

四、glances：现代化全能面板

glances是一个用 Python 写的、跨平台的「系统监控仪表盘」，界面漂亮、信息密度高，还支持 Web 模式和导出。

安装

sudo apt install glances -y # Ubuntu sudo dnf install glances -y # Rocky/CentOS（可能需 EPEL）

使用

glances

它会以彩色面板显示 CPU、内存、磁盘、网络、传感器温度、最耗资源进程等，并自动标记「警告（黄）/严重（红）」阈值。

常用命令行模式（适合写脚本/远程采集）：

# 输出 JSON 给其他系统消费 glances --stdout cpu.idle,mem.used,fs./.percent --quiet # 客户端-服务端模式，集中看多台 glances -s # 服务端 glances -c 192.168.1.10 # 客户端连过去

glances 的定位

• 单机全面体检：登录一台陌生机器，先glances一眼扫过。
• 多机集中：服务端模式可以汇总多台机器的指标。
• 告警：支持阈值触发颜色和外部通知。

比top直观，比自建监控轻量，适合中小规模。

五、Prometheus：从单机走向集群

前面都是「登录到机器上看」，规模一大就不够用了：100 台机器你要一台台登？出问题要等用户报？这时需要Pull 模式的监控系统——Prometheus。

核心架构

┌────────────┐ pull(/metrics) ┌──────────────┐ │ node_exporter │◀────────────────│ Prometheus │ │ (每台机器) │ │ Server │ └────────────┘ └──────┬───────┘ │ 存储 TSDB ┌─────▼──────┐ │ Grafana │ 可视化 └────────────┘ ┌────────────┐ │Alertmanager│ 告警 └────────────┘

• node_exporter：部署在每台被监控机，暴露/metrics接口。
• Prometheus Server：定期去各 exporter「拉」数据（Pull），存进时序数据库（TSDB）。
• Grafana：连 Prometheus，画仪表盘。
• Alertmanager：按规则触发告警（钉钉、邮件、Webhook）。

快速体验

1. 启动 node_exporter（被监控端）：

wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz tar xzf node_exporter-1.7.0.linux-amd64.tar.gz ./node_exporter-1.7.0.linux-amd64/node_exporter &

2. 验证指标接口：

curl -s localhost:9100/metrics | head

# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode. # TYPE node_cpu_seconds_total counter node_cpu_seconds_total{cpu="0",mode="idle"} 123456.78

3. Prometheus 配置抓取：

scrape_configs: - job_name: 'node' static_configs: - targets: ['localhost:9100']

4. 常用 PromQL 查询（告警规则的核心）：

# CPU 使用率超过 80%（持续 5 分钟） 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80 # 内存使用率 (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 # 根分区剩余空间小于 10% node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.1

为什么 Prometheus 是主流

定位：单机监控用sar/glances，集群监控上 Prometheus。两者不冲突，前者做现场排查，后者做长期趋势和告警。

六、其他值得知道的工具

⚠️ 常见错误

1. 只装实时工具，不做历史留存。事故在凌晨，top看不到现场。sar/Prometheus 必须有。
2. 采集间隔太粗或太密。太粗丢尖峰，太密浪费资源、撑爆存储。1 分钟是常见折中。
3. 只监控、不告警。没有告警的监控等于没监控，问题还是要等人工发现。
4. 指标太多没重点。全量采集会让 Prometheus 存储和查询变慢，只采关键指标 + 按需扩展。
5. 忽视 exporter 自身开销。高频采集大量指标会消耗被监控机资源，粒度要权衡。
6. 把 glances 当集群方案。它适合单机/小规模，跨机房、高可用要用 Prometheus。

七、原理探究：Push 与 Pull，以及时序数据模型

Push vs Pull

监控系统有两大流派：

Prometheus 选 Pull 的理由：

• 目标管理简单：改配置就能加减监控目标，不用在被监控端改。
• 天然探测存活：拉不到数据（up=0）本身就是「目标挂了」的告警。
• 避免推送风暴：不会被瞬时大量上报压垮。
• 短生命周期任务：配合 Pushgateway 解决批处理任务无法被 pull 的问题。

Pull 的代价是需要目标 IP 可达、要维护服务发现，但在云原生环境下这些由 K8s API 自动完成，反而更省心。

指标类型（Prometheus 四大类）

理解Counter 用rate()求速率、Gauge 直接看值，是写 PromQL 的基础。比如node_cpu_seconds_total是 counter，所以要rate(...[5m])才能算出「每秒的 CPU 时间」。

采集方式对比

• sar/sysstat：定时读/proc，写文本文件。轻量，适合单机长期留存。
• node_exporter：同样读/proc//sys，但转成 Prometheus 格式暴露 HTTP 接口。
• eBPF（bpftrace）：在内核里挂探针，采集传统/proc拿不到的指标（延迟分布、调用栈），精度和开销都更优，是下一代监控的方向（第 108 篇细讲）。

监控的本质是「把内核暴露的运行时数据，采集、存储、聚合、告警」。工具会变，这条链路不变。理解/proc是数据源头（第 61 篇讲过），再看任何监控工具，都能明白它的数据从哪来、到哪去。

八、工具选型速查

一句话收尾：实时排查用top/dstat，历史回看靠sar，大规模监控上 Prometheus。工具再多，核心都是那几类指标，先把指标体系建对，比堆工具更重要。