Как вы регистрируете ошибки сервера на сайтах 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
        },
    },
}

django-db-log, упомянутый в другом ответе, был заменен на:

https://github.com/dcramer/django-sentry


очевидно, Джеймс прав, но если вы хотите регистрировать исключения в хранилище данных, уже доступно несколько решений с открытым исходным кодом:

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')