Python中关于Celery的worker和beat使用问题
项目是一个接收 CAT 和 FALCON 告警，然后把告警处理一下展示出来再把告警发出去的平台，需要做一些异步任务和定时任务等，因此用了 Celery 并用 Redis 做 broker。上周一晚上 23 点突然 beat 和 worker 的日志不打了，但是进程都还在，当初看了 worker 的日志，发现接了几个任务，日志就停在那了。第二天重启项目，那些积压的告警一下全发出来了。大家遇到过这种情况吗？我觉得应该不是程序的问题，可能是 Celery 或者 Redis 的问题，大家觉得呢？还有一个问题就是项目启动的时候有时候 worker 全部起不起来，必须重启后才解决（偶发），大家遇到过吗？
Python中关于Celery的worker和beat使用问题
建议用 rabittmq。
还算稳定,分享下我的配置
CELERY_IGNORE_RESULT = True
CELERY_BROKER_URL = '‘ xxxx ’
CELERY_TIMEZONE = ‘xxx’
CELERY_DEFAULT_QUEUE = ‘default’
CELERY_CREATE_MISSING_QUEUES = ‘default’
BROKER_HEARTBEAT = 246060*2
CELERY_ENABLE_UTC = False
CELERY_DISABLE_RATE_LIMITS = True
CELERYD_MAX_TASKS_PER_CHILD = 10
BROKER_TRANSPORT_OPTIONS = {‘visibility_timeout’: 1800}
CELERYD_FORCE_EXECV = True
BROKER_POOL_LIMIT = None
RabbitMQ is feature-complete, stable, durable and easy to install. It ’ s an excellent choice for a production environment.
官方文档推荐的~
这不是 redis 的问题，很可能是 celery_schedule 的问题，总觉得用 celery 自带的 beat 来做定时器总会出现各种问题，现在有两种选择，自己写 beat，或者换一个库
你得看看 worker 卡在哪儿了
先开详细日志，看看执行到哪个 task 函数里了
然后改这个 task 函数，里边可疑的动作都加上“动作前输出时间戳”和“动作后输出时间戳”
如果卡死的，会发现这俩不配对
如果特别慢，相减得到时长可很明显看出来
一定还会有的，哈哈哈
其实我那时候这么分析，消息队列模型，worker 主动去 MQ 取出消息消费，监控 MQ 消息有没有丢（一般不会），再做一些 worker 的监控，最终看下次遇到问题的情况进一步处理。
如果单纯的是 beat 定时任务，可以做一个超时重试的参数（我那时候的业务，定时任务就是去改数据库的一些东西，无所谓就做了超时）。但是非 beat 的，这个真的需要去好好定位，如果对业务无所谓，可以考虑加 timeout 参数
可以使用 celery 提供的信号接口，监测每个任务的执行时间，然后发给 statsd 或者 promethus 之类的
https://github.com/getredash/redash/blob/master/redash/metrics/celery.py
这个是代码例子
