Не удается получить доступ к журналу для работы с оружием

Я бегу за ружьем позади ngninx. Я хочу зарегистрировать ошибки в gunicorn для gunicorn-error.log и получить доступ к журналу gunicorn-access.log.

У меня работает ошибка, но не журнал доступа, что я делаю неправильно?

Это мой gunicorn.conf.py:

bind = '127.0.0.1:8888'
backlog = 2048
workers = 3
errorlog = '/home/my/logs/gunicorn-error.log'
accesslog = '/home/my/logs/gunicorn-access.log'
loglevel = 'debug'
proc_name = 'gunicorn-my'
pidfile = '/var/run/my.pid'

Это script для запуска gunicorn:

#!/bin/bash
set -e
ENV=/home/my/env/bin/activate
GUNICORN=gunicorn_django
SETTINGS_PATH=/home/my/app/app/settings
PROJECT_PATH=/home/my/app
CONFROOT=/home/my/app/conf/gunicorn.conf.py

cd $SETTINGS_PATH
source $ENV
export PYTHONPATH=$PROJECT_PATH
exec $GUNICORN app.settings.staging -c $CONFROOT

Он создает как gunicorn-error.log, так и gunicorn-access.log, но только gunicorn-error.log получает любые журналы, например:

2012-11-20 11:49:57 [27817] [INFO] Starting gunicorn 0.14.6
2012-11-20 11:49:57 [27817] [DEBUG] Arbiter booted
2012-11-20 11:49:57 [27817] [INFO] Listening at: http://127.0.0.1:8888 (27817)
2012-11-20 11:49:57 [27817] [INFO] Using worker: sync
2012-11-20 11:49:58 [27825] [INFO] Booting worker with pid: 27825
2012-11-20 11:49:58 [27828] [INFO] Booting worker with pid: 27828
2012-11-20 11:49:58 [27830] [INFO] Booting worker with pid: 27830

Что я делаю неправильно? Кто-нибудь хочет поделиться своими рабочими gunicorn.conf.py с журналами ошибок и журналами доступа?

Ответ 1

Я изменил мою конфигурацию ведения журнала в Django на следующую и помог:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': True,
    'root': {
        'level': 'WARNING',
        'handlers': ['sentry'],
    },
    'formatters': {
        'verbose': {
            'format': '%(levelname)s %(asctime)s %(module)s %(process)d %(thread)d %(message)s'
        },
        'generic': {
            'format': '%(asctime)s [%(process)d] [%(levelname)s] %(message)s',
            'datefmt': '%Y-%m-%d %H:%M:%S',
            '()': 'logging.Formatter',
        },
    },
    'handlers': {
        'sentry': {
            'level': 'ERROR',
            'class': 'raven.contrib.django.handlers.SentryHandler',
        },
        'console': {
            'level': 'DEBUG',
            'class': 'logging.StreamHandler',
            'formatter': 'verbose'
        },
        'error_file': {
            'class': 'logging.FileHandler',
            'formatter': 'generic',
            'filename': '/home/fungine/gunicorn.error.log',
        },
        'access_file': {
            'class': 'logging.FileHandler',
            'formatter': 'generic',
            'filename': '/home/fungine/gunicorn.access.log',
        },
    },
    'loggers': {
        'django.db.backends': {
            'level': 'ERROR',
            'handlers': ['console'],
            'propagate': False,
        },
        'raven': {
            'level': 'DEBUG',
            'handlers': ['console'],
            'propagate': False,
        },
        'sentry.errors': {
            'level': 'DEBUG',
            'handlers': ['console'],
            'propagate': False,
        },
        'gunicorn.error': {
            'level': 'INFO',
            'handlers': ['error_file'],
            'propagate': True,
        },
        'gunicorn.access': {
            'level': 'INFO',
            'handlers': ['access_file'],
            'propagate': False,
        },
    },
}

Ответ 2

Задание 'disable_existing_loggers': False в logging.config.dictConfig работает для меня.

disable_existing_loggers. Если указано как False, регистраторы, которые существуют при выполнении этого вызова, остаются в силе. По умолчанию используется Trueпотому что это позволяет старое поведение обратно совместимым способом. Эта поведение заключается в отключении любых существующих регистраторов, если они или их предки явно указаны в конфигурации ведения журнала.

http://docs.python.org/2/library/logging.config.html#logging.config.fileConfig