Over a million developers have joined DZone.

Django/NewRelic Quickstart (gunicorn.d + Django 1.3 hack)

DZone's Guide to

Django/NewRelic Quickstart (gunicorn.d + Django 1.3 hack)

Chase Seibert

May. 29, 12 · Web Dev Zone ·

Free Resource

Like (0)

Comment (0)

Save

{{ articles[0].views | formatCount}} Views

Learn how error monitoring with Sentry closes the gap between the product team and your customers. With Sentry, you can focus on what you do best: building and scaling software that makes your users’ lives better.

New Relic is an excellent web application performance reporting tool. After a great experience using it on Heroku, I went to enable it for an existing self-hosted application. While Django 1.4 has an excellent WSGI configuration build-in, Django 1.3 makes it a little trickier. To complicate matters even more, I was using debian's gunicorn package, which not not make changing the Django executable easy.

New Relic has excellent documentation for downloading, installing and configuring their tools. Here are my crib notes:

view plainprint?

    pip install newrelic django-newrelic-extensions  
    # sign up on newrelic.com, get $LICENSE_KEY under "Account Settings"  
    mkdir /etc/newrelic  
    newrelic-admin generate-config $LICENSE_KEY /etc/newrelic/newrelic.ini  
    newrelic-admin validate-config /etc/newrelic/newrelic.ini

You should now be able to log in to new relic and see an application called "Python Agent Test". This means that the test worked; new relic can communicate with the hosted servers. You can run gunicorn manually from the command line with new relic as follows:

view plainprint?

    cd /opt/my-django-project  
    export NEW_RELIC_CONFIG_FILE=/etc/newrelic/newrelic.ini  
    newrelic-admin run-program python manage.py run_gunicorn

Notice that new relic replaces the python executable with its own command, "newrelic-admin run-program". I'm using Ubuntu, which uses the Debian gunicorn package, which stores its configuration in /etc/gunicorn.d/django. Here is my current config file:

view plainprint?

    #/etc/gunicorn.d/django  
    CONFIG = {  
        'mode': 'django',  
        'working_dir': '/opt/my-django-project',  
        'user': 'django',  
        'group': 'django',  
      
        # stupid hack to get new relic to load in Django 1.3  
        # once we move to 1.4 we should use straight WSGI  
        'python': '/opt/my-django-project/conf/newrelic.sh',  
        'environment': {  
            'NEW_RELIC_CONFIG_FILE': '/etc/newrelic/newrelic.ini',  
            },  
      
        'args': (  
            '--bind=0.0.0.0:80',  
            '--workers=4',   
            '--backlog=0',  
            '--worker-class=sync',  # gevent doesn't work smoothly with new relic yet  
            '--preload',  
        ),  
    }

Notice the hack to inject the new relic runner script. I have over-ridden the python executable path to point to a third script, newrelic.sh.

view plainprint?

    #!/usr/bin/env bash  
    /usr/local/bin/newrelic-admin run-program python $*

This script just takes whatever arguments are passed in ($*), and passes them as arguments to newrelic-admin. That's it, a service gunicorn restart should start data flowing into new relic.

What’s the best way to boost the efficiency of your product team and ship with confidence? Check out this ebook to learn how Sentry's real-time error monitoring helps developers stay in their workflow to fix bugs before the user even knows there’s a problem.