问个问题，关于 Celery 的 worker 和 beat

项目是一个接收 CAT 和 FALCON 告警，然后把告警处理一下展示出来再把告警发出去的平台，需要做一些异步任务和定时任务等，因此用了 Celery 并用 Redis 做 broker。上周一晚上 23 点突然 beat 和 worker 的日志不打了，但是进程都还在，当初看了 worker 的日志，发现接了几个任务，日志就停在那了。第二天重启项目，那些积压的告警一下全发出来了。大家遇到过这种情况吗？我觉得应该不是程序的问题，可能是 Celery 或者 Redis 的问题，大家觉得呢？还有一个问题就是项目启动的时候有时候 worker 全部起不起来，必须重启后才解决（偶发），大家遇到过吗？

Worker

Celery

日志

Redis

21 条回复 • 2019-01-02 09:22:41 +08:00

fanhaipeng0403

2018-12-29 21:56:38 +08:00

建议用 rabittmq。
还算稳定,分享下我的配置

CELERY_IGNORE_RESULT = True
CELERY_BROKER_URL = '‘ xxxx ’
CELERY_TIMEZONE = 'xxx'
CELERY_DEFAULT_QUEUE = 'default'
CELERY_CREATE_MISSING_QUEUES = 'default'

BROKER_HEARTBEAT = 24*60*60*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

zhoudaiyu

2018-12-29 22:08:36 +08:00 via iPhone

@fanhaipeng0403 谢谢您！请问 celery 对 redis 的支持有问题吗？对 RMQ 的支持好一些？

fanhaipeng0403

2018-12-29 22:17:00 +08:00

RabbitMQ is feature-complete, stable, durable and easy to install. It ’ s an excellent choice for a production environment.

官方文档推荐的~
@zhoudaiyu

zhoudaiyu

2018-12-29 22:22:16 +08:00 via iPhone

@fanhaipeng0403 好的，我看看文档！谢谢啦

Eds1995

2018-12-30 02:25:53 +08:00 via Android

这不是 redis 的问题，很可能是 celery_schedule 的问题，总觉得用 celery 自带的 beat 来做定时器总会出现各种问题，现在有两种选择，自己写 beat，或者换一个库

zhoudaiyu

2018-12-30 06:25:07 +08:00 via iPhone

@Eds1995 比如可以换成什么库呢？

chashao

2018-12-30 13:55:33 +08:00 via Android

会不会是那几个任务把 worker 阻塞了……

zhoudaiyu

2018-12-30 14:29:36 +08:00 via iPhone

@chashao 不会吧一直都是这些任务都没变过，怎么就突然死了呢

a663

2018-12-30 18:44:27 +08:00 via Android

之前用 celery 和 rabbitmq 也遇到过同样的问题

zhoudaiyu

2018-12-30 19:09:51 +08:00 via iPhone

@a663 那后来怎么解决的？不用 celery 了吗？

a663

2018-12-30 22:31:11 +08:00 via Android

@zhoudaiyu 我是运维，那时候是开发那边去看的，我觉得可以尝试多加点监控看看，监控 celery 和 mq，做到精细化去，我后面离职了，对这个 bug 一直念念不忘，诶。

zhoudaiyu

2018-12-31 00:02:44 +08:00 via iPhone

@a663 我也是运维运维开发...

a663

2018-12-31 08:59:02 +08:00 via Android

@zhoudaiyu 哈哈哈，你要是处理了这个，记得分享一下呀

julyclyde

2018-12-31 09:15:18 +08:00

你得看看 worker 卡在哪儿了

先开详细日志，看看执行到哪个 task 函数里了
然后改这个 task 函数，里边可疑的动作都加上“动作前输出时间戳”和“动作后输出时间戳”
如果卡死的，会发现这俩不配对
如果特别慢，相减得到时长可很明显看出来

zhoudaiyu

2018-12-31 10:16:00 +08:00 via iPhone

@a663 希望不要再发生了...

@julyclyde 我就翻了翻 WORKER 的日志...没啥问题好像

a663

2018-12-31 14:02:33 +08:00 via Android

@zhoudaiyu 一定还会有的，哈哈哈
其实我那时候这么分析，消息队列模型，worker 主动去 MQ 取出消息消费，监控 MQ 消息有没有丢（一般不会），再做一些 worker 的监控，最终看下次遇到问题的情况进一步处理。
如果单纯的是 beat 定时任务，可以做一个超时重试的参数（我那时候的业务，定时任务就是去改数据库的一些东西，无所谓就做了超时）。但是非 beat 的，这个真的需要去好好定位，如果对业务无所谓，可以考虑加 timeout 参数

zhoudaiyu

2018-12-31 19:10:05 +08:00 via iPhone

@a663 较为关键的业务 beat worker 都要用实在不行我写个东西监控日志吧..

a663

2018-12-31 20:04:24 +08:00 via Android

@zhoudaiyu 日志基本看不出什么来，还是从原理上抓起，理解消息队列模型，理解 worker 工作过程，然后根据这些去深挖

julyclyde

2018-12-31 21:00:13 +08:00

@zhoudaiyu 你让它多产生日志就有了

fanhaipeng0403

2019-01-01 14:24:51 +08:00

@zhoudaiyu

可以使用 celery 提供的信号接口，监测每个任务的执行时间，然后发给 statsd 或者 promethus 之类的

https://github.com/getredash/redash/blob/master/redash/metrics/celery.py

这个是代码例子

a226679594

2019-01-02 09:22:41 +08:00

让它多产生日志就有了