前面几篇讲的是「单点工具」——查 CPU 用mpstat查磁盘用iostat。但真实运维里你需要的是一套能长期采集、随时回看、自动告警的监控体系。单机排查靠top线上监控靠全家桶。这一篇把sar、dstat、glances三个单机工具和Prometheus这套现代监控系统串起来帮你从「事后救火」走向「事前预警」。一、监控的三个层次先建立一张地图知道每个工具在哪一层层次目标代表工具实时现在发生了什么top、dstat、glances历史过去某时刻发生了什么sar告警/集群出问题主动通知、跨机器汇总PrometheusGrafanatop的问题在于它不留痕——你不在的时候发生了什么它不记录。而线上事故往往发生在凌晨没人看屏的时候所以历史采集和告警才是生产监控的核心。二、sar历史数据的瑞士军刀sarSystem Activity Reporter是sysstat套件的核心它的价值在于后台默默采样你要的时候能查任意历史时刻的数据。工作原理sysstat服务或 cron默认每 10 分钟采集一次系统数据写到/var/log/sysstat/Debian/Ubuntu或/var/log/sa/CentOS/Rocky文件名形如sa1515 号。默认保留约一个月。先确保采集开启# Ubuntu/Debian编辑 /etc/default/sysstat把 ENABLED 改成 true sudo sed -i s/ENABLEDfalse/ENABLEDtrue/ /etc/default/sysstat sudo systemctl restart sysstat # CentOS/Rocky确认 cron 里有 sysstat 任务 systemctl status sysstat语法格式sar [选项] [间隔] [次数] sar [选项] -f /var/log/sa/saDD # 查看历史某天常用参数按子系统参数查看内容-uCPU 使用率-r内存-bIO 与传输速率-d块设备-n DEV网络接口-n EDEV网络错误-q负载与运行队列-w上下文切换示例与预期输出实时看 CPU每秒共 3 次sar -u 1 310: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 -q10: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把vmstatiostatnetstatmpstat的能力合到一个命令里输出彩色、带单位是「实时看页面」的利器。安装sudo apt install dstat -y # Ubuntu sudo dnf install dstat -y # Rocky/CentOS语法格式dstat [选项] [间隔] [次数]常用参数参数说明-cCPU-d磁盘-n网络-m内存-rIO 请求--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{cpu0,modeidle} 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{modeidle}[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老牌指标采集器插件多传统监控集成bpftraceeBPF 动态追踪深度观测明细级问题定位第 108 篇⚠️ 常见错误只装实时工具不做历史留存。事故在凌晨top看不到现场。sar/Prometheus 必须有。采集间隔太粗或太密。太粗丢尖峰太密浪费资源、撑爆存储。1 分钟是常见折中。只监控、不告警。没有告警的监控等于没监控问题还是要等人工发现。指标太多没重点。全量采集会让 Prometheus 存储和查询变慢只采关键指标 按需扩展。忽视 exporter 自身开销。高频采集大量指标会消耗被监控机资源粒度要权衡。把 glances 当集群方案。它适合单机/小规模跨机房、高可用要用 Prometheus。七、原理探究Push 与 Pull以及时序数据模型Push vs Pull监控系统有两大流派模式代表特点Push推Graphite、部分 agent被监控端主动上报Pull拉Prometheus监控端定期抓取Prometheus 选 Pull 的理由目标管理简单改配置就能加减监控目标不用在被监控端改。天然探测存活拉不到数据up0本身就是「目标挂了」的告警。避免推送风暴不会被瞬时大量上报压垮。短生命周期任务配合 Pushgateway 解决批处理任务无法被 pull 的问题。Pull 的代价是需要目标 IP 可达、要维护服务发现但在云原生环境下这些由 K8s API 自动完成反而更省心。指标类型Prometheus 四大类类型含义例子Counter只增不减的累计值请求总数、错误总数Gauge可增可减的瞬时值内存使用、连接数Histogram分桶统计分布请求延迟 P50/P99Summary分位数统计延迟分位数理解Counter 用rate()求速率、Gauge 直接看值是写 PromQL 的基础。比如node_cpu_seconds_total是 counter所以要rate(...[5m])才能算出「每秒的 CPU 时间」。采集方式对比sar/sysstat定时读/proc写文本文件。轻量适合单机长期留存。node_exporter同样读/proc//sys但转成 Prometheus 格式暴露 HTTP 接口。eBPFbpftrace在内核里挂探针采集传统/proc拿不到的指标延迟分布、调用栈精度和开销都更优是下一代监控的方向第 108 篇细讲。监控的本质是「把内核暴露的运行时数据采集、存储、聚合、告警」。工具会变这条链路不变。理解/proc是数据源头第 61 篇讲过再看任何监控工具都能明白它的数据从哪来、到哪去。八、工具选型速查需求推荐临时登机体检top/htop/glances一屏看全维度dstat事后回看历史sar/atop单机 Web 可视化netdata集群监控 告警Prometheus Grafana Alertmanager深度性能分析perf/bpftrace一句话收尾实时排查用top/dstat历史回看靠sar大规模监控上 Prometheus。工具再多核心都是那几类指标先把指标体系建对比堆工具更重要。