hyperf定时任务异常需通过进程状态、日志、资源水位联动告警：盯紧worker pid飙升、整点报错、check_worker_exit_status非零退出、redis队列堆积等信号，结合hyperf-alarm-clock耗时监控、k8s资源限制与探针、结构化日志过滤实现可观测闭环。
Hyperf 定时任务执行报错或进程异常退出（如 check_worker_exit_status 日志、worker 静默崩溃、OOM Kill）时，仅靠人工巡检很难及时发现。要实现「自动告警」，关键不是等错误发生后再查，而是把进程状态、执行日志、资源水位三者联动起来，形成可观测闭环。
定时任务异常的典型信号要盯紧
不是所有报错都会立刻体现为 PHP 异常，很多是底层进程级问题：
- worker 进程 ID 持续飙升（如日志中出现 PID > 100000），大概率是 crontab-dispatcher 或任务未释放资源导致 fork 泄漏；
-
整点/固定间隔前后集中报错，配合
crontab配置检查，大概率是某条定时任务逻辑卡死、内存泄漏或未 catch 的协程异常； -
日志中出现
check_worker_exit_status+ 进程退出码非 0，说明 worker 被系统强制终止（常见于 OOM Kill 或超时 SIGKILL）； - Redis 队列堆积、消费者静默退出，可能源于定时任务里投递了超大 Job（如未压缩的 5MB 订单数组），触发 Redis 缓冲区卡死或协程挂起。
用 hyperf-alarm-clock 监控单次执行耗时
对高风险定时任务（如报表生成、批量同步），可在 handle() 内部加一层执行兜底监控：
- 安装
pudongping/hyperf-alarm-clock:^3.0，确保 PHP ≥ 8.1、Hyperf ~3.1.0； - 配置
hyperf_alarm_clock.php，开启'enable' => true，并至少配置一种通知通道（如飞书 Webhook）； - 在 Crontab 类中手动包裹关键逻辑：
use Pudongping\HyperfAlarmClock\AlarmClock;
class DailyReportCron {
public function execute() {
AlarmClock::run(fn() => $this->generateReport(), 300); // 超过 300 秒触发告警
}
}
K8s 层面必须配置的资源与健康探针
Hyperf 本身不管理 POD 生命周期，告警需依赖 K8s 原生能力：
-
限制内存上限：在 deployment 中设置
resources.limits.memory: 1Gi，避免单 POD 吃光节点内存； -
配置 livenessProbe：用
curl http://localhost:9501/health检查 HTTP 服务存活（需启用 health 组件）； -
配置 readinessProbe：同样走
/health，但更建议增加redis.ping和crontab.ready自定义检查项，防止 POD 就绪但定时任务已卡死； -
启用 K8s Event 告警：监听
OOMKilled、FailedPostStartHook、BackOff等事件，直接对接企业微信/钉钉机器人。
日志结构化 + 关键字段过滤告警
原始日志难排查，必须让日志自带上下文：
- 在
config/autoload/logger.php中为 crontab 日志单独配置 channel，启用context字段输出worker_id、task_name、pid； - 使用 Filebeat 或 Loki 收集日志，设置告警规则匹配：
level:"ERROR" AND (message:"check_worker_exit_status" OR message:"Segmentation fault" OR message:"Killed process")； - 对定时任务 SQL，统一加
/* cron:DailySync */注释，便于在慢日志或 Redis Monitor 中快速定位来源。
