python - log - ¿Cómo se registran los errores del servidor en los sitios de django?
logging in django project (6)
Por lo tanto, al jugar con el desarrollo, puedo simplemente configurar los settings.DEBUG de. EN MARCHA en True y si ocurre un error, puedo verlo muy bien formateado, con un buen seguimiento de la pila y la información solicitada.
Pero en el tipo de sitio de producción preferiría usar DEBUG=False y mostrar a los visitantes un error estándar de la página 500 con información de 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 (rastreo de pila e información de solicitud) en un archivo en mi servidor, para poder enviarlo a mi consola y ver los errores desplazarse, enviarme el registro por correo electrónico. cada hora o algo como esto.
¿Qué soluciones de registro recomendaría para un django-site, que cumpliría esos requisitos simples? Tengo la aplicación ejecutándose como servidor fcgi y estoy usando el servidor web apache como frontend (aunque pensando en ir a lighttpd).
Acabo de tener un problema molesto con mi script fcgi . Ocurrió antes de que django incluso comenzara. La falta de registro es muy dolorosa. De todos modos, redireccionar stderr a un archivo como lo primero lo ayudó mucho:
#!/home/user/env/bin/python
sys.stderr = open(''/home/user/fcgi_errors'', ''a'')
Bueno, cuando DEBUG = False , Django enviará automáticamente un rastreo completo de cualquier error a cada persona incluida en la configuración de ADMINS , lo que hace que las notificaciones sean prácticamente gratuitas. Si desea un control más detallado, puede escribir y agregar a su configuración una clase de middleware que define 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 process_exception() puede realizar el tipo de registro que desee: escribir en la consola, escribir en un archivo, etc., etc.
Editar: aunque es un poco menos útil, también puedes 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
Sin embargo, 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.
Django Sentry es un buen camino a seguir, como ya se mencionó, pero hay un poco de trabajo involucrado en configurarlo correctamente (como un sitio web separado). Si solo desea 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
},
},
}
Ha pasado algún tiempo desde la presentación del código más útil de EMP. Acabo de implementarlo, y mientras forcejeo con alguna opción manage.py, para intentar buscar un error, recibí una advertencia de desaprobación de que con mi versión actual de Django (1.5.?) Un filtro require_debug_false es 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
},
},
}
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 será suficiente.
He usado ambos y funcionan bien.
django-db-log, mencionado en otra respuesta, ha sido reemplazado por: