Debugging Django in Production Environments

« Should reusable apps have templates? | A start to the uber community »

Nick had a nice post about setting DEBUG based on the hostname of the server that you're site is running on. This allows you to set DEBUG to True for your staging site, and False for your production site.

I do something along those lines, but a little bit differently. I can't take credit for this idea, because it came from this snippet. It is a really neat trick, that I have expanded on a little bit.

from django.views.debug import technical_500_response
import sys
from django.conf import settings

class UserBasedExceptionMiddleware(object):
    def process_exception(self, request, exception):
        if request.user.is_superuser or request.META.get('REMOTE_ADDR') in settings.INTERNAL_IPS:
            return technical_500_response(request, *sys.exc_info())

Now simply save this in a file somewhere. Add it to your MIDDLEWARE_CLASSES, and you are good to go. For example, mine looks like:

    'tools.middleware.superuser.UserBasedExceptionMiddleware',

This is a pretty simple middleware that is crazy useful. When you throw this inside of your site, it will give you a normal Django error page if you're a superuser, or if your IP is in INTERNAL_IPS.

This makes it really nice, because you can get an error message on your production servers, where your normal users get your normal pretty 500 pages. This makes debugging things that are showing up in production, but won't be reproduced on the staging server possible. Caching behavior is a big one that I know isn't tested when you are using DEBUG = True. This lets you keep DEBUG = False on, but gives you some nice error pages.

Hope this tip is useful.

Comments

1 Eric Florenzano says...

That is so freaking cool!

Posted at 8 a.m. on November 16, 2008

2 makitek says...

:-) so nice ... thanks!

Posted at 11:59 a.m. on November 16, 2008

3 Nick Sergeant says...

Wow, this is great! Now we can be even lazier :)

Nick

Posted at 1:51 p.m. on November 16, 2008

4 Srdjan Popovic says...

Excellent. Many thanks.

Posted at 1:56 p.m. on November 16, 2008

5 Eric Moritz says...

I'm a pdb junkie. I just log into the prod server, use the django.test.client to execute the code.

Once you know the line number of the error, you can set a break point and then call the URL via django.test.client.

Posted at 4:25 p.m. on November 16, 2008

6 barbara says...

whoa, excellent idea - thank you!

Posted at 4:26 p.m. on November 16, 2008

7 Robert Lofthouse says...

Nice tip, Eric.

Like Eric Moritz though i'm a pdb junkie. Also, in my live environments I tend to have a "dead" box these days which replicates the other boxes (in the cluster). If anything goes wrong, I conduct my testing on that. If it's a case of load, it's still fairly easy to replicate the issue.

I also like to keep the amount of middleware down ;)

Nonetheless, quite cool :)

Posted at 8:22 p.m. on November 16, 2008

8 Eric Moritz says...

Inspired by this entry, I made a quick write up on how to use django.test.client to debug production code:

http://eric.themoritzfamily.com/2008/11/17/pdb-and-django...

Posted at 12:21 a.m. on November 17, 2008

9 Antonio Melé says...

Great middleware! Thank you!

Posted at 5:15 p.m. on December 12, 2008

Comments support markdown

Comments are closed.

Comments have been close for this post.

About this post

Posted at 8:27 p.m. on November 15, 2008

Comments: 9

Tags: debugging , django , middleware , post-a-day , production

Surfing in Kansas