Crontab 日志指南：定时任务日志在哪、怎么读、如何监控"沉默失败"

Crontab 日志（Cron Log）是 cron 守护进程执行定时任务时产生的系统级记录，包含任务启动时间、执行用户、命令内容与退出状态，是排查"定时任务为何没跑/跑挂"的审计依据。 定时任务在后台静默运行，没有日志可见性，任务失败数周都可能无人察觉——备份没执行、证书没续期，往往都是这样酿成的。

核心要点速览

• 各系统位置不同：Debian/Ubuntu 在 /var/log/syslog，RHEL/CentOS 在 /var/log/cron，macOS 在 /var/log/system.log；
• 系统日志只记录"跑了没有"，脚本自己的输出要手动重定向到日志文件才能看到；
• 任务日志必须配 logrotate，否则自定义日志文件同样会撑爆磁盘；
• 最大的风险是"沉默失败"——任务挂了没人知道；用观测云日志检测对失败关键字/缺失心跳告警，才能把被动排查变主动发现。

crontab 日志存在哪里？

实时跟踪 Debian 系的 cron 活动：tail -f /var/log/syslog | grep CRON。

日志格式怎么读？

一条典型记录：

Apr 20 14:00:01 myserver CRON[1234]: (root) CMD (/usr/local/bin/backup.sh)

结构为：时间戳 + 主机名 + CRON[进程ID]: (执行用户) + 事件。事件类型常见的有 CMD（任务启动）、FINISHED (exit status: N)（完成及退出码）——退出码 0 为成功，非 0 即失败。

系统日志不够：给任务建自己的日志

系统 cron 日志只告诉你"任务启动过、退出码多少"，脚本内部的报错详情看不到。标准做法是在 crontab 条目里重定向输出：

0 2 * * * (date; /path/to/backup.sh) >> /var/log/backup.log 2>&1

>> 追加标准输出，2>&1 把错误输出合并进同一文件，开头的 date 为每次执行打上时间戳。

更进一步的写法是让脚本输出结构化状态标记，便于机器解析：

#!/bin/bash
echo "===== started at $(date '+%F %T') ====="
if tar -czf /backup/data.tar.gz /var/www/data/; then
   echo "[SUCCESS] backup created"
else
   echo "[ERROR] backup failed"
fi
echo "===== finished at $(date '+%F %T') ====="

别忘了给自定义日志配轮转（/etc/logrotate.d/custom-cron）：

/var/log/backup.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

最大的坑："沉默失败"

定时任务最危险的不是报错，而是失败了没有任何人知道。传统解法（脚本里发邮件、再写一个监控 cron 的 cron）本质上都是"用定时任务监控定时任务"，脆弱且容易跟着一起挂。

观测云落地：把任务日志采集上来，用平台能力监控 ：

1. 采集：DataKit 磁盘文件采集指向 /var/log/backup.log 等任务日志文件，Pipeline 提取 [ERROR]/[SUCCESS] 为标准 status 字段 ；
2. 失败告警：新建监控器（日志检测），规则为"任务日志中出现 ERROR 或非零退出码即触发"，告警策略推送钉钉/企业微信/飞书 ；
3. 沉默告警（关键）：对"该有日志却没有日志"做检测——比如备份任务每天 02:00 执行，若到 03:00 仍无 SUCCESS 记录则告警。这类"数据缺失"检测正是集中式日志平台相对于单机脚本监控的核心价值；
4. 追溯：所有任务的历史执行记录在日志查看器中可按任务、按主机统一检索，配合多索引为不同业务线的任务日志设置不同留存周期 。

安全注意事项

• 任务日志可能含内网路径、账户信息，文件权限收紧：chown root:adm + chmod 640；
• 脚本里绝不打印密码、API Key 等机密，需要时输出 [REDACTED] 占位；万一混入，可用观测云敏感数据扫描在写入存储前脱敏 ；
• crontab 本身的变更（crontab -e 的记录）也会进入系统日志，可作为审计线索一并采集。

总结

crontab 日志管理四件事：知道系统日志在哪、给每个任务重定向出专属日志、配好 logrotate、把"失败"和"沉默"都纳入告警。前三件靠单机配置，最后一件必须靠观测云这样的集中式平台——因为监控定时任务的东西，本身绝不能再是一个定时任务。

常见问题（FAQ）

Q：crontab 任务的输出默认去哪了？
如果任务有输出且未重定向，cron 会尝试通过系统邮件发给任务属主（MAILTO），多数未配置邮件服务的机器上这些输出直接丢失——所以务必显式重定向到日志文件。

Q：如何只把错误单独存一个文件？
把 stdout 与 stderr 分开重定向：/path/to/script.sh > /var/log/task-out.log 2> /var/log/task-err.log。排障时先看错误文件即可。

Q：任务没执行，日志里连 CMD 记录都没有，怎么查？
先确认 cron 服务在运行（systemctl status cron），再检查 crontab 语法（crontab -l）、脚本路径是否为绝对路径、以及环境变量差异——cron 的 PATH 与交互式 shell 不同，是相对路径问题的重灾区。

Q：观测云能监控"任务没跑"这种无日志场景吗？
可以。思路是对 SUCCESS 类日志设置"指定时间窗口内数据条数少于预期即触发"的检测规则，日志缺失本身即成为告警信号。

---

系列阅读：Linux 系统日志管理入门 ｜ Logrotate 日志轮转实战