监控ThinkPHP6定时任务需构建可观测性闭环：在Command类execute()中埋点记录任务名、执行时间、耗时、状态及错误摘要并写入结构化日志或数据库；结合Crontab的time命令补全系统级耗时对比；建sys_cron_log表聚合分析失败率、P95耗时与趋势，用Grafana可视化并按失败类型分层告警。
监控 ThinkPHP6 定时任务运行状态，关键在于「可观测性闭环」：既要捕获每次执行的原始数据（是否成功、耗时多少、错在哪），又要聚合分析趋势（比如某任务最近三天平均慢了40%），还得能快速告警。不能只靠看日志尾巴或等用户反馈。
在命令类中埋点记录核心指标
所有定时任务逻辑都封装在 app/command/ 下的 Command 类中，这是最精准的监控入口。务必在 execute() 方法开头和结尾加入计时与状态标记：
- 用
microtime(true)记录起始时间，执行完再算差值，得到脚本内纯业务耗时（单位秒，保留三位小数） - 统一记录任务名（取
$this->getName()）、执行时间（date('Y-m-d H:i:s')）、返回码（return 0表示成功，非零需记为失败）、错误摘要（try...catch捕获异常消息，截取前200字符） - 把这组数据写入结构化日志文件（如 JSON 行格式），或直接插入数据库监控表——字段至少含：
task_name、exec_time、duration_ms、status、error_summary
通过 Crontab 日志补全系统级视图
Crontab 调用的是整个 PHP 进程，它的耗时包含框架加载、自动加载、配置解析等开销，和脚本内计时不一致时，就能定位瓶颈在哪：
- 在 crontab 条目中加
time命令包裹：* * * * * /usr/bin/time -f "CRON_REAL:%e|USER:%U|SYS:%S" /usr/bin/php /var/www/myproject/think cron:sync-data >> /var/log/cron-sync.log 2>&1 - 这样每行日志开头会多出类似
CRON_REAL:8.234|USER:0.456|SYS:0.112的标记，real 时间远大于脚本内耗时，说明启动慢；user/sys 高但脚本内耗时低，可能是 I/O 或 CPU 密集型操作 - 日志重定向必须显式写全（
>>和2>&1），否则错误被丢弃，监控就漏掉了最关键的失败信号
建立轻量数据库表+基础可视化
单次日志没价值，持续积累才能看出问题。建一张最小可用监控表即可：
- 表名建议
sys_cron_log，字段：id（自增）、task_name（varchar 64）、exec_time（datetime）、duration_ms（int）、status（tinyint，0=success, 1=failed）、error_summary（varchar 500） - 在 Command 的
execute()结尾，用\think\Db::name('sys_cron_log')->insert([...])写入，不依赖事务，失败也不影响主逻辑 - 用 Grafana 连接该表，画三条基础曲线：「每日失败率」（count failed / total）、「P95 耗时」（按 task_name 分组查 percentile_cont）、「平均耗时变化趋势」；设置阈值告警，例如「cron:sync-data 连续2次耗时 >15s」发钉钉通知
区分失败类型，避免误判
不是所有失败都要立刻告警，要分层处理：
- 可重试失败：如远程 API 超时、数据库连接短暂抖动，记录 error_summary 含 “cURL error 28” 或 “SQLSTATE[HY000] [2002]”，这类可设静默期（如1小时内同错误只报1次）
- 致命失败：如 Class not found、Parse error、权限拒绝（Permission denied），说明部署或配置出错，需立即告警并停止后续调度
- 假成功：脚本返回 0，但业务逻辑没执行（如缓存清空代码被注释了），靠日志关键词匹配（如检查日志中是否出现 “✅ 缓存已清空”）来交叉验证
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
