centos运维定时任务日志审计与异常任务实时告警

CentOS运维中定时任务（crontab）出了问题不告警、日志没人看、异常任务跑了几天都没发现，这是绝大多数运维团队的真实痛点。要解决这个问题，核心思路就三步：第一，把所有crontab任务的执行日志统一收集到一个可审计的文件里；第二，写一个实时监控脚本，对任务执行状态、执行时长、返回码进行判断；第三，一旦发现异常，通过邮件、企业微信或钉钉机器人实时推送告警。下面我把每一步的具体操作、脚本代码和注意事项全部讲透。

一、为什么CentOS定时任务需要日志审计和实时告警

CentOS系统默认的crond服务只会把执行结果通过邮件发给本地用户，但大多数服务器根本没配置本地邮件转发，导致任务执行失败了你完全不知道。更严重的是，有些任务虽然"成功"执行了，但实际上跑了异常长的时间、占用了大量资源，或者输出了错误内容却没人检查。没有日志审计，你连出了什么问题都无法追溯；没有实时告警，小问题拖成大事故只是时间问题。

特别是在生产环境中，一台服务器上可能有几十甚至上百条crontab任务，涉及数据库备份、日志清理、数据同步、监控采集等关键操作。任何一条任务异常都可能导致数据丢失、服务中断。所以，建立一套完整的定时任务日志审计和异常告警机制，是CentOS运维的基本功。

二、统一收集crontab执行日志的具体方法

CentOS的crond本身不提供集中日志功能，我们需要通过包装脚本的方式，把每条任务的执行情况记录下来。最实用的方案是创建一个通用的日志记录wrapper脚本，然后让所有crontab任务都通过这个脚本来执行。

首先，创建日志目录和wrapper脚本：

mkdir -p /var/log/cron_audit
chmod 755 /var/log/cron_audit

cat > /usr/local/bin/cron_wrapper.sh << 'EOF'
#!/bin/bash
# cron_wrapper.sh - 定时任务执行日志包装器
# 用法: cron_wrapper.sh "任务名称" "要执行的命令"

TASK_NAME=$1
shift
COMMAND="$@"

LOG_FILE="/var/log/cron_audit/${TASK_NAME}.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

echo "========================================" >> "$LOG_FILE"
echo "[$TIMESTAMP] 任务开始: $TASK_NAME" >> "$LOG_FILE"
echo "执行命令: $COMMAND" >> "$LOG_FILE"

# 执行命令并捕获返回码和输出
OUTPUT=$($COMMAND 2>&1)
RETURN_CODE=$?
DURATION=0

END_TIME=$(date +%s)

if [ $RETURN_CODE -eq 0 ]; then
    echo "[$TIMESTAMP] 任务成功完成, 返回码: $RETURN_CODE" >> "$LOG_FILE"
else
    echo "[$TIMESTAMP] 任务执行失败, 返回码: $RETURN_CODE" >> "$LOG_FILE"
fi

echo "输出内容:" >> "$LOG_FILE"
echo "$OUTPUT" >> "$LOG_FILE"
echo "========================================" >> "$LOG_FILE"

exit $RETURN_CODE
EOF

chmod +x /usr/local/bin/cron_wrapper.sh

然后，修改你的crontab条目，把原来的命令替换成wrapper调用。例如原来的任务：

0 2 * * * /usr/local/bin/backup_db.sh

改成：

0 2 * * * /usr/local/bin/cron_wrapper.sh "db_backup" /usr/local/bin/backup_db.sh

这样每条任务的执行时间、命令、返回码、输出内容都会被完整记录到 /var/log/cron_audit/ 目录下对应的日志文件中。日志文件建议按月轮转，避免单个文件过大：

cat > /etc/logrotate.d/cron_audit << 'EOF'
/var/log/cron_audit/*.log {
    monthly
    rotate 12
    compress
    delaycompress
    missingok
    notifempty
    create 0644 root root
}
EOF

三、实时异常告警脚本的完整实现

有了日志之后，下一步就是实时监控。我们需要一个守护脚本，定期扫描日志文件，判断是否有异常情况，一旦发现立即告警。异常的判断标准通常包括：任务执行失败（返回码非0）、任务执行时间超过阈值、任务连续多次失败、任务长时间未执行。

下面是一个功能完整的实时告警脚本：

cat > /usr/local/bin/cron_alert_monitor.sh << 'EOF'
#!/bin/bash
# cron_alert_monitor.sh - 定时任务异常实时告警
# 依赖: curl (用于发送企业微信/钉钉告警)

LOG_DIR="/var/log/cron_audit"
ALERT_LOG="/var/log/cron_audit/alert.log"
CHECK_INTERVAL=60  # 检查间隔，单位秒

# 告警阈值配置
MAX_DURATION=3600      # 单次任务最大允许执行时间（秒）
MAX_FAIL_COUNT=3       # 连续失败次数阈值
WEBHOOK_URL=""         # 企业微信/钉钉机器人Webhook地址

# 记录告警，避免重复发送（同一任务30分钟内不重复告警）
declare -A ALERT_CACHE

send_alert() {
    local task_name=$1
    local alert_type=$2
    local detail=$3
    local now=$(date '+%Y-%m-%d %H:%M:%S')
    local cache_key="${task_name}_${alert_type}"

    # 防重复告警
    if [ -n "${ALERT_CACHE[$cache_key]}" ]; then
        last_alert=${ALERT_CACHE[$cache_key]}
        diff=$(( $(date +%s) - last_alert ))
        if [ $diff -lt 1800 ]; then
            return
        fi
    fi
    ALERT_CACHE[$cache_key]=$(date +%s)

    local msg="【CentOS定时任务告警】\n任务: ${task_name}\n类型: ${alert_type}\n详情: ${detail}\n时间: ${now}"

    # 记录到告警日志
    echo "[$now] $alert_type - $task_name - $detail" >> "$ALERT_LOG"

    # 发送Webhook告警
    if [ -n "$WEBHOOK_URL" ]; then
        curl -s -X POST "$WEBHOOK_URL" \
            -H 'Content-Type: application/json' \
            -d "{\"msgtype\": \"text\", \"text\": {\"content\": \"$msg\"}}" > /dev/null 2>&1
    fi

    # 同时发送邮件告警（需要系统配置好mail或sendmail）
    echo "$msg" | mail -s "CentOS定时任务异常告警: $task_name" root@localhost 2>/dev/null
}

check_task_log() {
    local log_file=$1
    local task_name=$(basename "$log_file" .log)

    # 检查最新一次执行状态
    local last_status=$(tail -5 "$log_file" | grep "任务成功完成" || grep "任务执行失败")

    if [ -z "$last_status" ]; then
        # 日志文件为空或没有执行记录，检查任务是否超时未执行
        local last_modify=$(stat -c %Y "$log_file")
        local now=$(date +%s)
        local diff=$(( now - last_modify ))

        # 根据任务名称推断预期执行频率（简单处理：超过24小时没记录就告警）
        if [ $diff -gt 86400 ]; then
            send_alert "$task_name" "任务未执行" "超过24小时未检测到执行记录"
        fi
        return
    fi

    # 检查是否执行失败
    if echo "$last_status" | grep -q "任务执行失败"; then
        # 统计最近失败次数
        local fail_count=$(tail -20 "$log_file" | grep -c "任务执行失败")
        if [ $fail_count -ge $MAX_FAIL_COUNT ]; then
            send_alert "$task_name" "连续执行失败" "最近$fail_count次执行均失败"
        fi
    fi

    # 检查执行时长（从日志中提取时间戳计算）
    local start_time=$(tail -10 "$log_file" | grep "任务开始" | tail -1 | grep -oP '\[\K[^\]]+')
    local end_time=$(tail -5 "$log_file" | grep -E "成功完成|执行失败" | tail -1 | grep -oP '\[\K[^\]]+')

    if [ -n "$start_time" ] && [ -n "$end_time" ]; then
        local start_epoch=$(date -d "$start_time" +%s 2>/dev/null)
        local end_epoch=$(date -d "$end_time" +%s 2>/dev/null)
        if [ -n "$start_epoch" ] && [ -n "$end_epoch" ]; then
            local duration=$(( end_epoch - start_epoch ))
            if [ $duration -gt $MAX_DURATION ]; then
                send_alert "$task_name" "执行超时" "执行时长${duration}秒，超过阈值${MAX_DURATION}秒"
            fi
        fi
    fi
}

# 主循环
while true; do
    for log_file in "$LOG_DIR"/*.log; do
        if [ -f "$log_file" ]; then
            check_task_log "$log_file"
        fi
    done
    sleep $CHECK_INTERVAL
done
EOF

chmod +x /usr/local/bin/cron_alert_monitor.sh

四、部署告警监控服务并设置开机自启

脚本写好之后，需要把它做成systemd服务，确保服务器重启后自动运行：

cat > /etc/systemd/system/cron-alert.service << 'EOF'
[Unit]
Description=CentOS Cron Task Alert Monitor
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/cron_alert_monitor.sh
Restart=always
RestartSec=10
User=root

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable cron-alert.service
systemctl start cron-alert.service
systemctl status cron-alert.service

记得把脚本中的 WEBHOOK_URL 替换成你实际的企业微信或钉钉机器人地址。如果没有Webhook，至少要确保系统的mail命令能正常发送邮件到运维人员邮箱。

五、日志审计的进阶技巧和注意事项

在实际运维中，还有几个容易被忽略但非常重要的细节。

第一，crontab本身也要审计。很多时候任务被人改了你都不知道。建议把 /var/spool/cron/ 下每个用户的crontab文件纳入版本管理，或者定期用脚本对比：

# 每天凌晨对比crontab变化
0 3 * * * diff /var/spool/cron/root /tmp/cron_root_backup.txt > /var/log/cron_audit/crontab_diff_$(date +\%Y\%m\%d).log 2>&1 || cp /var/spool/cron/root /tmp/cron_root_backup.txt

第二，注意日志权限和安全。/var/log/cron_audit/ 目录下的日志包含了大量系统操作信息，建议设置为root:root 0640权限，防止普通用户读取敏感信息。

第三，对于高频任务（比如每分钟执行一次的），日志量会非常大。建议对这类任务单独设置更短的日志保留周期，或者只记录失败和超时的情况，成功执行的可以只记录一条摘要。

第四，告警脚本本身也需要监控。可以用另一个简单的监控来确认告警服务是否在运行：

# 每5分钟检查告警服务是否存活
*/5 * * * * systemctl is-active cron-alert.service > /dev/null 2>&1 || systemctl restart cron-alert.service

六、总结与最佳实践

CentOS定时任务的日志审计和实时告警，本质上就是把"被动发现问题"变成"主动感知问题"。核心组件就三个：wrapper脚本负责记录、告警监控脚本负责判断、通知渠道负责触达。部署成本很低，一个下午就能搭建完毕，但能避免的损失可能是几十万的数据事故。

建议运维团队把这套机制纳入服务器初始化流程，新机器上线时自动部署。同时定期回顾告警日志，分析哪些任务经常超时或失败，从根本上优化任务本身的稳定性。好的运维不是救火，而是让火烧不起来。