Так как же все-таки работает logging в celery и как его настроить?
Из того что я понял:
1. Celery добавляет в стандартный питоновский логгинг два логгера - celery и celery.task.
2. celery.task НЕ передает логи наверх в celery.
3. Ф-ция celery.utils.log.get_task_logger(name) создает логгер, привязанный к celery.task.
Вопросы:
1. Почему get_task_logger('some_name').name выдает 'some_name', а не celery.task.some_name? Ведь так же определяется иерархия логгеров. В доках питона так и рекомендуется делать (через __name__ для удобного создания иерархии).
2. Логгер celery - для всего, что творится в celery? Как тогда это работает при наличии нескольких воркеров, это же разные процессы?
3. Логгер celery.task тоже общий для всех или у каждого воркера свой?
4. Как вы настраиваете celery.task?
5. Зачем нужна worker_hijack_root_logger? Зачем вообще celery сбрасывать главный логгер?
6. А это worker_redirect_stdouts вообще зачем? Зачем редиректить стд в логгер? Неужели celery напичкан принтами? Нормально же делается наоборот: в коде импользуется логгер, а потом, если нужно, вешается необоходимый хендлер (хочешь - в стд, хочешь - в файл)
7. Тут еще вступают в дело сигналы, от чего становится еще "веселее"
8. Как вы настраиваете логгирование celery вместе с вашим django проектом?
Вобщем каша в голове, и дока по celery не помогает.
dimonchik2013, спасибо. Но не могли бы вы объяснить почему неспроста отдельно?
Как это работает: celery_logger пишет какие таски получил, и в случае ошибок он также пишет о retry. А celery_task_logger тем временем пишет сообщения из тасков. В итоге эта схема лишает логи тасков контекста (например это повторная попытка или нет?). Конечно можно по time и task_id восстановить последовательность событий, но это неудобно - придется какой-то скрипт писать для merge.