Crontab 日志指南：定时任务日志在哪、怎么读、如何监控"沉默失败"
crontab 定时任务失败了却没发现？本文讲解 crontab 日志在各系统的存放位置、日志格式解读、自定义任务日志的重定向与结构化写法、logrotate 配套，以及用观测云监控定时任务"沉默失败"的完整方案。
Crontab 日志（Cron Log）是 cron 守护进程执行定时任务时产生的系统级记录，包含任务启动时间、执行用户、命令内容与退出状态，是排查"定时任务为何没跑/跑挂"的审计依据。 定时任务在后台静默运行，没有日志可见性，任务失败数周都可能无人察觉——备份没执行、证书没续期，往往都是这样酿成的。
核心要点速览
- 各系统位置不同：Debian/Ubuntu 在
/var/log/syslog，RHEL/CentOS 在/var/log/cron，macOS 在/var/log/system.log； - 系统日志只记录"跑了没有"，脚本自己的输出要手动重定向到日志文件才能看到；
- 任务日志必须配 logrotate，否则自定义日志文件同样会撑爆磁盘；
- 除了报错，还要检查任务是否按期结束：为成功记录约定时间窗口，并单独检测日志缺失。
crontab 日志存在哪里？
| 系统 | 日志位置 | 查看命令 |
|---|---|---|
| Debian / Ubuntu | /var/log/syslog |
grep CRON /var/log/syslog |
| RHEL / CentOS / Fedora | /var/log/cron |
tail -f /var/log/cron |
| macOS | /var/log/system.log |
grep cron /var/log/system.log |
实时跟踪 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
}
最大的坑："沉默失败"
任务失败可能有错误日志，也可能连启动记录都没有。为每日备份约定最晚完成时间，并同时检查任务输出和采集链路。
在观测云中，可按以下步骤检查本文的备份任务：
- 用 DataKit 文件采集 读取
/var/log/backup.log，以主机及任务名区分不同任务。 - 在 日志检测 中筛选该任务的
[ERROR]记录，按数量设置触发条件与通知。 - 对
[SUCCESS]记录另建检查。例如任务每天 02:00 开始、约定 03:00 前完成，可在 03:00 查询本次运行窗口，并配置数据断档事件；默认的“不触发事件”不会报告缺失。 - 停掉测试任务验证缺失告警，再恢复任务验证恢复行为。没有日志时，还需区分任务未运行与采集器未上报。
安全注意事项
- 任务日志可能含内网路径、账户信息，文件权限收紧：
chown root:adm+chmod 640； - 脚本不要打印密码或 API Key。采集侧需处理敏感内容时，在上报前配置 本地 Pipeline，用真实格式样本验证脱敏结果；
- 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：观测云能监控"任务没跑"这种无日志场景吗？
可以对成功日志配置数据断档检测。检测窗口要覆盖预期执行时间及允许延迟，并通过停跑一次测试任务验证，不能把任意时段没有日志都算成故障。
系列阅读：Linux 系统日志管理入门 ｜ Logrotate 日志轮转实战
