Linux 系统监控入门：从 top 到 Prometheus 全链路实战

一台生产环境的 Linux 服务器,你真的知道它在”想”什么吗?CPU 飙高、内存吃紧、磁盘 IO 瓶颈——这些问题如果不能第一时间发现,故障就会像滚雪球一样越滚越大。本文带你从最基础的 top 命令开始,一路走到企业级的 Prometheus + Grafana 监控体系,搭建属于自己的”服务器驾驶舱”。

为什么需要监控

运维工程师有三怕:怕宕机、怕背锅、怕半夜被叫醒。监控系统就是那个能在你睡觉时替你”盯盘”的眼睛。

一个完整的监控体系至少要覆盖四个维度:

CPU:使用率、负载、上下文切换次数
内存:已用/可用、Swap 使用率、缓存命中率
磁盘:容量、IOPS、读写延迟
网络:带宽、连接数、丢包率

第一阶段:命令行工具快速排查

top / htop:实时进程视图

1 2	# top 是 Linux 自带的进程监控工具 top -d 1 -p 1234 # 每 1 秒刷新,只看 PID 1234

htop 是 top 的增强版,支持鼠标操作和颜色高亮,推荐安装:

# CentOS / RHEL
yum install -y htop
# Ubuntu / Debian
apt install -y htop

重点关注三行:

load average:三个数字分别是 1 分钟、5 分钟、15 分钟的平均负载。经验值:不超过 CPU 核心数
%Cpu(s):us(user) + sy(system) 之和 > 80% 说明 CPU 紧张
KiB Mem:available 接近 0 就该警惕了

vmstat:系统整体性能

1	vmstat 1 5 # 每秒采样一次,共 5 次

输出字段解读:

r:等待运行的进程数(> CPU 核心数说明排队了)
b:不可中断睡眠的进程数(通常是 IO 阻塞)
si/so:Swap 换入换出(长期 > 0 说明内存不够)
cs:上下文切换次数(> 10 万/秒说明进程太多)

iostat:磁盘 IO 性能

1	iostat -xz 1 # 扩展统计,只看使用中的设备

关键指标:

%util:设备繁忙程度,接近 100% 说明磁盘到瓶颈
await:平均 IO 等待时间(毫秒),> 10ms 就偏高了
svctm:服务时间(已废弃,看 await 即可)

网络相关

# 实时流量
iftop -i eth0
# 连接统计
ss -s
# 抓包分析
tcpdump -i eth0 port 80 -c 100

第二阶段:Zabbix 企业级监控

命令行工具适合应急排查,但要做 7×24 小时监控还是得用专业系统。

Zabbix 架构

┌──────────┐      ┌──────────┐      ┌──────────┐
│  Agent   │──────│  Server  │──────│ Frontend │
└──────────┘      └──────────┘      └──────────┘
     │                  │
     ↓                  ↓
 被监控主机         MySQL/PostgreSQL

快速部署(Docker 方式)

docker run --name zabbix-mysql -t \
  -e MYSQL_DATABASE=zabbix \
  -e MYSQL_USER=zabbix \
  -e MYSQL_PASSWORD=zabbix_pwd \
  -d mysql:8.0

docker run --name zabbix-server -t \
  -e DB_SERVER_HOST="mysql-host" \
  -e MYSQL_USER=zabbix \
  -e MYSQL_PASSWORD=zabbix_pwd \
  --link zabbix-mysql:mysql \
  -d zabbix/zabbix-server-mysql

自定义监控项

以监控 Nginx 活跃连接数为例:

# 1. Agent 端编写采集脚本
cat /etc/zabbix/zabbix_agentd.d/nginx_active.sh
#!/bin/bash
curl -s http://127.0.0.1/nginx_status | grep "Active connections" | awk '{print $3}'

# 2. 配置 UserParameter
echo 'UserParameter=nginx.active,/etc/zabbix/zabbix_agentd.d/nginx_active.sh' >> \
  /etc/zabbix/zabbix_agentd.conf

# 3. Web 端创建监控项,键值填 nginx.active

第三阶段:Prometheus + Grafana 云原生方案

如果你用的是 Kubernetes 或者微服务架构,Prometheus 几乎是事实标准。

核心组件

Prometheus Server:抓取和存储时序数据
Exporter:采集各种指标的”翻译官”(node_exporter / mysqld_exporter 等)
Alertmanager:告警分发(邮件 / 钉钉 / 飞书 / Slack)
Grafana:可视化面板

安装 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
cd node_exporter-1.7.0.linux-amd64
./node_exporter --web.listen-address=:9100 &

Prometheus 配置

# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['192.168.1.100:9100', '192.168.1.101:9100']
        labels:
          env: production

常用 PromQL 查询

# CPU 使用率
100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# 内存可用率
(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

# 磁盘使用率
(node_filesystem_size_bytes - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100

# 网络入流量(MB/s)
irate(node_network_receive_bytes_total[5m]) / 1024 / 1024

配置告警规则

# alert.rules.yml
groups:
- name: host
  rules:
  - alert: HighCPUUsage
    expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "实例 {{ $labels.instance }} CPU 使用率过高"
      description: "当前值: {{ $value }}%"

监控告警的最佳实践

1. 告警分级

P0(紧急):核心服务不可用,电话通知
P1(高):性能严重下降,5 分钟内响应
P2(中):指标预警,工单跟进
P3(低):趋势提醒,周报汇总

2. 避免告警风暴

告警合并:同一类问题不要发几十条
抑制规则:网络不通时,依赖它的服务告警自动屏蔽
静默期:维护窗口期关闭非关键告警

3. 监控黄金指标(Four Golden Signals)

Google SRE 提出的四个核心指标:

Latency(延迟)
Traffic(流量)
Errors(错误率)
Saturation(饱和度)

任何一个出问题,用户体验都会下降。

总结

阶段	工具	适用场景
命令行	top / vmstat / iostat	应急排查、单台机器
企业级	Zabbix / Nagios	传统架构、物理机/虚拟机
云原生	Prometheus + Grafana	K8s、微服务、容器化

没有最好的方案,只有最合适的方案。小团队用命令行 + 脚本就够了,中型公司上 Zabbix,云原生架构直接用 Prometheus 生态。

监控的本质不是收集数据,而是让问题在变成事故之前被发现。把告警阈值调合理,把通知链路跑通,你就能安心睡个好觉了。