¿Cómo se registran los errores del servidor en los sitios django?

Question

Por lo tanto, cuando juego con el desarrollo puedo simplemente configurar settings.DEBUG en y si se produce un error puedo verlo muy bien formateado, con buen seguimiento de pila y solicitar información.

Pero el tipo de planta de producción prefiero usar DEBUG=False y visitantes muestran un cierto estándar de error 500 páginas con la información que estoy trabajando en la fijación de este error en este momento;)
Al mismo tiempo, me gustaría tener alguna forma de registrar toda esa información (rastreo de pila e información de solicitud) en un archivo en mi servidor, para poder enviarlo a mi consola y ver cómo se desplazan los errores, enviarme el correo electrónico cada hora o algo así.

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

Answer 1

Bueno, cuando DEBUG = False, Django enviará automáticamente un rastreo completo de cualquier error a cada persona enumerada en la configuración ADMINS, lo que le permite recibir notificaciones casi gratis. Si desea más control de grano fino, se puede escribir, a sumar a la configuración de una clase middleware que define un método llamado process_exception(), que tendrán acceso a la excepción que se planteó:

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

Su process_exception() método puede realizar cualquier tipo de registro que desee: escribir en 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 proceso de solicitud:

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

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

Answer 2

Obviamente James es correcta, pero si quería que entrar excepciones en un almacén de datos, hay algunas soluciones de código abierto ya disponible:

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 será suficiente.

He usado ambos y funcionan bien.

Answer 3

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

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

Answer 4

Django Sentry es un buen camino a seguir, como ya se ha mencionado, pero hay un poco de trabajo involucrado en configurarlo correctamente (como un sitio web separado).Si lo que desea es registrar todo en un archivo de texto simple aquí está la configuración de registro para poner 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 5

ha pasado algún tiempo desde la presentación de código más útil del EMP. Yo sólo ahora se implementa, y mientras retorcía con alguna opción manage.py, para tratar de perseguir a un error, tengo una advertencia de desaprobación en el sentido de que con mi versión actual de Django (1.5.?) Es un filtro require_debug_false ahora 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

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

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