Instrumented Python packages

When the Python agent is run it will automatically instrument the following Python packages/modules.

Instrumentation of specific packages or modules can be disabled if you find that the instrumentation is interfering with the operation of your application. For further details on disabling the provided instrumentation see the documentation on agent configuration.

If you are using a third party package or module which is not instrumented, or you want more specific instrumentation for your own code, limited abilities are provided for tracking time spent in additional functions via the agent configuration file, or by modifying the code directly to wrap functions or blocks of code with calls into the agent API. See documentation on extending the instrumentation for additional information.

If you do go down this path and believe that having the third party software instrumented is something that would be useful to others, let us know the name of the software and if it is practical and makes sense we will add it to our TODO list.

Web frameworks

Bottle

Function timing in transactions traces for slow transactions is provided for:

  • View function.
  • Template rendering via SimpleTemplate, MakoTemplate, CheetahTemplate, Jinja2Template and SimpleTalTemplate interfaces.

Exception logging is provided for:

  • Uncaught exceptions which would otherwise generate 500 responses from Bottle.

The web transaction is named after the view function.

As Bottle uses external template libraries, see also which of those packages may be supported for additional detail.

CherryPy

Function timing in transactions traces for slow transactions is provided for:

  • Handler function.

Exception logging is provided for:

  • Uncaught exceptions which would otherwise generate 500 responses from CherryPy.

The web transaction is named after the handler function.

As CherryPy relies upon external template libraries, see also which of those packages may be supported for additional detail.

Django

Function timing in transactions traces for slow transactions is provided for:

  • Request middleware.
  • View middleware.
  • Template response middleware.
  • Response middleware.
  • Exception middleware.
  • Template rendering.

Exception logging is provided for:

  • Exceptions occurring during loading of view handlers by URL resolver.
  • Exceptions occurring within the execution of the view handler.
  • Uncaught exceptions which would otherwise generate 500 responses from Django.

Page load timing (sometimes referred to as real user monitoring or RUM) support consists of:

  • Optional automatic insertion of JavaScript header/footer via response middleware.
  • Provision of template tag library to enable manual insertion of the JavaScript header/footer into templates.

The web transaction is named after the view handler, unless a request or view middleware returns a response object prior to the view handler being invoked.

Instrumentation is also implemented to provide better web transaction naming or additional functional tracing when using:

Flask

Function timing in transactions traces for slow transactions is provided for:

  • View function.
  • Template rendering via render_template() and render_template_string().

Exception logging is provided for:

  • Uncaught exceptions which would otherwise generate 500 responses from Flask.

The web transaction is named after the view function.

As Flask uses Jinja2 for templates, see also details of Jinja2 instrumentation listed below.

Pylons

Function timing in transactions traces for slow transactions is provided for:

  • Controller function, before and after methods.
  • Template rendering via render_genshi(), render_jinja2() and render_mako().

Exception logging is provided for:

  • Uncaught exceptions which would otherwise generate 500 responses from Pylons.

The web transaction is named after the controller/action.

As Pylons can use Genshi, Jinja2 or Mako for templates see also details of instrumentation for those modules listed below.

Pyramid

Function timing in transactions traces for slow transactions is provided for:

  • View handler functions.

Exception logging is provided for:

  • Uncaught exceptions which would otherwise generate 500 responses from Pyramid.

The web transaction is named after the view handler.

Tornado

Function timing in transactions traces for slow transactions is provided for:

  • Initial handler function.
  • ASYNC Callbacks when subsequently invoked.
  • Template rendering when using tornado.template.

Actions which occur outside of the context of the users code in dealing with web requests which are monitored are:

  • Pre-reading of request content.
  • Waiting for response content to be sent.
  • Time spent waiting for callbacks to complete.

Exception logging is provided for:

  • Uncaught exceptions which would otherwise generate 500 responses from Tornado.

The web transaction is named after the handler function.

Web2py

Function timing in transactions traces for slow transactions is provided for:

  • Overall time in models phase.
  • Overall time in controller phase.
  • Overall time in view phase.
  • Execution time for specific scripts executed within models, controller and view phases.

Exception logging is provided for:

  • Uncaught exceptions which would otherwise generate 500 responses from Web2py.

The web transaction is named after the view script.

Backend services

gearman

Timing of task execution performed in a gearman worker recorded as background tasks against designated web application. Timing as a web external any client side calls to a gearman server to queue up or wait for the execution of queued tasks.

Celery

Timing of task execution recorded as background tasks against designated web application.

Template rendering

Genshi

Function timing in transactions traces for slow transactions is provided for:

  • Template rendering.

Jinja2

Function timing in transactions traces for slow transactions is provided for:

  • Template compilation.
  • Template rendering.

Mako

Function timing in transactions traces for slow transactions is provided for:

  • Template rendering.

SQL database adapters

Timing of database queries, capture of the SQL for the database query and capture of a stack trace for long database queries is provided for the following Python DB-API 2.0 compliant modules.

Note: We should be able to track database queries for any Python DB-API 2.0 compliant modules. Those above are all we have directly tested or are confident will work. Let us know which database client module you are using and we will tell you a temporary change to add into your configuration file to get it working. Let us know all is fine and we will add the instrumentation as part of the package.

Capture of explain plans for slow database queries is only supported for MySQL and PostgreSQL at this time.

* Additional instrumentation also provided for database adapter specific functionality outside of the DB-API 2.0 specification. This can include short cut methods for executing queries without creating cursors etc.

NoSQL database clients

Timing of calls made against NoSQL databases are provided for the following for the following client modules.

Note that MongoDB and Redis calls are currently only recorded as transaction breakdown metrics. That is, no rollup metrics are produced and so they will still be shown on the overview dashboard as Python time and not as a separate segment or even as database calls. Also, no specific details of MongoDB queries are captured at this time and so no information will be displayed on the databases page in the UI corresponding to these queries.

Memcache clients

Timing of memcache requests and capture of type of request is provided for the following memcache client modules.

Solr service clients

Timing of Solr service requests and type of request is provided for the following Solr client modules.

External web services

Timing of external web service requests as carried out via the following modules.

For more help

If you need additional help, get support at support.newrelic.com.