Request reporting for django + raven + standard exceptions

203 views
Skip to first unread message

Alan Ray

unread,
May 22, 2013, 12:17:43 PM5/22/13
to gets...@googlegroups.com
I recently updated a project to Django 1.5, Raven 3.3, and Sentry 5.X. By and large, the upgrade went smoothly, but I notice that for many exceptions, a request is not being reported. (I'm not certain whether this is related to the upgrade, or to different types of exceptions being encountered.)

As far as I can tell, the problem is with raven.events.Exception:capture().
The django exception hook calls through Raven exception hook with the request as a kwarg, and it is passed through the functions until raven.base:build_msg. There, build_msg calls handler.capture(**kwargs), and handler is of type raven.events.Exception.

But the capture method of raven.events.Exception doesn't do anything with kwargs, so the request object is summarily left at the side of the road. Is this intended, or am I missing some obvious setup/configuration detail? I'd really like to know the request that triggered non-Django errors, and this seems like pretty basic functionality for a Django app. I know I can monkey patch the capture method, but I'd prefer to do it right.

(I have looked at the updates from 3.3 to 3.7, but nothing seems to address this problem.)

Thanks,
Alan

David Cramer

unread,
May 22, 2013, 1:20:00 PM5/22/13
to gets...@googlegroups.com, gets...@googlegroups.com
Can you give an example of the code you're using to capture the error?
--
You received this message because you are subscribed to the Google Groups "sentry" group.
To unsubscribe from this group and stop receiving emails from it, send an email to getsentry+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Alan Ray

unread,
May 22, 2013, 2:20:59 PM5/22/13
to gets...@googlegroups.com
I followed the instructions for configuring Django:

In settings/base.py

INSTALLED_APPS = (
    'raven.contrib.django.raven_compat',
...
)

I added in the middleware for Raven (it seemed to help get the request passed into the Raven code):
MIDDLEWARE_CLASSES = (
'raven.contrib.django.middleware.SentryLogMiddleware',
...
)

RAVEN_CONFIG = {
'dsn' : '...'
}

LOGGING = {
<giant dictionary of handlers from file>
}

Then to create the exception, I call curl on my site:
curl http://<site>/<path>

The Django code creates a '
ValueError: too many values to unpack' exception, which is logged to my sentry server, but without the request information.

Thanks for the help,
Alan

David Cramer

unread,
May 22, 2013, 2:26:49 PM5/22/13
to gets...@googlegroups.com
I can't quite see how it wouldn't get the request.

To help with your understanding, the path it follows is like this:

Django:SentryHandler->_emit()
SentryHandler->emit(**kwargs)  # includes request at this point
Django:Client->capture(**kwargs)

So it should be getting the request object in the django client's capture method, which is where it extracts the HTTP information.

I'm going to slightly clean this up so the client itself always tries to use the thread local in the middleware (instead of the logging handler),
though I still don't know how you'd be missing the data (unless there's an error parsing it).

Alan Ray

unread,
May 22, 2013, 3:49:15 PM5/22/13
to gets...@googlegroups.com
Thanks for clarifying -- I traced it back to the fact that it was bailing early in contrib.django:get_data_from_request due to a suspicious operation exception. I see that's been updated in raven 3.3.7, and updating looks like it fixes the problem. Thanks again for the pointers -- that was immensely helpful. (It looks like I missed a couple functions in my initial search through the code.)

Alan
Reply all
Reply to author
Forward
0 new messages