Linux服务器监控工具怎么选？sar、dstat、glances和Prometheus对比
作者：程序员Benothing
前面几篇讲的是「单点工具」——查 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.783. 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。工具再多，核心都是那几类指标，先把指标体系建对，比堆工具更重要。
九、总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。