Как вы регистрируете ошибки сервера на сайтах django
Итак, играя с разработкой, я могу просто установить settings.DEBUG
до True
и если возникает ошибка, Я вижу, что она хорошо отформатирована, с хорошей трассировкой стека и информацией запроса.
но на вид производственной площадки я бы предпочел использовать DEBUG=False
и показать посетителям некоторые стандартные ошибки 500 страниц с информацией, что я работаю над исправлением этой ошибки в данный момент;)
В то же время я хотел бы иметь какой-то способ регистрации всей этой информации (трассировки стека и информации запроса) в файл на моем сервере-поэтому я могу просто выводить его на консоль и смотреть, как прокручиваются ошибки, отправлять мне журнал каждый час или что-то вроде этого.
какие решения для ведения журнала вы бы рекомендовали для сайта django, который отвечал бы этим простым требованиям? У меня приложение работает как fcgi
сервер, и я использую веб-сервер apache в качестве интерфейса (хотя думаю о переходе на lighttpd).
6 ответов
Ну, когда DEBUG = False
, Django автоматически отправит полную трассировку любой ошибки каждому человеку, указанному в ADMINS
настройка, которая получает уведомления в значительной степени бесплатно. Если вам нужен более мелкозернистый элемент управления, вы можете написать и добавить в свои настройки класс middleware, который определяет метод с именем process_exception()
, который будет иметь доступ к исключению, которое было поднял:
http://docs.djangoproject.com/en/dev/topics/http/middleware/#process-exception
код process_exception()
метод может выполнять любой тип ведения журнала, который вы хотите: запись в консоль,запись в файл и т. д., п.
Edit: хотя это немного менее полезно, вы также можете прослушать got_request_exception
сигнал, который будет послан, когда возникает исключение во время запроса обработка:
http://docs.djangoproject.com/en/dev/ref/signals/#got-request-exception
Это не дает вам доступ к объекту исключения, однако, поэтому метод промежуточного программного обеспечения намного проще работать.
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
},
},
}
очевидно, Джеймс прав, но если вы хотите регистрировать исключения в хранилище данных, уже доступно несколько решений с открытым исходным кодом:
1) CrashLog-хороший выбор:http://code.google.com/p/django-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')