110π
Well, when DEBUG = False
, Django will automatically mail a full traceback of any error to each person listed in the ADMINS
setting, which gets you notifications pretty much for free. If youβd like more fine-grained control, you can write and add to your settings a middleware class which defines a method named process_exception()
, which will have access to the exception that was raised:
http://docs.djangoproject.com/en/dev/topics/http/middleware/#process-exception
Your process_exception()
method can then perform whatever type of logging youβd like: writing to console, writing to a file, etc., etc.
Edit: though itβs a bit less useful, you can also listen for the got_request_exception
signal, which will be sent whenever an exception is encountered during request processing:
http://docs.djangoproject.com/en/dev/ref/signals/#got-request-exception
This does not give you access to the exception object, however, so the middleware method is much easier to work with.
83π
Django Sentry is a good way to go, as already mentioned, but there is a bit of work involved in setting it up properly (as a separate website). If you just want to log everything to a simple text file hereβs the logging configuration to put in your 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]-Django F() division β How to avoid rounding off
- [Django]-Django substr / substring in templates
- [Django]-How to format time in django-rest-framework's serializer?
- [Django]-Django content-type : how do I get an object?
- [Django]-Django queries β id vs pk
- [Django]-Copy a database column into another in Django
30π
Obviously James is correct, but if you wanted to log exceptions in a datastore, there are a few open source solutions already available:
1) CrashLog is a good choice: http://code.google.com/p/django-crashlog/
2) Db-Log is a good choice as well: http://code.google.com/p/django-db-log/
What is the difference between the two? Almost nothing that I can see, so either one will suffice.
Iβve used both and they work well.
- [Django]-Where's my JSON data in my incoming Django request?
- [Django]-How to tell if a task has already been queued in django-celery?
- [Django]-Django queries β id vs pk
16π
Some time has passed since EMPβs most helpful code submission. I just now implemented it, and while thrashing around with some manage.py option, to try to chase down a bug, I got a deprecation warning to the effect that with my current version of Django (1.5.?) a require_debug_false filter is now needed for the mail_admins handler.
Here is the revised code:
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
},
},
}
- [Django]-How do Django models work?
- [Django]-What is actually assertEquals in Python?
- [Django]-How do you detect a new instance of the model in Django's model.save()
1π
I just had an annoying problem with my fcgi
script. It occurred before django even started. The lack of logging is sooo painful. Anyway, redirecting stderr to a file as the very first thing helped a lot:
#!/home/user/env/bin/python
sys.stderr = open('/home/user/fcgi_errors', 'a')
- [Django]-Convert Django Model object to dict with all of the fields intact
- [Django]-What's the best solution for OpenID with Django?
- [Django]-How to get a favicon to show up in my django app?
0π
You can use the logging library in Python, no need to pip install
anything.
Replace any print()
with logging.debug()
but,
Django Sentry is a good way to go
as EMP said.
- [Django]-Django change default runserver port
- [Django]-Django MEDIA_URL and MEDIA_ROOT
- [Django]-How to assign items inside a Model object with Django?