<h2>一、为什么运维必须建监控体系</h2><p>服务器出了问题不可怕，可怕的是<strong>用户比你更早知道</strong>。监控的意义不是"出事后看日志"，而是"出事前收到告警"。一套完整的监控体系应该覆盖：CPU、内存、磁盘、网络、进程、日志、业务接口，并且能保留历史数据用于容量规划。</p><h2>二、第一梯队：命令行三板斧（应急用）</h2><pre># 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</pre><p>三板斧适合故障当下快速判断"是不是资源问题"，但它们看不到历史趋势，也发不出告警，只能算"眼睛"，不是"体系"。</p><h2>三、第二梯队：sysstat 全家桶（历史回溯用）</h2><pre># 安装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)</pre><p>sysstat 通过 cron 定时采集（/etc/cron.d/sysstat），默认保留一个月。出问题时先看历史曲线，能回答"从什么时候开始异常的"这个关键问题。建议把 HISTORY 保留天数改大：<code>sed -i 's/HISTORY=7/HISTORY=30/' /etc/sysstat/sysstat</code>。</p><h2>四、第三梯队：Prometheus + Grafana（生产级体系）</h2><p>单机命令工具管不了集群。生产环境推荐 Prometheus 采集 + node_exporter 出指标 + Grafana 出图 + Alertmanager 出告警，这套组合是当前开源监控的事实标准。</p><pre># 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</pre><p>监控核心指标清单（node_exporter 直接可用）：</p><ul><li><strong>CPU</strong>：<code>100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100</code></li><li><strong>内存</strong>：<code>(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100</code></li><li><strong>磁盘</strong>：<code>node_filesystem_avail_bytes / node_filesystem_size_bytes</code></li><li><strong>负载</strong>：<code>node_load1</code>，结合 CPU 核数判断</li><li><strong>网络</strong>：<code>rate(node_network_receive_bytes_total[5m]) * 8</code>（转成bps）</li></ul><h2>五、告警规则：监控的灵魂</h2><p>光有图不够，必须能主动告警。告警阈值要分级，避免告警疲劳：</p><pre>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 }</pre><p>几个告警设计心得：</p><ul><li>告警必须带 <code>for</code> 持续时间，瞬时抖动不打扰人</li><li>critical 走电话/短信，warning 走IM/邮件，分级触达</li><li>磁盘告警要提前：85% warning、95% critical，别等写满才报警</li><li>每周review一次告警规则，把无效告警删掉，把漏掉的补上</li></ul><h2>六、实战：一次 CPU 飙升的定位</h2><p>某天告警：业务服务器 CPU 持续 95%+。排查过程：</p><pre># 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分钟解决</pre><p>没有监控体系时，这种问题只能靠用户投诉才能发现；有了监控和告警，问题在影响用户之前就已经在处理了。</p><h2>七、总结</h2><p>监控体系建设的路线图：<b>先命令行三板斧应急 → 再 sysstat 留历史 → 最后 Prometheus+Grafana 建体系</b>。不要一上来就追求大而全，先保证"能看、能查、能告警"三件事，再逐步丰富指标和自动化。记住：监控不是给领导看的仪表盘，是给运维自己的"提前预警系统"。</p>
文中这类批量操作，我们平时是用自研的[七亿批量远程管理工具](https://blog.7ehl.com/index.php/archives/3/)做的，免费，支持 RDP / SSH / SFTP / FTP。
评论