Записывать все запросы в файл Django

Когда я запускаю сервер разработки django (./manage.py runserver) все запрошенные URL-адреса удобно записываются в стандартный вывод процесса с указанием точного времени и кода ответа:

[09/Jun/2016 23:35:53] "GET /api/game/ HTTP/1.1" 404 3185
[09/Jun/2016 23:36:01] "GET /api/game/123/ HTTP/1.1" 404 1735

Это очень удобно, потому что при анализе вывода вы сразу же видите запрос, соответствующий вашим сообщениям журнала, например:

WARNING:2016-06-09 23:41:27,806:views:7449:140139847718656: No such object in the database: u'123'
[09/Jun/2016 23:41:27] "GET /api/game/123/ HTTP/1.1" 404 1735

Раньше я работал с uwsgi + nginx, поэтому для всего я использовал обработчик логов 'console', а затем запустил uwsgi следующим образом:

exec uwsgi --master --die-on-term --logto /var/log/uwsgi.log

В результате я получил все необходимые логины/var/log/uwsgi.log, записи запросов uwsgi и мои собственные сообщения регистрации.

Теперь я хочу добиться того же результата с помощью Apache + мод WSGI + django. Я хочу, чтобы единственный файл содержал все запросы и все журналы из моего приложения django в одном месте.

Я пытался добиться этого с помощью конфигурации ведения журнала Django, но даже когда я перенаправляю django.requests в тот же файл, я получаю только свои собственные сообщения в журналах, никаких запросов вообще. Вот часть конфигурации:

'handlers': {
    'file_handler': {
        'level': DEBUG and 'DEBUG' or 'INFO',
        'class': 'logging.handlers.RotatingFileHandler',
        'filename': join(LOG_DIRECTORY, 'api_log.log'),
        'maxBytes': 1024 * 1024 * 5,  # 5 MB
        'backupCount': 15,
        'formatter': 'verbose',
    },
},
'loggers': {
    'api': {
        'handlers': ['file_handler'],
        'level': DEBUG and 'DEBUG' or 'INFO',
    },
    'django': {
        'handlers': ['file_handler'],
        'level': DEBUG and 'DEBUG' or 'INFO',
    },
    'django.request': {
        'handlers': ['file_handler'],
        'level': DEBUG and 'DEBUG' or 'INFO',
    },
    'django.db.backends': {
        'handlers': ['file_handler'],
        'level': DEBUG and 'INFO' or 'WARNING',
        'propagate': False,
    },
}

Есть ли способ достичь поведения логирования nginx + uwsgi + django с помощью apache + WSGI + django? Или единственный способ сохранить apache access.log и мои журналы в отдельных файлах?

Я думаю, в первом случае это был сервер разработки, который регистрировал запросы, а во втором случае это был процесс uwsgi. Может быть, есть способ заставить WSGIDaemonProcess сделать то же самое?

Ответы на вопрос(1)

Решение Вопроса

что считается наилучшей практикой, пытаясь смешать журналы доступа и журналы ошибок. Традиционно они были разделены, чтобы можно было проводить анализ журналов доступа к трафику сервера.

Тем не менее, вы пытались изменитьErrorLog а такжеCustomLog директивы в Apache использовать тот же файл?

Когда я использовал mod_wsgi-express с командой:

mod_wsgi-express start-server --access-log --access-log-name application.log --error-log-name application.log

он генерирует:

<IfDefine MOD_WSGI_ROTATE_LOGS>
ErrorLog "|/usr/sbin/rotatelogs \
    /tmp/mod_wsgi-localhost:8000:502/application.log.%Y-%m-%d-%H_%M_%S 5M"
</IfDefine>
<IfDefine !MOD_WSGI_ROTATE_LOGS>
ErrorLog "/tmp/mod_wsgi-localhost:8000:502/application.log"
</IfDefine>
LogLevel warn

<IfDefine MOD_WSGI_ACCESS_LOG>
<IfModule !log_config_module>
LoadModule log_config_module ${MOD_WSGI_MODULES_DIRECTORY}/mod_log_config.so
</IfModule>
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
LogFormat "undefined" custom
<IfDefine MOD_WSGI_ROTATE_LOGS>
CustomLog "|/usr/sbin/rotatelogs \
    /tmp/mod_wsgi-localhost:8000:502/application.log.%Y-%m-%d-%H_%M_%S 5M" common
</IfDefine>
<IfDefine !MOD_WSGI_ROTATE_LOGS>
CustomLog "/tmp/mod_wsgi-localhost:8000:502/application.log" common
</IfDefine>
</IfDefine>

с результатомapplication.log являются:

[Fri Jun 10 07:17:30.845264 2016] [mpm_prefork:notice] [pid 84334] AH00163: Apache/2.4.18 (Unix) mod_wsgi/4.5.2 Python/2.7.10 configured -- resuming normal operations
[Fri Jun 10 07:17:30.845518 2016] [core:notice] [pid 84334] AH00094: Command line: 'httpd (mod_wsgi-express)  -f /tmp/mod_wsgi-localhost:8000:502/httpd.conf -D MOD_WSGI_ACCESS_LOG -D FOREGROUND'
::1 - - [10/Jun/2016:07:17:36 +1000] "GET / HTTP/1.1" 200 709
::1 - - [10/Jun/2016:07:17:37 +1000] "GET / HTTP/1.1" 200 709
::1 - - [10/Jun/2016:07:17:37 +1000] "GET / HTTP/1.1" 200 709
::1 - - [10/Jun/2016:07:17:38 +1000] "GET / HTTP/1.1" 200 709
::1 - - [10/Jun/2016:07:17:38 +1000] "GET / HTTP/1.1" 200 709
[Fri Jun 10 07:17:39.784486 2016] [mpm_prefork:notice] [pid 84334] AH00169: caught SIGTERM, shutting down

Таким образом, технически это должно работать для автономной установки Apache, при этом журнал ошибок и доступ к одному и тому же файлу просто устанавливаютсяErrorLog а такжеCustomLog в тот же файл.

Что касается дополнительной регистрации в Django, которая может генерироваться из-за исключительных ситуаций, вам все равно потребуется:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
        },
    },
    'loggers': {
        'django': {
            'handlers': ['cons,ole'],
            'level': os.getenv('DJANGO_LOG_LEVEL', 'INFO'),
        },
    },
}

Это говорит Django, что он должен логически входить в терминал, который mod_wsgi будет перехватывать и отправлять в журнал ошибок Apache, который вместе с вышеперечисленным будет объединенным журналом приложения.

Кстати, если вы хотите запустить Apache / mod_wsgi в контейнере, в котором регистрация должна идти к стандартному выводу, не делайте это самостоятельно. Используйте mod_wsgi-express, так как он специально разработан для использования в контейнерах. В этом случае вы просто используете:

mod_wsgi-express start-server --access-log --log-to-terminal

если вы хотите включить ведение журнала доступа (по умолчанию отключено, как правило, просто шум для развертываний контейнеров), и он будет беспокоиться об отправке на терминал и журналов доступа, и ошибок, чтобы Docker мог их перехватить.

Если вам нужна дополнительная информация или помощь, используйте список рассылки mod_wsgi.

Ваш ответ на вопрос