Linux系统监控工具全家桶：sar、dstat、glances、Prometheus

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

一、监控的三个层次

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

层次	目标	代表工具
实时	现在发生了什么	`top`、`dstat`、`glances`
历史	过去某时刻发生了什么	`sar`
告警/集群	出问题主动通知、跨机器汇总	`Prometheus` + `Grafana`

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      # 查看历史某天

常用参数（按子系统）

参数	查看内容
`-u`	CPU 使用率
`-r`	内存
`-b`	IO 与传输速率
`-d`	块设备
`-n DEV`	网络接口
`-n EDEV`	网络错误
`-q`	负载与运行队列
`-w`	上下文切换

示例与预期输出

实时看 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 [选项] [间隔] [次数]

常用参数

参数	说明
`-c`	CPU
`-d`	磁盘
`-n`	网络
`-m`	内存
`-r`	IO 请求
`--top-cpu`	显示最耗 CPU 的进程
`--top-io`	显示最耗 IO 的进程
`--top-mem`	显示最耗内存的进程
`-t`	加时间戳

示例与预期输出

复制代码

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 是主流

特性	说明
Pull 模式	监控端主动拉取，目标下线自动感知
多维标签	同一指标按 instance/job/mountpoint 等多维度切片
PromQL	强大的查询语言，告警规则直接基于它写
生态	几乎所有中间件、云原生组件都自带 exporter
云原生	Kubernetes 事实标准，`kube-state-metrics`、`cAdvisor` 开箱即用

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

六、其他值得知道的工具

工具	特点	适用场景
`nmon`	一个命令采集全维度，输出可被 Excel 分析	AIX/Linux 老牌，性能采集
`atop`	记录历史并能回放，可分析进程级历史	事后精确复盘
`netdata`	开箱即用的实时 Web 面板，秒级精度	单机可视化，免配置
`collectd`	老牌指标采集器，插件多	传统监控集成
`bpftrace`	eBPF 动态追踪，深度观测	明细级问题定位（第 108 篇）

⚠️ 常见错误

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

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

Push vs Pull

监控系统有两大流派：

模式	代表	特点
Push（推）	Graphite、部分 agent	被监控端主动上报
Pull（拉）	Prometheus	监控端定期抓取

Prometheus 选 Pull 的理由：

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

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

指标类型（Prometheus 四大类）

类型	含义	例子
Counter	只增不减的累计值	请求总数、错误总数
Gauge	可增可减的瞬时值	内存使用、连接数
Histogram	分桶统计分布	请求延迟 P50/P99
Summary	分位数统计	延迟分位数

理解 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` / `htop` / `glances`
一屏看全维度	`dstat`
事后回看历史	`sar` / `atop`
单机 Web 可视化	`netdata`
集群监控 + 告警	Prometheus + Grafana + Alertmanager
深度性能分析	`perf` / `bpftrace`

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