**This article refers to outdated and deprecated technology**
Sentry catches any exception that your django project raises, and stores it in your database for future reference – much like its previous name describes.
It already provides robust documentation:
http://readthedocs.org/docs/sentry/en/v1.6.2/
However, with error logging such an integral part of producing a working site, Sentry provides much more sophistication than merely ‘logging to a database.’
As the original authors put it:
http://blog.disqus.com/post/1178923988/django-sentry
Cramer and company took it one step further by allowing grouping and ordering of records, and also allowing administration. Grouping and ordering errors is great stuff, but the clincher is that by following the Django Admin style, a format already familiar to Django users, Sentry makes itself accessible to the general populace.
Sentry also is able to handle multiple servers out of the box, with just some configuration needed.
On Configuration:
http://readthedocs.org/docs/sentry/en/v1.6.2/config.html
A simple <pip install django-sentry> gets you going with sentry. It already installs dependencies, and it doesn’t need any additional files that couldn’t be retrieved via pip. As per usual, Sentry needs to be put in Installed Apps (in addition to its dependencies). Sentry also needs to be put in the urls.
The documentation notes that in order to get template debug information, the user(developer) must set <TEMPLATE_DEBUG = True>.
Another caveat involves environments with DEBUG = True.In this case, the developer must set the setting SENTRY_TESTING = True in order to verify that Sentry is indeed operational (Sentry would otherwise not work because of django’s debug handling when DEBUG = True.)