要让crontab任务可查、不丢、好分析，需分三步：一查系统级调度日志（如/var/log/cron或journalctl -u cron）确认是否触发；二重定向任务自身输出（>> /var/log/xxx.log 2>&1）捕获真实执行结果；三规范环境与路径（声明path、用绝对路径、显式调用bash），并做好日志归档与维护。
要让 crontab 任务的执行过程可查、不丢、好分析，不能只靠系统默认行为，得主动设计日志路径、明确输出流向、分层排查线索。
系统级调度日志：确认任务是否被触发
这是第一步——看 cron 守护进程有没有“看到”你的任务。
- CentOS/RHEL 系统：直接查看 /var/log/cron，里面记录了每次任务的触发时间、用户、命令摘要和退出码（如 CRON[12345]: (user) CMD (/path/script.sh)）
- Ubuntu/Debian 系统：默认写入 /var/log/syslog，用
grep CRON /var/log/syslog筛选；若已启用 cron 模块，也可能有 /var/log/cron.log - systemd 系统（含统信UOS）：运行
sudo journalctl -u cron -n 50查最近日志，或sudo journalctl -u cron -f实时跟踪新条目
任务自身输出日志：捕获真实执行结果
系统日志只告诉你“任务启动了”，但脚本里 print 了什么、报错在哪一行，得靠你自己重定向。
- 用
>>追加，别用>覆盖：例如0 2 * * * /opt/bin/backup.sh >> /var/log/backup.log 2>&1 -
2>&1把错误也合并进来，避免 stderr 消失；若需分离排查，可写成> /var/log/backup.out 2> /var/log/backup.err - 确保目标目录可写：比如 root 运行的任务，不能往普通用户
~/logs/写；推荐统一用/var/log/下带权限的子目录
环境与路径：避免“手动能跑，cron 不行”
很多任务失败不是逻辑问题，而是 cron 启动时环境太干净。
- 在 crontab 文件顶部声明：
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin - 必要时显式调用 bash：crontab 默认用
/bin/sh，不支持$(date)等语法，要用/bin/bash -c 'command >> file_$(date +\%Y\%m\%d).log 2>&1' - 脚本第一行加
#!/bin/bash，且用绝对路径调用（/usr/bin/python3而非python3）
归档与维护：让日志长期可用不膨胀
日志堆久了会占满磁盘，也难定位问题，得提前规划。
- 按日期命名日志文件，配合
logrotate：把/var/log/myscripts/*.log加入/etc/logrotate.d/myscripts，设保留 30 天、自动 gzip 压缩 - 在 crontab 中关闭邮件通知：
MAILTO=""，防止因本地邮件服务未配导致 silent fail - 对关键任务加简单校验：比如在命令后接
&& echo "$(date) OK" || echo "$(date) FAILED"，快速判断成败
