Superset/Celery Beat定时报告部分日期失败求助及补跑方法咨询

• Celery Beat/Worker进程异常：故障期间Beat进程可能意外挂起、重启，或Worker节点离线，导致任务无法被调度、执行
• 消息队列故障：Redis/RabbitMQ等消息队列出现断连、队列堆积、资源耗尽，任务无法正常传递给Worker
• 元数据数据库问题：Superset依赖的元数据库（如PostgreSQL）出现连接超时、锁表、查询延迟，导致定时任务的触发记录无法被读取或更新
• 系统资源瓶颈：服务器CPU、内存、磁盘IO在这段时间内耗尽，导致Celery或Superset进程被系统强制暂停
• 时区/任务规则冲突：Celery Beat与Superset的时区配置不一致，或cron规则在故障日期范围内存在触发盲区（如特殊日期的规则匹配问题）

• 检查Celery进程状态：
  • 执行ps aux | grep celery，确认Beat和Worker进程在故障期间是否持续运行，有没有频繁重启的记录
  • 查看Celery日志文件（通常在/var/log/superset/或自定义路径），筛选11月22日至12月2日的日志，查找ERROR或CRITICAL级别的报错（如连接超时、任务提交失败）
• 排查消息队列状态：
  • 若使用Redis，执行redis-cli info stats查看队列长度、连接数，确认期间有没有队列阻塞或连接断开的情况；用redis-cli keys "*celery*"查看Celery相关键的状态
  • 若使用RabbitMQ，通过管理控制台查看队列的消息堆积数、消费者状态，检查是否有连接异常日志
• 检查元数据数据库：
  • 查看数据库的错误日志，排查故障期间是否有连接失败、锁表、查询超时的情况
  • 登录元数据库，查询scheduled_task表（不同Superset版本表名可能为sl_schedule），查看故障期间任务的last_run_dttm、next_run_dttm字段，确认任务是否被正确调度
• 核对系统资源监控：
  • 查看服务器的历史监控数据（如top、iostat、df -h的历史记录），确认故障期间CPU、内存使用率是否过高，磁盘是否已满
• 验证时区与任务规则：
  • 检查Superset配置TIME_ZONE和Celery Beat的时区配置是否一致，执行superset config show | grep TIME_ZONE查看Superset时区
  • 核对任务的cron表达式，测试在故障日期范围内是否能正确触发

• UI手动触发：
  登录Superset后台，进入「定时任务」页面，找到目标报告任务，点击「运行」按钮，逐个补跑对应日期的任务（若任务按天生成，需手动调整执行日期或重复执行）
• 命令行批量补跑：
  1. 进入Superset的虚拟环境（如果使用虚拟环境）：source /path/to/superset/venv/bin/activate
  2. 列出所有定时任务，获取目标任务的ID：superset list_scheduled_tasks
  3. 执行补跑命令，指定日期范围：

     superset run_scheduled_task --task-id <你的任务ID> --start-date '2024-11-22' --end-date '2024-12-02'
     

  注意：部分Superset版本可能需要使用superset run_schedule命令，需根据版本调整

内容的提问来源于stack exchange，提问作者suhail areekkan