一、为什么运维必须建监控体系

服务器出了问题不可怕，可怕的是用户比你更早知道。监控的意义不是"出事后看日志"，而是"出事前收到告警"。一套完整的监控体系应该覆盖：CPU、内存、磁盘、网络、进程、日志、业务接口，并且能保留历史数据用于容量规划。

二、第一梯队：命令行三板斧（应急用）

# 1. top：实时看CPU/内存/负载top -c          # 按CPU排序，显示完整命令行top -H -p PID   # 看某个进程的所有线程# 2. vmstat：系统整体状态vmstat 1 5      # 每秒采样5次，看r(运行队列)、us/sy、si/so# 3. iostat：磁盘IOiostat -x 1 3   # -x 扩展模式，看await、util# 4. free：内存free -h

三板斧适合故障当下快速判断"是不是资源问题"，但它们看不到历史趋势，也发不出告警，只能算"眼睛"，不是"体系"。

三、第二梯队：sysstat 全家桶（历史回溯用）

# 安装yum install sysstat -y   # CentOS/RHELapt install sysstat -y   # Debian/Ubuntu# 关键命令sar -u 1 3       # CPU使用率sar -r 1 3       # 内存使用sar -b 1 3       # IOsar -n DEV 1 3   # 网卡流量sar -q           # 负载与运行队列# 查看历史数据（默认保留在 /var/log/sa/）sar -u -f /var/log/sa/sa$(date +%d)

sysstat 通过 cron 定时采集（/etc/cron.d/sysstat），默认保留一个月。出问题时先看历史曲线，能回答"从什么时候开始异常的"这个关键问题。建议把 HISTORY 保留天数改大：sed -i 's/HISTORY=7/HISTORY=30/' /etc/sysstat/sysstat。

四、第三梯队：Prometheus + Grafana（生产级体系）

单机命令工具管不了集群。生产环境推荐 Prometheus 采集 + node_exporter 出指标 + Grafana 出图 + Alertmanager 出告警，这套组合是当前开源监控的事实标准。

# 1. 部署 node_exporter（每台机器）wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gztar xzf node_exporter-*.tar.gz -C /optcat > /etc/systemd/system/node_exporter.service <<'EOF'[Unit]Description=Node ExporterAfter=network.target[Service]ExecStart=/opt/node_exporter-1.8.2.linux-amd64/node_exporter --web.listen-address=:9100Restart=always[Install]WantedBy=multi-user.targetEOFsystemctl daemon-reload && systemctl enable --now node_exporter# 2. Prometheus 配置抓取cat >> /etc/prometheus/prometheus.yml <<'EOF'  - job_name: 'linux'    static_configs:      - targets: ['192.168.1.11:9100', '192.168.1.12:9100']EOF

监控核心指标清单（node_exporter 直接可用）：

  • CPU：100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100
  • 内存：(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100
  • 磁盘：node_filesystem_avail_bytes / node_filesystem_size_bytes
  • 负载：node_load1，结合 CPU 核数判断
  • 网络：rate(node_network_receive_bytes_total[5m]) * 8（转成bps）

五、告警规则：监控的灵魂

光有图不够，必须能主动告警。告警阈值要分级，避免告警疲劳：

groups:  - name: linux-alerts    rules:      - alert: 服务器宕机        expr: up == 0        for: 1m        labels: { severity: critical }      - alert: CPU使用率过高        expr: 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90        for: 10m        labels: { severity: warning }      - alert: 磁盘使用率超过85%        expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.15        for: 5m        labels: { severity: warning }      - alert: 磁盘即将写满（95%）        expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.05        for: 2m        labels: { severity: critical }

几个告警设计心得：

  • 告警必须带 for 持续时间，瞬时抖动不打扰人
  • critical 走电话/短信，warning 走IM/邮件，分级触达
  • 磁盘告警要提前：85% warning、95% critical，别等写满才报警
  • 每周review一次告警规则，把无效告警删掉，把漏掉的补上

六、实战：一次 CPU 飙升的定位

某天告警：业务服务器 CPU 持续 95%+。排查过程：

# 1. top 找到高CPU进程top -c          # 发现是 php-fpm，单个worker CPU 100%# 2. 看是不是某个PHP脚本死循环strace -p PID -c -f   # 统计系统调用，发现大量 epoll_wait + 无实际IO# 3. 查日志定位具体请求tail -f /var/log/nginx/access.log | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head# 4. 发现某个API接口被爬虫疯狂请求，单IP每秒几十次# 解决：nginx 限流 + fail2ban 封IP，问题5分钟解决

没有监控体系时，这种问题只能靠用户投诉才能发现；有了监控和告警，问题在影响用户之前就已经在处理了。

七、总结

监控体系建设的路线图：先命令行三板斧应急 → 再 sysstat 留历史 → 最后 Prometheus+Grafana 建体系。不要一上来就追求大而全，先保证"能看、能查、能告警"三件事，再逐步丰富指标和自动化。记住：监控不是给领导看的仪表盘，是给运维自己的"提前预警系统"。