Различное поведение модуля регистрации Python при использовании mod_python - PullRequest
Новая
       6

Различное поведение модуля регистрации Python при использовании mod_python

1 голос
/ 28 мая 2009

У нас есть неприятная проблема, когда мы видим, что модуль ведения журнала python ведет себя по-разному при работе с mod_python на наших серверах. При выполнении того же кода в оболочке, или в django с помощью команды runserver или с mod_wsgi, поведение корректно: 

import logging
logger = logging.getLogger('site-errors')
logging.debug('logger=%s' % (logger.__dict__))
logging.debug('logger.parent=%s' % (logger.parent.__dict__))
logger.error('some message that is not logged.')

Мы тогда следующие записи:

2009-05-28 10: 36: 43 740, DEBUG, error_middleware.py: 31, [logger = {'name': 'site-errors', 'parent': , ' обработчики »: [],« уровень »: 0,« отключено »: 0,« менеджер »: ,« распространять »: 1,« фильтры »: []}]

2009-05-28 10: 36: 43 740, DEBUG, error_middleware.py: 32, [logger.parent = {'name': «root», «parent»: нет, «handlers»: [ ], 'level': 10, «отключен»: 0, «распространять»: 1, 'filters': []}]

Как видно, для дочернего регистратора 'site-errors' не установлены обработчики или уровень.

Настройка регистрации производится в settings.py:

MONITOR_LOGGING_CONFIG = ROOT + 'error_monitor_logging.conf'

import logging
import logging.config

logging.config.fileConfig(MONITOR_LOGGING_CONFIG)

if CONFIG == CONFIG_DEV:
   DB_LOGLEVEL = logging.INFO
else:
   DB_LOGLEVEL = logging.WARNING

Вторая проблема заключается в том, что мы также добавляем в __init__.py собственный обработчик, который находится в папке как error_middleware.py:

. 
import logging
from django.conf import settings
from db_log_handler import DBLogHandler

handler = DBLogHandler()
handler.setLevel(settings.DB_LOGLEVEL)
logging.root.addHandler(handler)

Пользовательский обработчик не отображается в журнале!

Если кто-то знает, в чем проблема, пожалуйста, сообщите нам! Не стесняйтесь просить дополнительную информацию. Это, безусловно, поможет решить проблему.

Ответы [ 3 ]

5 голосов
/ 28 мая 2009

Может быть лучше, если вы не настроите вход в систему settings.py.

Мы настраиваем вашу регистрацию в нашем корне urls.py. Кажется, это работает лучше. Я не прочитал достаточно источников Django, чтобы понять, почему это лучше, но у нас это хорошо получается. Я бы добавил здесь и собственные обработчики.

Кроме того, присмотритесь к mod_wsgi . Кажется, он ведет себя намного лучше, чем mod_python.

0 голосов
/ 07 июня 2009

Похоже, вы не разместили всю необходимую информацию - например, где находится файл конфигурации вашего журнала?

Вы говорите, что:

При выполнении того же кода в shell, или в django с сервером запуска команда или с mod_wsgi, поведение правильно

Вы не ясно, является ли вывод журнала, который вы показали, из одной из этих сред, или из запуска mod_python. Это не выглядит неправильно - в своем коде вы добавили обработчики в корень, а не в logger 'site-errors'. Вы также устанавливаете уровень для обработчика, а не для регистратора - так что вы не ожидаете увидеть уровень, установленный для регистратора 'site-errors', в выводе журнала, не так ли? Уровни могут быть установлены как в регистраторах, так и в обработчиках, и они не одинаковы, хотя они отфильтровывают события одинаковым образом.

Проблема с пользовательскими обработчиками легко объяснима, если вы посмотрите документацию регистрации для конфигурации, см.

http://docs.python.org/library/logging.html (поиск "указывается в записи класса")

Это объясняет, что любой класс обработчика, описанный в файле конфигурации, является eval () d в пространстве имен пакетов журналирования. Таким образом, связывая logging.custhandlers с вашим модулем пользовательских обработчиков, а затем указав «custhandlers.MyCustomClass» в файле конфигурации, eval () дает ожидаемый результат. С таким же успехом вы могли бы сделать

logging.sitemonitoring = мониторинг сайта

и указал класс обработчика как

sitemonitoring.db_log_handler.DBLogHandler

, который будет работать так же хорошо (если подпакет db_log_handler уже был импортирован).

Кстати, причина, по которой у людей иногда возникают проблемы с настройкой входа в файл settings.py, связана с магией импорта Django, вызывающей проблемы кругового импорта. Я обычно настраиваю регистрацию в settings.py, и она работает нормально, если вы не хотите импортировать определенные биты Django (например, в django.db - поскольку логика импорта приложения находится в django.db, вы можете столкнуться с проблемами кругового импорта, если попытаетесь импортировать django.db.x в settings.py).

0 голосов
/ 02 июня 2009

Проблема не решается с помощью mod_wsgi.

Я мог бы решить проблему, поместив полную конфигурацию в один файл. Смешивание конфигурации файла и кода, кажется, создает проблемы с Apache (будь то с использованием mod_wsgi или mod_python).

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

import logging
import logging.config
logging.custhandlers = sitemonitoring.db_log_handler
logging.config.fileConfig(settings.MONITORING_FILE_CONFIG)

Из файла settings.py я не могу импортировать sitemonitoring.db_log_handler, поэтому мне нужно поместить этот код в корень urls.py.

В файле конфигурации я ссылаюсь на DBLogHandler со следующим утверждением 

[handler_db]
class=custhandlers.DBLogHandler()
level=ERROR
args=(,)

PS: обратите внимание, что атрибут custhandler создается динамически и может иметь другое имя. Это преимущество использования динамического языка.

...