centos运维性能监控与故障自愈脚本编写

CentOS运维中最头疼的就是半夜告警和性能瓶颈定位，性能监控和故障自愈脚本就是你的“自动驾驶”系统。核心思路很简单：用Shell或Python脚本自动采集系统指标（CPU、内存、磁盘、网络），设定阈值触发告警，并自动执行预设的恢复命令。比如，当内存使用率超过90%时，自动清理缓存；当服务进程挂掉，自动重启。下面我将从监控项选择、脚本编写、到自愈逻辑设计，一步步拆解。

一、性能监控脚本的核心：要监控什么？怎么采集？

有效的监控必须抓住关键指标。对于CentOS服务器，你需要紧盯CPU负载、内存使用、磁盘空间与IO、网络连接数以及关键服务状态。使用命令行工具采集这些数据是最直接的方法。例如，使用vmstat、mpstat看CPU；free -m看内存；df -h看磁盘空间；ss -s或netstat看网络。一个基础的监控脚本应该定期（如每分钟）记录这些数据，并与阈值进行比较。

#!/bin/bash
# 基础系统监控采集脚本
LOG_FILE="/var/log/system_monitor.log"
THRESHOLD_CPU=80
THRESHOLD_MEM=90
THRESHOLD_DISK=85

# 采集数据
CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1)
MEM_USAGE=$(free | grep Mem | awk '{print $3/$2 * 100.0}')
DISK_USAGE=$(df / | grep / | awk '{print $5}' | sed 's/%//g')

# 记录日志
echo "$(date): CPU=$CPU_USAGE%, MEM=$MEM_USAGE%, DISK=$DISK_USAGE%" >> $LOG_FILE

# 阈值检查与告警（示例：CPU）
if [ $(echo "$CPU_USAGE > $THRESHOLD_CPU" | bc) -eq 1 ]; then
    echo "$(date): CPU使用率超过${THRESHOLD_CPU}%，当前为${CPU_USAGE}%" >> $LOG_FILE
    # 此处可集成邮件或即时通讯工具告警
fi

二、故障自愈脚本的设计逻辑：从发现到恢复的自动化

自愈脚本的核心是“if-then”逻辑：如果某个条件被触发，就执行相应的恢复操作。这需要你对常见故障有预判。常见的自愈场景包括：

(1)服务进程崩溃：检测进程是否存在，不存在则重启；

(2)磁盘空间不足：自动清理日志文件或临时文件；

(3)内存泄漏：触发缓存清理；

(4)网络端口不可用：重启网络服务或特定应用。设计时要特别注意恢复操作的安全性，避免循环重启或数据丢失。

#!/bin/bash
# Nginx服务进程自愈脚本示例
SERVICE="nginx"
LOG="/var/log/service_healer.log"

# 检查进程是否存在
if ! systemctl is-active --quiet $SERVICE; then
    echo "$(date): $SERVICE 服务异常，尝试重启..." >> $LOG
    systemctl restart $SERVICE
    sleep 5
    # 二次检查是否重启成功
    if systemctl is-active --quiet $SERVICE; then
        echo "$(date): $SERVICE 重启成功" >> $LOG
    else
        echo "$(date): $SERVICE 重启失败，需要人工干预！" >> $LOG
        # 此处可升级告警
    fi
fi

三、高级监控与集成：让脚本更智能、更全面

基础脚本可以应付简单场景，但生产环境需要更精细的监控。建议从三方面升级：

(1)使用更专业的工具辅助：如用dstat综合监控，用iotop看磁盘IO，用nethogs看进程网络带宽。

(2)监控应用层指标：例如，用curl检测Web服务HTTP状态码和响应时间，用mysqladmin检测数据库连接。

(3)集成外部系统：将告警发送至运维平台、短信或邮件，并将历史数据记录到时序数据库（如InfluxDB）以便可视化分析。

#!/bin/bash
# 高级监控示例：检测Web服务并记录响应时间
URL="http://your-domain.com/health"
LOG="/var/log/web_monitor.log"
RESPONSE_TIME=$(curl -o /dev/null -s -w '%{time_total}\n' $URL)
HTTP_CODE=$(curl -o /dev/null -s -w '%{http_code}\n' $URL)

if [ "$HTTP_CODE" -ne 200 ] || [ $(echo "$RESPONSE_TIME > 2" | bc) -eq 1 ]; then
    echo "$(date): 服务异常！HTTP状态码=$HTTP_CODE, 响应时间=${RESPONSE_TIME}s" >> $LOG
    # 可触发自愈操作，如重启Web服务
fi

四、生产环境部署与管理：可靠性是关键

编写好的脚本需要可靠地运行。务必做好以下几点：

(1)设置定时任务：通过crontab让脚本按固定频率（如每分钟）执行，注意避免重复执行冲突。

(2)完善的日志记录：所有操作和错误都应记录到带时间戳的日志文件，便于回溯。

(3)设置“熔断”机制：避免在短时间内对同一故障重复执行自愈操作，可引入冷却时间（cooldown）或最大重试次数。

(4)权限与安全：脚本应以最小必要权限（如通过sudo授权特定命令）运行，避免使用root权限执行所有操作。

# 在crontab中设置每分钟执行一次监控脚本
* * * * * /root/scripts/system_monitor.sh >/dev/null 2>&1

# 自愈脚本的"熔断"机制示例（通过标记文件实现）
COOLDOWN_FILE="/tmp/reboot_cooldown"
COOLDOWN_TIME=300 # 冷却5分钟

if [ -f "$COOLDOWN_FILE" ]; then
    # 检查冷却文件是否过期
    if [ $(($(date +%s) - $(stat -c %Y "$COOLDOWN_FILE"))) -gt $COOLDOWN_TIME ]; then
        rm -f $COOLDOWN_FILE
    else
        echo "处于冷却期，跳过自愈操作" >> $LOG
        exit 0
    fi
fi

# 执行自愈操作...
touch $COOLDOWN_FILE # 创建冷却标记

五、超越脚本：构建自动化运维体系的思考

脚本是自动化的起点，但不是终点。当服务器规模扩大后，分散的脚本会难以管理。你应该考虑：

(1)配置管理工具：如Ansible，可以批量部署和执行监控脚本，确保一致性。

(2)集中式监控告警平台：如Prometheus + Grafana + Alertmanager的组合，能提供更强大的数据采集、存储、可视化和告警路由能力。

(3)将自愈逻辑平台化：通过编写运维平台的插件或Webhook，将自愈动作集成到更广泛的工作流中。记住，脚本的目标是减少重复劳动并快速响应，但复杂的决策和关联分析仍需依赖更专业的系统和人的判断。

总结来说，CentOS运维性能监控与故障自愈脚本的编写，是一个从手动到自动、从基础到系统的过程。核心在于准确采集、智能判断和安全执行。从本文提供的脚本示例出发，结合你的实际业务场景进行修改和扩展，你就能构建起一套守护服务器稳定的自动化防线，将自己从繁琐的重复告警处理中解放出来，专注于更有价值的架构与优化工作。

centos运维性能监控与故障自愈脚本编写

服务指南

帮助中心