bouke / django-airbrake Goto Github PK

Django Airbrake provides a logging handler to push exceptions and other errors to airbrakeapp or other airbrake-compatible exception handler services (e.g. aTech Media's Codebase).

Home Page: https://pypi.python.org/pypi/django-airbrake

License: Other

Makefile 2.32% Python 97.68%

django logging airbrake codebasehq

django-airbrake's Introduction

Django Airbrake

Django Airbrake provides a logging handler to push exceptions and other errors to airbrakeapp or other airbrake-compatible exception handler services (e.g. aTech Media's Codebase).

Compatible with all supported Django (LTS) versions. At the moment of writing that's including 1.11 and 2.0 on Python 2.7(only django1.11), 3.4, 3.5 and 3.6.

Installation

Installation with pip:

$ pip install django-airbrake

Add 'airbrake.handlers.AirbrakeHandler' as a logging handler:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse'
        }
    },
    'handlers': {
        'airbrake': {
            'level': 'WARNING',
            'class': 'airbrake.handlers.AirbrakeHandler',
            'filters': ['require_debug_false'],
            'api_key': '[your-api-key]',
            'env_name': 'develop',
        }
    },
    'loggers': {
        'django.request': {
            'handlers': ['airbrake'],
            'level': 'WARNING',
            'propagate': True,
        },
    }
}

Settings

level (built-in setting) Change the level to 'ERROR' to disable logging of 404 error messages.

api_key (required): API key provided by the exception handler system.
env_name (required): Name of the environment (e.g. production, develop, testing)
api_url: To use aTech Media's Codebase exception system, provide an extra setting api_url with the value 'https://exceptions.codebasehq.com/notifier_api/v2/notices'.
env_variables: List of environment variables that should be included in the error message, defaults to ['DJANGO_SETTINGS_MODULE'].
meta_variables: List of request.META variables that should be included in the error message, defaults to ['HTTP_USER_AGENT', 'HTTP_COOKIE', 'REMOTE_ADDR', 'SERVER_NAME', 'SERVER_SOFTWARE'].
timeout: Timeout in seconds to send the error report, defaults to 30 seconds.

Contributing

Fork the repository on GitHub and start hacking.
Run the tests.
Send a pull request with your changes.

Releasing

The following actions are required to push a new version:

bumpversion [major|minor|patch]
python setup.py sdist bdist_wheel upload
git push && git push --tags

django-airbrake's People

Contributors

Stargazers

Watchers

Forkers

ericbuckley perkville georgethomasuk cimani kozmagabor oliciv bounder utsdanielosborne fastref

django-airbrake's Issues

Log notifier exceptions

Currently exceptions when notifying are print to stderr print >>sys.stderr. However, these messages might get lost in heaps of other log messages. I'd like to log these messages, allowing Django's mail_admins handler to process those messages as a last resort. However caution is required as it could lead to log recursion (A > B > A > B etc).

Set logger name as component when no request

Currently, the component value is set to the controller's class name, if a match could be made. However, for non-request errors, there is no controller. It would be helpful if something like the logger's name (e.g. myapp.tasks).

Limited Backtrace

First off I wanted to say kudos for putting this package together. Made my life so much easier :) I am only noticing one issue with the backtrace when I switch to this handler.

Using django-airbrake, I get only the last file in backtrace. Whereas if I switch to the old exceptional handler I see the full backtrace for a similar error. Is this a limitation in airbrake or something that could be addressed in this handler?

Here is what I see in exceptional (using exceptional handler):

campaign.views.external#serve_module (django.http.Http404) "SentimentHubModule matching query does not exist."

File "/home/ubuntu/webapps/vg/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 111, in get_response
response = callback(request, _callback_args, *_callback_kwargs)
File "/home/ubuntu/webapps/vg/local/lib/python2.7/site-packages/django/views/decorators/cache.py", line 75, in _cache_controlled
response = viewfunc(request, _args, *_kw)
File "/home/ubuntu/webapps/vg/local/lib/python2.7/site-packages/django/utils/decorators.py", line 91, in _wrapped_view
response = view_func(request, _args, *_kwargs)
File "/home/ubuntu/webapps/vg/src/vg/vg_django/apps/campaign/views/external.py", line 697, in serve_module
module = module_class.find_by_serve_id_or_404(serve_id)
File "/home/ubuntu/webapps/vg/src/vg/vg_django/apps/common/models.py", line 215, in find_by_serve_id_or_404
raise Http404(*err.args)

In airbrake (using django-airbrake) I see only 1 line:

/Users/cimani/work/vg/lib/python2.7/site-packages/django/core/handlers/base.py:142 in "get_response"

Validate generated XML according to airbrake XSD in unittest

See xsd: http://airbrake.io/airbrake_2_3.xsd

1.1.1 release to support Django 1.9

If this project is still maintained would it be possible to make a 1.1.1 PyPi release that includes 171966e?

This commit includes a replacement of request.REQUEST with request.POST.

Django 1.9 removes request.REQUEST. The result is that exception logging fails when the application runs into a 500 error:

  File "/.../site-packages/airbrake/handlers.py", line 78, in _generate_xml
    for key, value in request.REQUEST.items():
AttributeError: 'WSGIRequest' object has no attribute 'REQUEST'

In my case this was causing an Internal Server Error message from nginx and no admin 500 error to be logged for the underlying 500 error. (I had to enable gunicorn logging in my logging config to see the above stacktrace and realise django-airbrake was the reason. I then disabled django-airbrake to see the underlying 500 error).

I don't know if the the current master django-airbrake is fully compatible with Django 1.9, or if you intend to officially support Django > 1.6 but a PyPi release would be a useful nonetheless. At the moment I'd have to stop using it or fork it for Django 1.9 projects.

Cheers.

Generating error key/var could result in UnicodeEncodeError

/home/frontend/local/lib/python2.7/site-packages/gunicorn/workers/sync.py:126:in `handle_request: respiter = self.wsgi(environ, resp.start_response)'
/home/frontend/local/lib/python2.7/site-packages/django/core/handlers/wsgi.py:241:in `__call__: response = self.get_response(request)'
/home/frontend/local/lib/python2.7/site-packages/django/core/handlers/base.py:179:in `get_response: response = self.handle_uncaught_exception(request, resolver, sys.exc_info())'
/home/frontend/local/lib/python2.7/site-packages/django/core/handlers/base.py:215:in `handle_uncaught_exception: 'request': request'
/usr/lib/python2.7/logging/__init__.py:1158:in `error: self._log(ERROR, msg, args, **kwargs)'
/usr/lib/python2.7/logging/__init__.py:1250:in `_log: self.handle(record)'
/usr/lib/python2.7/logging/__init__.py:1260:in `handle: self.callHandlers(record)'
/usr/lib/python2.7/logging/__init__.py:1300:in `callHandlers: hdlr.handle(record)'
/usr/lib/python2.7/logging/__init__.py:744:in `handle: self.emit(record)'
/home/frontend/local/lib/python2.7/site-packages/airbrake/handlers.py:35:in `emit: self._sendMessage(self._generate_xml(record))'
/home/frontend/local/lib/python2.7/site-packages/airbrake/handlers.py:74:in `_generate_xml: SubElement(params, 'var', dict(key=key)).text = str(value)'

Error handling request: 'ascii' codec can't encode character u'\u201c' in position 466: ordinal not in range(128)