Celery Worker无故障迹象意外停止的原因排查求助

针对你描述的场景——运行48小时的机器学习训练任务、Worker间协同调用、K8s环境下仅留下sync with celery@thori-at-pronosticos-worker-forecast-model-training-deployhvhhl日志后停止，以下是常见的排查方向：

• Kubernetes资源限制触发驱逐
  如果Pod的内存/CPU请求/限制设置不合理，长时间的ML训练可能导致资源超限，触发K8s的OOMKiller直接终止Pod。这种情况下Celery进程来不及输出错误日志，仅能完成最后一次节点同步。可以检查Pod的resources配置，以及宿主机的dmesg日志（查找oom-killer相关记录）。

• Celery超时/心跳配置不当
  若Worker的--timeout或--soft-timeout参数设置过短，或者与Broker（如RabbitMQ/Redis）的心跳间隔配置不合理，长时间运行的训练任务可能被Celery判定为失联，进而被强制终止。默认情况下Celery的超时时间可能远短于48小时，需确认任务是否超过了Worker的超时阈值。

• Broker连接异常中断
  当Broker（消息中间件）出现重启、网络分区或连接断开时，Worker在尝试同步节点状态后可能因连接失败静默退出，且未生成错误日志。可以检查Broker的运行状态、连接日志，以及Worker与Broker之间的网络连通性。

• 宿主机级别的故障
  宿主机重启、磁盘空间耗尽、网络中断等节点级问题会导致Pod被强制终止，日志被截断，仅保留最后一条同步记录。可以查看节点的系统日志、磁盘使用情况，以及K8s节点的事件记录（kubectl describe node <node-name>）。

• Celery内部同步/任务调用异常
  Worker间互相调用任务时，若出现死锁、未捕获的异常或状态同步逻辑错误，可能导致进程静默退出，无错误日志输出。比如任务依赖循环导致死锁，或者回调函数中的未处理异常直接终止了Worker进程。

• 进程级资源耗尽
  Worker进程本身存在内存泄漏，运行48小时后内存耗尽被系统内核杀死，这种情况下Celery层面不会生成错误日志，仅能在系统日志中找到OOM相关记录。

内容的提问来源于stack exchange，提问作者Diego L