Как вы регистрируете ошибки сервера на сайтах Django
-
04-07-2019 - |
Вопрос
Итак, играя с разработкой, я могу просто установить для settings.DEBUG
значение True
и, если произойдет ошибка, я могу увидеть, что она хорошо отформатирована, с хорошей трассировкой стека и запросить информацию.
Но на рабочем сайте я бы предпочел использовать DEBUG = False
и показывать посетителям стандартную страницу ошибки 500 с информацией, над которой я сейчас работаю над исправлением этой ошибки;)
В то же время я хотел бы иметь какой-либо способ записи всей этой информации (трассировки стека и информации о запросах) в файл на моем сервере - так что я могу просто вывести ее на консоль и посмотреть прокрутку ошибок, отправить мне журнал по электронной почте каждый час или что-то в этом роде.
Какие решения для ведения журналов вы бы порекомендовали для django-сайта, которые отвечали бы этим простым требованиям? У меня есть приложение, работающее как сервер fcgi
, и я использую веб-сервер apache в качестве внешнего интерфейса (хотя собираюсь перейти на lighttpd).
Решение
Что ж, когда DEBUG = False
, Django автоматически отправит полный отчет об отслеживании любой ошибки каждому человеку, указанному в настройке ADMINS
, что в значительной степени позволяет получать уведомления для свободно. Если вы хотите более детальный контроль, вы можете написать и добавить в свои настройки класс промежуточного программного обеспечения, который определяет метод с именем process_exception ()
, который будет иметь доступ к возникшему исключению: р>
http://docs.djangoproject.com/en / DEV / темы / HTTP / промежуточный / # процесс-исключение
Ваш метод process_exception ()
может затем выполнять запись любого типа: запись в консоль, запись в файл и т. д. и т. д.
Редактировать: хотя это немного менее полезно, вы также можете прослушивать сигнал got_request_exception
, который будет отправляться всякий раз, когда во время обработки запроса возникает исключение:
http://docs.djangoproject.com/en / DEV / исх / сигналы / # получил-запрос-исключение р>
Это не , однако, дает вам доступ к объекту исключения, поэтому с методом промежуточного программного обеспечения работать намного проще.
Другие советы
Django Sentry - это хороший путь, как уже упоминалось, но есть немало работы, чтобы правильно настроить его (как отдельный сайт). Если вы просто хотите записать все в простой текстовый файл, вот конфигурация ведения журнала, которую нужно поместить в ваш settings.py
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
# Include the default Django email handler for errors
# This is what you'd get without configuring logging at all.
'mail_admins': {
'class': 'django.utils.log.AdminEmailHandler',
'level': 'ERROR',
# But the emails are plain text by default - HTML is nicer
'include_html': True,
},
# Log to a text file that can be rotated by logrotate
'logfile': {
'class': 'logging.handlers.WatchedFileHandler',
'filename': '/var/log/django/myapp.log'
},
},
'loggers': {
# Again, default Django configuration to email unhandled exceptions
'django.request': {
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': True,
},
# Might as well log any errors anywhere else in Django
'django': {
'handlers': ['logfile'],
'level': 'ERROR',
'propagate': False,
},
# Your own app - this assumes all your logger names start with "myapp."
'myapp': {
'handlers': ['logfile'],
'level': 'WARNING', # Or maybe INFO or DEBUG
'propagate': False
},
},
}
django-db-log, упомянутый в другом ответе, был заменен на:
Очевидно, Джеймс прав, но если вы хотите регистрировать исключения в хранилище данных, есть несколько доступных решений с открытым исходным кодом:
1) CrashLog - хороший выбор: http://code.google.com/ р / Джанго-crashlog / р>
2) Db-Log также является хорошим выбором: http: // code.google.com/p/django-db-log/ р>
В чем разница между двумя? Почти ничего, что я вижу, так что либо одного будет достаточно.
Я использовал оба, и они хорошо работают.
Прошло некоторое время с момента предоставления наиболее полезного кода EMP. Я только сейчас реализовал это, и, побеждая с некоторым параметром manage.py, чтобы попытаться отследить ошибку, я получил предупреждение об устаревании о том, что с моей текущей версией Django (1.5.?) Фильтр require_debug_false теперь необходим для обработчика mail_admins.
Вот пересмотренный код:
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'filters': {
'require_debug_false': {
'()': 'django.utils.log.RequireDebugFalse'
}
},
'handlers': {
# Include the default Django email handler for errors
# This is what you'd get without configuring logging at all.
'mail_admins': {
'class': 'django.utils.log.AdminEmailHandler',
'level': 'ERROR',
'filters': ['require_debug_false'],
# But the emails are plain text by default - HTML is nicer
'include_html': True,
},
# Log to a text file that can be rotated by logrotate
'logfile': {
'class': 'logging.handlers.WatchedFileHandler',
'filename': '/home/username/public_html/djangoprojectname/logfilename.log'
},
},
'loggers': {
# Again, default Django configuration to email unhandled exceptions
'django.request': {
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': True,
},
# Might as well log any errors anywhere else in Django
'django': {
'handlers': ['logfile'],
'level': 'ERROR',
'propagate': False,
},
# Your own app - this assumes all your logger names start with "myapp."
'myapp': {
'handlers': ['logfile'],
'level': 'DEBUG', # Or maybe INFO or WARNING
'propagate': False
},
},
}
У меня только что возникла досадная проблема с моим сценарием fcgi
. Это произошло еще до того, как Джанго начал. Отсутствие лесозаготовок ооочень больно. В любом случае, перенаправление stderr в файл, как первое, очень помогло:
#!/home/user/env/bin/python
sys.stderr = open('/home/user/fcgi_errors', 'a')