2014-03-12 39 views
8

我有一个运行cron脚本的django项目,执行管理命令。此命令为循环任务芹菜创建于:芹菜任务消失

for r in pr: 
    log_task(tasks_logger.info, "to_queue", r) 
    remind.delay(r, now, send_all) 

,任务看起来是这样的:

class RTask(Task): 
    abstract = True 
    def on_failure(self, exc, task_id, args, kwargs, einfo): 
     r = args[0] 
     log_task(logger.error, exc, r) 
     log_task(logger_tb.error, einfo, r) 


@task(base=RTask) 
def remind(r, now, send_all): 
    log_task(logger.info, "from_queue", r) 
    .... 

就像你看到的,我的任务执行前和里面第一行有一个记录器。问题是 - 在项目代码更新后(另一个程序员添加了其他任务和芹菜版本更新),我的大多数任务开始消失。我的日志文件看起来像这样(只执行8-10 1任务):

[2014-03-12 12:45:08,806] 106152122 INFO to_queue 
[2014-03-12 12:45:08,819] 106138932 INFO to_queue 
[2014-03-12 12:45:08,915] 106121944 INFO to_queue 
[2014-03-12 12:45:08,916] 110418819 INFO from_queue 
[2014-03-12 12:45:08,922] 106075777 INFO to_queue 

芹菜日志文件不包含任何有用的信息。兔子也是。 它有很多这样的东西,但它与我的任务没有关系,或者它呢?

[2014-03-12 12:58:43,091: INFO/MainProcess] Got task from broker: celery.chord_unlock[7fe8f29f-69e1-456c-8a14-7fae0cfacc33] eta:[2014-03-12 12:58:44.089401+00:00] 
[2014-03-12 12:58:43,092: INFO/MainProcess] Task celery.chord_unlock[7fe8f29f-69e1-456c-8a14-7fae0cfacc33] retry: Retry in 1s 
[2014-03-12 12:58:43,092: INFO/MainProcess] Task celery.chord_unlock[7b1d4a6b-9a34-43e9-98c9-851c93ace5ce] retry: Retry in 1s 

可能是什么问题? 如何跟踪任务以了解它何时消失?

请帮助=)

+0

您是否尝试将日志级别设置为DEBUG而不是INFO? – olofom

+0

>>您是否尝试将日志级别设置为DEBUG而不是INFO? 没有附加信息=( – shaihulud

+0

这很难说,你的问题是没有什么详细信息,请首先尝试 'rabbitmqctl list_queues' 或者如果你使用虚拟主机: 'rabbitmqctl list_queues -p ' ,看到这些任务真的得到存储在RabbitMQ中。 如果没有,请再次检查您的配置文件。请注意,如果您使用的是django_celery,则需要将其添加到设置: 'import djcelery; djcelery.setup_loader()'。顺便说一句:如果你有多个工作人员并且正在登录到同一个文件,你可能会遇到文件锁定问题,一些工作人员会覆盖其他人的线路。 – seeg

回答

1

这里之前是我的问题的原因:
http://docs.python.org/2/howto/logging-cookbook.html#logging-to-a-single-file-from-multiple-processes
虽然日志线程安全并且在单个进程中从多个线程记录到单个文件是受支持的,因此不支持从多个进程记录到单个文件,因为没有标准的方式来在Python中的多个进程间串行化访问单个文件。如果你需要从多个进程登录到单个文件,一种方法是让所有进程登录到SocketHandler,并有一个单独的进程实现一个套接字服务器,该套接字服务器从套接字读取并记录到文件。 (如果你愿意,你可以在现有的一个进程中专用一个线程来执行这个功能。)本节更详细地介绍了这种方法,包括一个工作插座接收器,它可以作为一个起点,让你适应你的自己的应用。
http://docs.python.org/2/howto/logging-cookbook.html#sending-and-receiving-logging-events-across-a-network
当一个负载很小时,一切都很完美,但随着它的增加,我面临这个问题。

5

这有可能是你有在后台运行的进程芹菜,先前推出了未正常关闭,这可能是消费的消息的遗物。尝试看看,如果你有这样的工人通过在命令行中运行

ps aux | grep celery

。以下命令将自动杀死所有的这些孤儿芹菜工人为您提供:

ps aux | grep celery | awk '{system("kill -9 " $2)}'

我执行它推出我的应用程序