Cron 健康监控
将以下提示词粘贴到你的 AI 对话框中:
请根据 https://skillhub.cn/install/skillhub.md,安装 @user_3ef04463/openclaw-cron-health-monitor。
技能介绍
背景:cron 出问题往往很晚才被发现
Linux 上的 cron 负责按时间表跑备份、同步、清理和告警脚本。常见痛点不是「不会写 crontab」,而是任务静默失败:进程退出了但没人看邮件、日志轮转后证据没了、或者机器重启后条目没装回去。等磁盘满或业务报错时,往往已经漏跑了好几轮。
技能在对话里能帮你做什么
Cron Health Monitor 把「定时任务是否还在按预期跑」拆成可检查的项,让大模型按运维语境帮你梳理,而不是只给一段泛泛的 shell 教程。典型用法包括:
- 解读
crontab -l、systemd timer 或容器内 cron 的配置,标出时间表达式、用户上下文、环境变量是否完整 - 根据最近日志、
/var/log/cron或应用侧输出,判断是否按时触发、退出码是否非零、是否存在重叠执行 - 列出「上次成功运行时间」「预期间隔」与当前时间的差距,方便你决定是先查网络/权限还是先改 schedule
- 在 IT 运维与安全分类下,顺带提醒最小权限、敏感脚本路径、以及不要把密钥写进 crontab 注释等习惯性问题
你可以把现状(配置片段、报错、监控截图文字)贴给模型,让它给出下一步排查顺序,而不是一次性堆砌命令。
适用边界
本技能是分析与建议型能力,不会替你登录服务器执行命令,也不绑定某一款监控产品。实际是否「健康」仍依赖你环境中的日志保留、NTP、邮件/告警通道是否可用。若资料中未声明与特定平台(如 OpenClaw)的深度集成,应把它当作通用 cron 健康检查助手使用。
使用场景
- 备份脚本应在凌晨执行,业务侧反映数据未更新,需对照 crontab 与 cron 日志确认是否漏跑或退出码非零
- 新机器上线后把旧 crontab 迁过来,想逐项检查用户、环境变量与五段式时间表达式是否仍成立
- 容器内用 cron 跑清理任务,怀疑与宿主机时区或重叠执行有关,需要梳理 schedule 与最近运行记录
- 安全审计要求说明定时任务权限与脚本路径,需从现有配置归纳风险点并列出加固建议
适合人员
- 负责多台 Linux 服务器、需定期确认备份与同步 cron 是否仍按表执行的系统管理员
- 编写并维护 crontab 的 SRE,希望在告警前先搞清是 schedule、权限还是脚本本身导致未跑成功
- 把定时任务迁到容器或 K8s CronJob 后,需要对照旧表达式与日志验证行为是否一致的 DevOps 工程师
- 做基线检查时要把 cron 配置与日志留存、最小权限一并梳理的 IT 安全与合规同事