推荐学习书目
› Learn Python the Hard Way
Python Sites
› PyPI - Python Package Index
› http://diveintopython.org/toc/index.html
› Pocoo
值得关注的项目
› PyPy
› Celery
› Jinja2
› Read the Docs
› gevent
› pyenv
› virtualenv
› Stackless Python
› Beautiful Soup
› 结巴中文分词
› Green Unicorn
› Sentry
› Shovel
› Pyflakes
› pytest
Python 编程
› pep8 Checker
Styles
› PEP 8
› Google Python Style Guide
› Code Style from The Hitchhiker's Guide
问个问题，关于 Celery 的 worker 和 beat
zhoudaiyu ·PRO
这是一个创建于 2570 天前的主题，其中的信息可能已经有所发展或是发生改变。
项目是一个接收 CAT 和 FALCON 告警，然后把告警处理一下展示出来再把告警发出去的平台，需要做一些异步任务和定时任务等，因此用了 Celery 并用 Redis 做 broker。上周一晚上 23 点突然 beat 和 worker 的日志不打了，但是进程都还在，当初看了 worker 的日志，发现接了几个任务，日志就停在那了。第二天重启项目，那些积压的告警一下全发出来了。大家遇到过这种情况吗？我觉得应该不是程序的问题，可能是 Celery 或者 Redis 的问题，大家觉得呢？还有一个问题就是项目启动的时候有时候 worker 全部起不起来，必须重启后才解决（偶发），大家遇到过吗？
 |
1
fanhaipeng0403 2018 年 12 月 29 日
建议用 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 |
 |
2
zhoudaiyu OP PRO @fanhaipeng0403 谢谢您！请问 celery 对 redis 的支持有问题吗？对 RMQ 的支持好一些？
|
|
3
fanhaipeng0403 2018 年 12 月 29 日  1
RabbitMQ is feature-complete, stable, durable and easy to install. It ’ s an excellent choice for a production environment.
官方文档推荐的~ @zhoudaiyu |
|
4
zhoudaiyu OP PRO @fanhaipeng0403 好的，我看看文档！谢谢啦
|
 |
5
Eds1995 2018 年 12 月 30 日 via Android
这不是 redis 的问题，很可能是 celery_schedule 的问题，总觉得用 celery 自带的 beat 来做定时器总会出现各种问题，现在有两种选择，自己写 beat，或者换一个库
|
 |
7
chashao 2018 年 12 月 30 日 via Android
会不会是那几个任务把 worker 阻塞了……
|
 |
9
a663 2018 年 12 月 30 日 via Android
之前用 celery 和 rabbitmq 也遇到过同样的问题
|
|
11
a663 2018 年 12 月 30 日 via Android
@zhoudaiyu 我是运维，那时候是开发那边去看的，我觉得可以尝试多加点监控看看，监控 celery 和 mq，做到精细化去，我后面离职了，对这个 bug 一直念念不忘，诶。
|
 |
14
julyclyde 2018 年 12 月 31 日
你得看看 worker 卡在哪儿了
先开详细日志，看看执行到哪个 task 函数里了 然后改这个 task 函数，里边可疑的动作都加上“动作前输出时间戳”和“动作后输出时间戳” 如果卡死的，会发现这俩不配对 如果特别慢，相减得到时长可很明显看出来 |
|
15
zhoudaiyu OP PRO |
|
16
a663 2018 年 12 月 31 日 via Android 1
@zhoudaiyu 一定还会有的，哈哈哈
其实我那时候这么分析，消息队列模型，worker 主动去 MQ 取出消息消费，监控 MQ 消息有没有丢（一般不会），再做一些 worker 的监控，最终看下次遇到问题的情况进一步处理。 如果单纯的是 beat 定时任务，可以做一个超时重试的参数（我那时候的业务，定时任务就是去改数据库的一些东西，无所谓就做了超时）。但是非 beat 的，这个真的需要去好好定位，如果对业务无所谓，可以考虑加 timeout 参数 |
|
18
a663 2018 年 12 月 31 日 via Android
@zhoudaiyu 日志基本看不出什么来，还是从原理上抓起，理解消息队列模型，理解 worker 工作过程，然后根据这些去深挖
|
|
20
fanhaipeng0403 2019 年 1 月 1 日 1
@zhoudaiyu
可以使用 celery 提供的信号接口，监测每个任务的执行时间，然后发给 statsd 或者 promethus 之类的 https://github.com/getredash/redash/blob/master/redash/metrics/celery.py 这个是代码例子 |
 |
21
a226679594 2019 年 1 月 2 日
让它多产生日志就有了
|
Select Language