2014-03-12 3 views
8

Ich habe ein Django-Projekt mit Cron-Skript ausgeführt, Ausführen eines Verwaltungsbefehls. Dieser Befehl erstellt für Zyklus Aufgaben für Sellerie in:Sellerie Aufgaben verschwinden

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

Und die Aufgabe wie folgt aussieht:

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) 
    .... 

Da u sehen kann, ich habe einen Logger vor der Aufgabenausführung und in der ersten Zeile in seinem Inneren. Das Problem ist - nach der Aktualisierung des Projektcodes (ein anderer Programmierer hat andere Aufgaben und Sellerie-Versionsupdate hinzugefügt) verschwinden die meisten meiner Aufgaben. Meine Log-Datei sieht wie folgt aus (nur 1 von 8-10 Aufgaben ausgeführt):

[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 

Die Sellerie Protokolldatei noch keine hilfreichen Informationen enthält. So auch Kaninchen. Es hat viele dieser Sachen, aber es ist nicht mit meinen Aufgaben verbunden, oder tut es?

[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 

Was könnte möglicherweise das Problem sein? Wie kann ich Aufgabe verfolgen, um zu verstehen, wenn sie verschwindet?

Bitte helfen =)

+0

Haben Sie versucht, den Loglevel auf DEBUG anstelle von INFO zu setzen? – olofom

+0

>> Haben Sie versucht, den Loglevel auf DEBUG anstelle von INFO zu setzen? Keine Zusatzinfo = ( – shaihulud

+0

Es ist schwer zu sagen, was Ihr Problem ohne detaillierte Informationen ist versuchen, zuerst 'rabbitmqctl list_queues' oder wenn Sie vhost verwenden. ' rabbitmqctl list_queues -p ' und sehen Sie, dass diese Aufgaben wirklich bekommen tun in RabbitMQ gespeichert. Wenn nicht, dann überprüfe deine Konfigurationsdatei. Beachten Sie, dass Sie, wenn Sie django_celery verwenden, dies zu den Einstellungen hinzufügen müssen: 'import djcellery; djcelery.setup_loader() '. Übrigens: Wenn Sie mehrere Worker haben und sich in derselben Datei anmelden, haben Sie möglicherweise Probleme mit der Dateisperre bei einigen Arbeitern, die die Zeilen anderer Benutzer überschreiben. – seeg

Antwort

1

Hier starten ist der Grund meines Problems:
http://docs.python.org/2/howto/logging-cookbook.html#logging-to-a-single-file-from-multiple-processes
Obwohl die Protokollierung threadsicher, und die Protokollierung in einer einzigen Datei aus mehreren Threads in einem einzigen Prozess wird unterstützt. Die Protokollierung in einer einzelnen Datei aus mehreren Prozessen wird nicht unterstützt, da es keinen Standard gibt, den Zugriff auf eine einzelne Datei über mehrere Prozesse in Python zu serialisieren . Wenn Sie sich bei einer einzelnen Datei aus mehreren Prozessen anmelden müssen, können Sie beispielsweise alle Prozesse bei einem SocketHandler anmelden und einen separaten Prozess implementieren, der einen Socket-Server implementiert, der aus dem Socket liest und in der Datei protokolliert. (Wenn Sie möchten, können Sie einen Thread in einen der vorhandenen Prozesse einfügen, um diese Funktion auszuführen.) Dieser Abschnitt dokumentiert diesen Ansatz detaillierter und enthält einen funktionierenden Socket-Empfänger, der als Ausgangspunkt für die Anpassung in Ihrem System verwendet werden kann eigene Anwendungen.
http://docs.python.org/2/howto/logging-cookbook.html#sending-and-receiving-logging-events-across-a-network
Wenn eine kleine Last hatte alles perfekt funktioniert, aber mit seiner Zunahme habe ich das Problem konfrontiert.

5

Es ist möglich, dass Sie Sellerie Prozesse im Hintergrund laufen, Relikte aus früheren Starts haben, die nicht ordnungsgemäß heruntergefahren wurden, welche die Nachrichten konsumieren könnten. versuchen, um zu sehen, ob Sie

ps aux | grep celery

in der Befehlszeile, indem Sie diese Arbeitnehmer haben. Der folgende Befehl wird automatisch alle für Sie Sellerie Arbeiter solche verwaisten töten:

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

ich es ausführen, bevor meine app