Cómo registrar errores de servidor en sitios django

Question

Entonces, cuando juego con el desarrollo, puedo establecer settings.DEBUG en True y si ocurre un error puedo verlo bien formateado, con un buen seguimiento de la pila y solicitar información.

Pero en el tipo de sitio de producción, prefiero usar DEBUG = False y mostrar a los visitantes un error estándar de 500 páginas con información en la que estoy trabajando para solucionar este error en este momento;)
Al mismo tiempo, me gustaría tener alguna forma de registrar toda esa información (seguimiento de la pila y la información de la solicitud) en un archivo de mi servidor, por lo que puedo enviarla a mi consola y ver cómo se desplazan los errores. Cada hora o algo así.

¿Qué soluciones de registro recomendaría para un sitio django, que cumpla con esos requisitos simples? Tengo la aplicación ejecutándose como servidor fcgi y estoy usando el servidor web apache como interfaz (aunque estoy pensando en ir a lighttpd).

Answer 1

Bueno, cuando DEBUG = False , Django enviará automáticamente un registro completo de cualquier error a cada persona que figura en la configuración de ADMINS , lo que le brinda notificaciones bastante por gratis. Si desea un control más preciso, puede escribir y agregar a su configuración una clase de middleware que defina un método llamado process_exception () , que tendrá acceso a la excepción que se generó:

http://docs.djangoproject.com/en / dev / topics / http / middleware / # process-exception

El método

Su process_exception () puede realizar cualquier tipo de registro que desee: escribir en la consola, escribir en un archivo, etc., etc.

Editar: aunque es un poco menos útil, también puede escuchar la señal got_request_exception , que se enviará cada vez que se encuentre una excepción durante el procesamiento de la solicitud:

http://docs.djangoproject.com/en / dev / ref / signs / # got-request-exception

Esto no le da acceso al objeto de excepción, por lo que es mucho más fácil trabajar con el método de middleware.

Answer 2

Django Sentry es una buena manera de proceder, como ya se mencionó, pero hay un poco de trabajo involucrado en su configuración (como un sitio web separado). Si solo desea registrar todo en un archivo de texto simple, aquí está la configuración de registro que debe colocar en su 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
        },
    },
}

Answer 3

django-db-log, mencionado en otra respuesta, se ha reemplazado por:

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

Answer 4

Obviamente, James tiene razón, pero si desea registrar excepciones en un almacén de datos, hay algunas soluciones de código abierto disponibles:

1) CrashLog es una buena opción: http://code.google.com/ p / django-crashlog /

2) Db-Log también es una buena opción: http: // code.google.com/p/django-db-log/

¿Cuál es la diferencia entre los dos? Casi nada de lo que puedo ver, por lo que cualquiera de los dos será suficiente.

He usado ambos y funcionan bien.

Answer 5

Ha pasado algún tiempo desde el envío de código más útil de EMP. Acabo de implementarlo, y mientras revuelo con alguna opción de manage.py, para tratar de perseguir un error, recibí una advertencia de desaprobación de que con mi versión actual de Django (1.5.?) Ahora es un filtro require_debug_false necesario para el controlador mail_admins.

Aquí está el código revisado:

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
        },
    },
}

Answer 6

Acabo de tener un problema molesto con mi script fcgi . Ocurrió incluso antes de que django comenzara. La falta de registro es muy dolorosa. De todos modos, redirigir stderr a un archivo como la primera cosa ayudó mucho:

#!/home/user/env/bin/python
sys.stderr = open('/home/user/fcgi_errors', 'a')