SENTRY 2.0 (this) IS IN DEVELOPMENT AND SHOULD NOT BE USED IN PRODUCTION
Sentry provides you with a generic interface to view and interact with your error logs. By default, it will record various events to a datastore. With this it allows you to interact and view near real-time information to discover issues and more easily trace them in your application.
(The next chunk is a lie, but planned)
Built-in support includes:
- Drop-in Django support
- WSGI middleware for error logging
- Query logging for psycopg2 and MySQLdb
Issue tracker: http://github.com/dcramer/django-sentry/issues
We'll move all of this into the Sphinx docs once APIs are finalized.
Sentry uses Nose, which will automatically be installed (along with unittest2) if you use
mkvirtualenv sentry python setup.py test
The server component of Sentry, called
sentry.web, can be run with the following command:
mkvirtualenv sentry python setup.py develop sentry start --no-daemon --debug
The client is the core of Sentry, which is composed of the
sentry namespace, and its many
submodules. There are a two key things that make up the client:
These components are also used within
sentry.web as well.
To capture an error, Sentry provides the
from sentry import capture capture('sentry.events.Exception', exc_info=exc_info)
For built-in events, you can drop the module namespace:
from sentry import capture capture('Exception', exc_info=exc_info)
One of the big changes from Sentry 1.x to 2.x, is the ability to record durations (in ms) with events:
from sentry import capture capture('Query', query='SELECT * FROM table', engine='psycopg2', time_spent=36)
The other major change, is that labels like "logger", and "server" are now part of the tagging architecture:
from sentry import capture capture('Message', message='hello world', tags=[('logger', 'root'), ('level', 'error'), ('url', 'http://example.com')])
The filter API is designed to allow dynamic filters based on tags. They are composed of two pieces: a processor and a renderer. The renderer simply tells Sentry how it needs to be displayed in the filter list (e.g. a select widget with FOO choices, a search input, etc).
The majority of this code lies within
sentry.web.filters, and are specified as part of the
SLICES runtime configuration.
This is a rough list of features/APIs which need to be completed (this is better described in the issue tracker):
- Runtime validation of settings (ensure events and filters are valid importables, etc.)
- Filter API
- Plugin API
- Custom Views (still using the old "render everything" logic from Sentry 1.x) * Partially done -- we need to deal with non-magical indexes (e.g. explicit, only index this)
- Dashboard View
- Django Integration (some draft code is present)
- SQLAlchemy Backend
- Full test coverage should exist for Models and Backends
- Deal with expiration (since we use sorted sets in Redis, we cant just expires on keys)
- Create a background process which gets launched in addition to the web process * Should handle tasks like "expire message" * Could handle all API requests?