Python Agent 1.13.0.30

Released on: 
Wednesday, July 3, 2013 - 03:30
End of Life

The end-of-life date for this agent version is July 29, 2019. To update to the latest agent version, see Update the agent. For more information, see End-of-life policy.

Notes

This release of the Python agent adds support for Cross Application Tracing.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directory from our download site.

For a list of known issues with the Python agent see our online help article on the status of the Python agent.

New features:

  • Support for New Relic's Cross Application Tracing feature is now available for the Python agent. This feature enables correlation of transaction traces between different services in your stack. It works on external calls made between applications monitored by any New Relic agents (Java, .NET, Ruby and Python), which support this feature. At this time the Python agent supports this feature on outgoing calls when using the 'httplib' module or any other module which uses 'httplib', such as the 'urllib', 'urllib2', 'urllib3' and 'requests' modules. Any inbound calls from other agents which support the feature will also be handled.

  • Added instrumentation for the weberror package. This provides visibility into potentially blocking operations such as sending of email for exceptions which are being reported.

  • Added instrumentation for the umemcache package.

  • Added instrumentation for the DBAPI2 compliant interface for the IBM DB2 ibm_db_dbi database client package.

Bug fixes/Improvements:

  • When running a WSGI application under the Tornado WSGI container, data reporting would stop if an unhandled exception managed to propagate back up to the Tornado WSGI container. This was due to a bug in Tornado in respect of its compliance with the WSGI specification. A workaround is provided to avoid the problems this caused to the Python agent. Tornado versions prior to 3.2 will still carry that bug however and we make no attempt to address the bug in Tornado.

  • The Tornado instrumentation was causing template rendering to fail where a relative path was used to refer to the template and no template path had been specified for the RequestHandler instance or globally.

  • The Tornado instrumentation was causing exceptions when using the @tornado.gen decorators under Tornado 2.X.

  • When using Django, web transactions will now be named after individual view handlers when using class based views, rather than being named after the class itself.

  • When using Pyramid, web transactions will now be named after individual view handlers when using view classes, rather than being named after the class itself.

  • Celery instrumentation had stopped working correctly for Celery versions 2.5.3 through 2.5.5.

  • No data was being reported where a monitored process was being shutdown within a couple of seconds of being started even if the agent was able to register. This could result in custom metrics in particular not being reported.

  • SSL certificate validation was failing on older Debian systems due to the OpenSSL libraries not being able to process a couple of the certificates bundled with the Python agent. Those certificates were not required and have been removed.

  • Calculation of a time string was failing on Windows due to using a strftime() formatter which only existed on UNIX systems.