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

2018-12-29 21:45:40 +08:00
 zhoudaiyu
项目是一个接收 CAT 和 FALCON 告警,然后把告警处理一下展示出来再把告警发出去的平台,需要做一些异步任务和定时任务等,因此用了 Celery 并用 Redis 做 broker。上周一晚上 23 点突然 beat 和 worker 的日志不打了,但是进程都还在,当初看了 worker 的日志,发现接了几个任务,日志就停在那了。第二天重启项目,那些积压的告警一下全发出来了。大家遇到过这种情况吗?我觉得应该不是程序的问题,可能是 Celery 或者 Redis 的问题,大家觉得呢?还有一个问题就是项目启动的时候有时候 worker 全部起不起来,必须重启后才解决(偶发),大家遇到过吗?
3160 次点击
所在节点    Python
21 条回复
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
@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
@fanhaipeng0403 好的,我看看文档!谢谢啦
Eds1995
2018-12-30 02:25:53 +08:00
这不是 redis 的问题,很可能是 celery_schedule 的问题,总觉得用 celery 自带的 beat 来做定时器总会出现各种问题,现在有两种选择,自己写 beat,或者换一个库
zhoudaiyu
2018-12-30 06:25:07 +08:00
@Eds1995 比如可以换成什么库呢?
chashao
2018-12-30 13:55:33 +08:00
会不会是那几个任务把 worker 阻塞了……
zhoudaiyu
2018-12-30 14:29:36 +08:00
@chashao 不会吧 一直都是这些任务都没变过,怎么就突然死了呢
a663
2018-12-30 18:44:27 +08:00
之前用 celery 和 rabbitmq 也遇到过同样的问题
zhoudaiyu
2018-12-30 19:09:51 +08:00
@a663 那后来怎么解决的?不用 celery 了吗?
a663
2018-12-30 22:31:11 +08:00
@zhoudaiyu 我是运维,那时候是开发那边去看的,我觉得可以尝试多加点监控看看,监控 celery 和 mq,做到精细化去,我后面离职了,对这个 bug 一直念念不忘,诶。
zhoudaiyu
2018-12-31 00:02:44 +08:00
@a663 我也是运维 运维开发...
a663
2018-12-31 08:59:02 +08:00
@zhoudaiyu 哈哈哈,你要是处理了这个,记得分享一下呀
julyclyde
2018-12-31 09:15:18 +08:00
你得看看 worker 卡在哪儿了

先开详细日志,看看执行到哪个 task 函数里了
然后改这个 task 函数,里边可疑的动作都加上“动作前输出时间戳”和“动作后输出时间戳”
如果卡死的,会发现这俩不配对
如果特别慢,相减得到时长可很明显看出来
zhoudaiyu
2018-12-31 10:16:00 +08:00
@a663 希望不要再发生了...

@julyclyde 我就翻了翻 WORKER 的日志...没啥问题好像
a663
2018-12-31 14:02:33 +08:00
@zhoudaiyu 一定还会有的,哈哈哈
其实我那时候这么分析,消息队列模型,worker 主动去 MQ 取出消息消费,监控 MQ 消息有没有丢(一般不会),再做一些 worker 的监控,最终看下次遇到问题的情况进一步处理。
如果单纯的是 beat 定时任务,可以做一个超时重试的参数(我那时候的业务,定时任务就是去改数据库的一些东西,无所谓就做了超时)。但是非 beat 的,这个真的需要去好好定位,如果对业务无所谓,可以考虑加 timeout 参数
zhoudaiyu
2018-12-31 19:10:05 +08:00
@a663 较为关键的业务 beat worker 都要用 实在不行我写个东西监控日志吧..
a663
2018-12-31 20:04:24 +08:00
@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

这个是代码例子

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/522414

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX