Python release notes

Python agent release notes

Monday, August 25, 2014 - 11: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 is a hotfix release to prevent proxy credentials set in the agent configuration file from being transmitted to New Relic.

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

For a list of known issues with the Python agent see Status of the Python agent.

Bug fixes

  • Previously, the agent stripped the proxy_user and proxy_pass settings when it transmitted configuration settings to New Relic, so as not to expose credentials. However, the proxy_host setting was transmitted unaltered, even if it was a URI containing a username and/or password. With this release, proxy usernames and passwords specified in a URI in the proxy_host setting are obfuscated before being transmitted. In addition, the proxy_user and proxy_pass settings are obfuscated, and are also transmitted.
Wednesday, August 20, 2014 - 17: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 includes improvements to browser monitoring, with the primary change being that the Python agent is now able to perform automatic browser monitoring for a wider range of Python web frameworks running on a traditional WSGI server. This includes popular web frameworks such as Flask, Pyramid and Bottle.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly 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

  • Prior to this version, automatic browser monitoring for HTML pages served up by a Python web application was only available if using the Django web framework. With this release this capability has now been expanded in most cases to cover any Python web framework being hosted on top of a web server with a direct interface for hosting Python WSGI applications. WSGI servers this covers include the popular Python web hosting packages Apache/mod_wsgi, gunicorn and uWSGI. Support does however not currently extend to Python web hosting mechanisms which provide a bridge to a WSGI application from a native Python web application API, such as is the case if using the Tornado or Twisted WSGI containers.

    What the change means is that if using a previously unsupported web framework such as Flask, Pyramid or Bottle, and you were not manually instrumenting your HTML page responses to make use of browser monitoring, you will now start to see automatically end user performance metrics being captured and displayed in the New Relic APM UI. You will also have access to the optionally enabled browser monitoring agent, enabling access to details of AJAX calls made by your pages and also the details of any client side Javascript errors which might have been raised.

    If you were previously manually instrumenting your HTML page responses to enable browser monitoring, you should in most cases now be able to discontinue such manual instrumentation.

    Note that at this time, in addition to lack of support for Tornado and Twisted WSGI containers, we do still have a few restrictions in place which mean we may not always be able to enable automatic browser monitoring support. The key restriction is that when using a web framework, the automatic support for browser monitoring will be disabled if you are using a middleware or plugin for the framework, which performs compression of responses, or which otherwise modifies the content encoding for the response. For example, automatic browser monitoring will still not be available if using the flask.ext.compress plugin with Flask, or the paste.gzipper middleware with any WSGI application. We are working on extending coverage to cases where such middleware or plugins are being employed, but if you are using them, for now you will still need to resort to manually instrumenting your responses to enable browser monitoring. The only exception to this is the Django web framework, where we already previously had support for automatic browser monitoring even if the Django GZipMiddleware was being used.

    For further details on the updated browser monitoring support and manually instrumenting your HTML page responses, see our documentation on page load timing when using the Python agent. If browser monitoring support is not currently enabled for your application or you need to disable it, then see our documentation on browser settings.

Bug fixes/Improvements

  • The agent was in some cases incorrectly inserting our instrumentation to HTML page responses which were marked as an attachment by way of a Content-Disposition HTTP response header or HTML page meta tag.
Wednesday, August 6, 2014 - 17: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 includes fixes related to tracking of external web service calls and minor improvements to automatic real user monitoring HTML insertion for Django. An offline developer mode has also be added to verify the operation of the agent with your application in a development or test environment.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly 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

  • An offline developer mode for the agent now exists to allow for verification that the operation of the agent will not affect the monitored web application in a development or test environment, without sending any actual data to New Relic. As it is an offline mode, no additional hosts will be recorded against your New Relic account for billing purposes.

    The offline mode does not allow for any viewing of collected metric information and other data for the purposes of monitoring your application, so it is not a solution for running New Relic locally. Being able to run it however, will allow you determine if a newer version of the agent, or an upgrade of any third party package in conjunction with the agent, will still function correctly before you jump to upgrading the packages in your production environment.

    The offline developer mode can be enabled by setting the developer_mode setting in the agent configuration file, or the NEW_RELIC_DEVELOPER_MODE environment variable, to true.

    Audit logging can also be enabled in conjunction with the offline developer mode so as to allow for the investigation of what data would be set to New Relic, resulting from the monitoring of your application, without actually sending any data to New Relic.

    Audit logging itself can be enabled by setting the the audit_log_file setting in the agent configuration file, or the NEW_RELIC_AUDIT_LOG environment variable. It is not recommended that audit logging be enabled for any extended period as the resulting log file will be quite large.

Bug fixes/Improvements

  • When using the Bottle web framework, the setting error_collector.ignore_status_codes, for ignoring exceptions linked to specific HTTP response status codes, was being ignored in the case of using Bottle plugins and a plugin raised a HTTPError exception. This only affected Bottle versions 0.11 or higher.

  • The New Relic feature for cross application tracing between two monitored web applications was not working when a Python web application was using recent versions of the urllib3 and requests modules for initiating the call to the back-end web application service. This affected version 1.8 or higher of urllib3 and version 2.3.0 of the requests module.

  • External web service calls were not being monitored when using the prepared requests feature of the requests module directly.

  • When using the urllib or urllib2 modules, if a URI of the form file://..., corresponding to a local file on the file system, was passed to any function monitored by our instrumentation, a metric and transaction trace node were being generated corresponding to an external web service with host name of 'unknown'. The instrumentation now correctly filters out URIs which do not correspond to an actual remote web service.

  • The automatic means for inserting page load timing tracking code for real user monitoring (RUM) into HTML page responses returned from a Django application now works no matter the case used for HTML elements. Previously automatic insertion would only be performed where HTML elements were lower case.

  • RUM tracking code inserted automatically into HTML page responses from Django is now more optimally placed when a X-UA-Compatible meta tag appeared in the head element of the HTML page. Previously the RUM code was placed at the end of the head element when such a meta tag existed. This would have meant that page loading times would not have accurately reflected time spent in loading assets from any script elements appear after the meta tag. The RUM code is now placed immediately after the meta tag. Placement is not done before the meta tag as some browsers require that the meta tag appear prior to any script elements.

  • RUM tracking code inserted automatucally into HTML page responses from Django is now placed after any Content-Type meta tag which also contains a charset attribute. This is necessary as some browsers will not recognise such a meta tag if it does not occur early in the page content. If a script tag was therefore placed before this meta tag it could have resulted in the meta tag being pushed down sufficiently far enough in the page content so as not to be recognised.

  • Data corresponding to a long running transaction monitored by the agent, which spanned the time when a server side configuration change was made in the New Relic UI, will now be discarded. This is to avoid a problem where the response time average for web requests on the overview chart would be skewed so as to appear greater at the time a server side configuration change was made. This problem would result as when such a server side configuration change is made, the agent will momentarily disconnect and reregister. In that time, any short lived transactions would not be monitored, but the long running transaction which only completed after registration occurred was incorrecly being recorded, with an undue effect on average response times.

Tuesday, July 1, 2014 - 06:00
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 is a hot fix release to address an issue introduced in version 2.22.0.19 when applying additional function traces from the agent configuration.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly 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.

Bug fixes:

  • When using the transaction_tracer.function_trace setting in the agent configuration file to apply additional function traces, the trace was not being applied and a message indicating an instrumentation error would appear in the Python agent log file. The error in itself would not have prevented the agent from starting and running, but no data would be collected for the designated functions as intended.
Tuesday, June 24, 2014 - 04:15
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 introduces a means to enforce High Security Mode from the agent configuration, as well as enabling capture of Insights events for background tasks.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly 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:

  • Insights events are now also recorded for background tasks, in addition to the existing events already captured for web transactions.

  • The application to record an exception against can now be explicitly provided using the keyword argument application when calling newrelic.agent.record_exception(). This enables the ability to record exceptions outside of the context of a monitored web transaction or background task. A suitable application object can be retrieved using newrelic.agent.application().

Features Changed:

  • Enforcing High Security Mode from the agent configuration is now supported.

    High Security Mode is a feature to prevent any sensitive data from being sent to New Relic. The local setting for the agent must match the server setting in the New Relic APM UI. If there is a mismatch, the agent will log a message and act as if it is disabled. A link to the docs for High Security Mode can be found here

    Attributes of high security mode (when enabled):

    • Requires an SSL connection to be used.
    • Prevents capture of request parameters.
    • Suppresses capture of custom parameters.

    The default setting for High Security Mode is false.

    If you already have high security mode enabled within the New Relic APM UI, you will need to add:

    high_security = true
    

    to your local agent configuration file.

    Or if using Heroku, set the NEW_RELIC_HIGH_SECURITY environment variable by running:

    heroku config:set NEW_RELIC_HIGH_SECURITY=true
    
  • When using the gunicorn WSGI server, the request URL which appears in transaction trace samples and error details will now be sourced from the RAW_URI variable passed by gunicorn in the WSGI environ dictionary. This will ensure that what is displayed is the raw URL before % escape sequences have been decoded. This avoids the problem of the URL being shown as a raw byte sequence.

  • When audit logging is enabled, the responses returned from our data collector service will now also be logged.

Bug fixes/Improvements:

  • An incorrect module name was being derived for methods of classes, when used in web transaction and function trace naming, where the method was from a base class defined in a different module, but invoked via a derived class.

  • When using Django class based views, if a class based view was used explicitly from within a view handler, the name of the class based view method was overriding the web transaction name, which at that point would have been set to the view handler. The class based view method name will now only be used for the web transaction name when it is actually registered as the view handler.

  • Explain plans for SQL queries were not working when the SQL database cursor had been configured to return a dictionary rather than a tuple for each row set when the original query was made.

Friday, June 13, 2014 - 05:20
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 addresses a bug which in some cases caused database connection parameters, which could include login credentials, to be logged to the local system by the monitored application if Python agent debug logging is being captured.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly 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.

Bugs Fixed

  • When Python agent debug logging was enabled by setting log_level to debug in the Python agent configuration, database connection details, including login credentials could be logged in the local Python agent log file.

    The details may also have been logged even if log_level had not been set to debug, but the Python logging module had been configured to collect and log messages logged at the log level of logging.DEBUG.

    This issue was introduced in version 2.20.0.17 of the Python agent.

Thursday, May 29, 2014 - 00:00
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 provides various improvements to database client module instrumentation and execution of explain plans.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly 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

  • Added a 'license-info' command to the 'newrelic-admin' script for displaying the LICENSE file for the 'newrelic' package.

Bug fixes/Improvements:

  • The bottle instrumentation was causing a secondary exception when a web request was not actually being monitored and an un-handled exception occurred in the web request.

  • Added support for accepting additional arguments to the execute() method of database cursors implemented by the oursql and cx_Oracle modules which are not covered by the Python DBAPI 2 (PEP 249) specification.

  • The time taken for connect() calls of database client modules will now be counted in Database time (on the APM Overview page).

  • The automatic rollback or commit performed on exit of the context manager for a database connection was not being monitored and reported when using the psycopg2, psycopg2cffi and postgresql database client modules for the PostgreSQL database.

  • Improved how database connections are managed when performing explain plans and also applied caps to the number of process wide explain plans that are done in each reporting period. This should have the result of reducing overhead in situations where there was a large number of candidate SQL statements on which to perform explain plans. Any additional overhead from the agent in the past would have been most notable when performing an X-Ray session against a key transaction.

Friday, March 28, 2014 - 10:15
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 improved audit logging functionality and an admin script sub command for recording deployments.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly 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

  • Record Deployments: A new 'record-deploy' sub command has been added to the 'newrelic-admin' script installed with the Python agent. This is a wrapper around the HTTP API provided by New Relic for recording deployments against your application. To use the sub command, add your API-KEY in the agent configuration file under the 'api_key' setting. The path to the config file, description for the deploy and optional revision, change log and user information can then be supplied as arguments to the sub command.

  • Audit Logging: An improved audit logging feature has been added to the agent for capturing details of what is being sent up to our data collectors. Information is now captured into a separate log file in a more human-readable format to aid any review process carried out to determine what the agent is sending. The audit logging feature can be enabled by setting the the 'audit_log_file' setting in the agent configuration file, or the 'NEW_RELIC_AUDIT_LOG' environment variable. It is not recommended that audit logging be enabled for any extended period as the resulting log file will be quite large.

Bug fixes/Improvements:

  • The agent now ensures that the certificate bundle packaged with the agent is always used when certifying SSL connections back to our data collector. Previously the location of the certificate bundle could be overridden by a number of environment variables. This could cause SSL connection failures when the referenced certificate bundle didn't exist or had incorrect permissions and could not be accessed.
Wednesday, March 5, 2014 - 17: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 obfuscation of explain plans as the default when using PostgreSQL, as well as including bug fixes related to the instrumentation for some MySQL database client modules.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly 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.

Bug fixes/Improvements:

  • Fixes an agent bug with PostgreSQL where parameters from the original query could appear in explain plans sent to New Relic servers, even when SQL obfuscation was enabled. Parameters from the query are now masked in explain plans prior to transmission when transaction_tracer.record_sql is set to 'obfuscated' (the default setting).

  • The automatic rollback or commit performed on exit of the context manager for a database connection was not being monitored and reported when using the MySQLdb, pymysql and oursql database client modules for the MySQL database.

Monday, February 17, 2014 - 08: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 the Cornice REST component library for the Pyramid web framework, as well as a number of minor feature improvements and bug fixes.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly 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:

  • Instrumentation added for the Cornice REST component library for the Pyramid web framework.

Bug fixes/Improvements:

  • Enhance the instrumentation for the Bottle web framework to work around the problem that the Bottle framework was not using 'functools.wraps()' correctly in the implementation of its 'auth_basic()' decorator. This was resulting in the web transaction being named after the 'wrapper' function closure used in the implementation of the decorator rather than the wrapped request handler the decorator was applied to. A pull request was made against the Bottle framework and the change will be included in a future version of Bottle. Our change ensures that the correct result is also obtained with older Bottle versions.

  • When using the database connection object created by the sqlite3 database client module as a context manager, the automatic rollback or commit performed by the context manager when the scope of the context manager is exited, will now be tracked.

  • If a function trace was applied to the bound method of a class implemented in a C extension module, the name of the module shown in the name of the function was being wrongly designated as the Python 'builtins' module.

  • Updated memcache instrumentation wrappers to use our latest function wrapper implementation. Our latest function wrappers better preserve the ability to introspect wrapped functions/methods and so return the same result as one would expect if no wrapper had been applied.

Monday, February 3, 2014 - 02:12
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 includes improved instrumentation for the Bottle framework and new instrumentation support for gevent WSGI servers. It also allows reporting of data to multiple applications in New Relic to be specified via an environment variable, in addition to the existing 'app_name' setting in the agent configuration file.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly 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:

  • Provide automatic instrumentation of the WSGI application entry point when using the 'gevent.wsgi' and 'gevent.pywsgi' servers. This means that if you are not using a web framework we already support and instrument, are using a WSGI component library, or implementing your WSGI application from scratch, it is no longer necessary to wrap the WSGI application entry point with our special decorator or wrappers when using the gevent WSGI servers.

Features Changed:

  • Previously it was only possible to list multiple applications in New Relic to report data to via the 'app_name' setting in the agent configuration file. Attempting to list multiple application names (separated by the requisite semi colon), in the 'NEW_RELIC_APP_NAME' environment variable was ignored with the complete value (including semi colons), being used as the application name. This limitation has now been lifted and a list of applications to report to can now be specified using the 'NEW_RELIC_APP_NAME' environment variable.

Bug fixes/Improvements:

  • The instrumentation for the Bottle web framework has been improved. The changes include the request handler now being broken out properly as a separate item in the transaction breakdown, the web transaction being named after an error handler when appropriate and requests which could not be mapped to a request handler being named as being a 404 if no error handler was provided. Handling of exceptions for HTTP errors has also been improved and are now being correctly matched against our internal list of HTTP status codes to be ignored as exceptions. Previously the instrumentation was too liberally ignoring all HTTP error exceptions.

  • When using the Flask web framework, a NotFound exception raised within the underlying Werkzeug library was not being ignored. It is now no longer necessary to explicitly ignore the exception type 'werkzeug.exceptions:NotFound' in the agent configuration.

  • When an unhanded exception was raised by a Pylons application, a bug in the implementation of the agent's error trace wrappers would cause a subsequent exception to be raised from the agent itself, masking the details of the original exception.

  • When trying to determine how much memory was available on a system, the agent would fallback to trying to the use the 'psutil' module, if installed, if our standard ways of checking failed. This would cause the agent to fail on a PaaS such as PythonAnyWhere, which prohibits access to the /proc filesystem. Use of 'psutil' as a fallback has now been removed to avoid any potential for a failure.

  • The version of the bundled 'requests' module the agent used to perform HTTP requests to our data collector did not work with Python 2.6.2 or older. A fix to 'urllib3' used by the 'requests' module has been back ported to address the issue.

  • Our updated database instrumentation wrappers released in the last agent version, would incorrectly return that a database connection or cursor object were callable. This could confuse code which was trying to introspect those objects to perform traversal in order to get access to inner details of the implementation of the database modules.

Friday, January 24, 2014 - 01:45
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 is a hot fix version to address an issue related to cross process application traces introduced in 2.10.0.8.

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.

Bug fixes/Improvements:

  • The value of headers inserted into the HTTP response returned from the WSGI application to support cross process application tracing were being incorrectly passed as Unicode strings on Python 2. This would cause a strictly compliant WSGI server such as Apache/mod_wsgi or uWSGI to raise an error when the headers were being set. In general, pure Python WSGI servers are not as strict in their WSGI compliance and would have silently accepted the value anyway, converting it to a byte string using the Python system default encoding.
Friday, January 17, 2014 - 10:40
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 includes various improvements and bug fixes related to instrumentation for database client modules, as well as a notable fix to our 'newrelic-admin' script affecting some users who referenced Python virtual environments via a symbolic link.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly 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:

  • Instrumentation of the WSGI application entry point will now add a new breakdown metric to web transactions corresponding to the finalization of the WSGI request. Within the workings of the interaction between the WSGI server and the WSGI application, this is the point at which the WSGI server will call any close() method on the iterable returned by the WSGI application. The name of this new breakdown metric is 'WSGI/Finalize'. In the case where there was actually a 'close()' method, a further breakdown metric will also appear corresponding to that method.

  • Added support to instrumentation for MySQL and PostgreSQL database client modules for monitoring database queries when the database connection object is used as a context manager. Such context manager features are outside of the scope of the Python DBAPI2 (PEP 249) specification, not all database client modules support it and nor do they all work the same. Although supported, we would suggest consideration should be given to not using these context manager features if you need your code to be portable between databases.

  • Added support to instrumentation for MySQL database client modules for monitoring database queries when the database connection object was created using the Connect() function. The Connect() function falls outside of the scope of the Python DBAPI2 (PEP 249) specification. Although supported, we would suggest consideration should be given to not using this Connect() function if you need your code to be portable between databases.

  • Added database instrumentation support for the mysql-connector-python database client module.

  • Custom parameters for a transaction which are a string or numeric value will now be added to and reported with analytic events reported to our analytics system code named Rubicon. This can be disabled using the agent configuration setting 'analytics_events.capture_attributes'.

  • The capture of custom parameters against a transaction trace can now be disabled using the agent configuration setting 'transaction_tracer.capture_attributes'.

  • The capture of custom parameters against error details can now be disabled using the agent configuration setting 'error_collector.capture_attributes'.

Features Changed:

  • The agent API function add_user_attribute() is now deprecated and functionality merged with the add_custom_parameter() function. The latter function should now be used instead. The display of such parameters in browser traces is now optionally enabled with the agent configuration setting 'browser_monitoring.capture_attributes'.

Bug fixes/Improvements:

  • If the 'newrelic' package was installed into a Python virtual environment, but the 'newrelic-admin' script was executed via a path that traversed a symlink to the virtual environment, the protections within the agent bootstrapping procedure was detecting that the agent was trying to be used with an application running against a different virtual environment when it was actually the same. This would result in the application not being monitored. This issue was introduced in version 2.8.0 of the agent when additional protections were added against mixing application/modules from different Python virtual environments.

  • Explain plans were not being performed on SQL queries made via the executemany() method of a database cursor object. When explain plans are now done, the data inputs from the first row of input data for the executemany() call will be used.

  • When using Python 2, if strings were supplied for the web transaction name, custom parameters, in error details etc, and that string contained a series of characters which could not be decoded as valid UTF-8, then an exception would occur. In the case of a web transaction name, this could result in the exception affecting the current web transaction and result in an error response being sent back to a user. For the case of a transaction trace or error details, the exception would prevent the sending of the captured data up to our data collector and it would be discarded. This was a regression within the agent behaviour introduced when Python 3 support was added to the agent.

  • Fixed instrumentation for sqlite database modules which could result in instrumentation not being applied correctly, and so no database metrics collected, if the sqlite module had been imported prior to the agent being initialized.

  • Limits being applied to the length of the SQL for a slow SQL query when being sent up to our data collector were being applied at the wrong time, resulting in the truncated SQL being used when performing an explain plan. This didn't affect the operation of the web application, but database logs could contain an error about the malformed SQL query.

  • Explain plans could be attempted for an SQL query even where the SQL query failed. Under most circumstances a SQL query would fail immediately and so the duration would fall below the threshold for collecting an explain plan, but the changes now made will protect against a long running SQL query which failed in the database and ensure that no additional problem is caused by issuing an explain plan for it.

  • If a monitored web application is started up using our newrelic-admin wrapper script, and it executes a separate Python script and that Python script used a Python version older than Python 2.6, the script could output the error message "'import site' failed; use -v for traceback". The execution of the script was not affected, but the message obviously could cause concern.

  • The equivalent functions from the 'urllib2' module from Python 2 were not being instrumented when Python 3 was being used. This was missed when Python 3 support was added to the agent.

Friday, December 13, 2013 - 13:13
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 marks the official introduction of support for pypy. Instrumentation has also been updated to address issues arising from the release of Celery 3.1.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly 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:

  • The agent has worked with and has already been used by customers with pypy for some time, but we have not officially acknowledged that we support pypy. We have now integrated pypy into our test procedures and now officially support this implementation of the Python language.

Bug fixes/Improvements:

  • Instrumentation for Celery has been updated to accommodate changes in Celery 3.1. The changes in Celery 3.1 resulted in no metrics being reported in prior versions of the agent.

  • When collecting data on external web service calls, the agent now drops port 80/443 from the name of the host when used with the standard http/https protocol schemes. This ensures that a URL with or without the ports are seen as the same service in the external web services page in the UI.

  • When using newrelic.agent.initialize() explicitly, if no arguments are provided, the values for the config file and environment arguments will now be read from the NEW_RELIC_CONFIG_FILE and NEW_RELIC_ENVIRONMENT arguments if specified.

  • Flask instrumentation was not correctly mapping URLs related to a HTTP 404 response to a known framework or application handler function. Instead the web transaction was named after the URL, which could result in metric grouping issues if an application was hit with a large number of URLs which couldn't be mapped by the application. Such requests will now be mapped to flask.app:Flask.handle_http_exception.

  • Pyramid instrumentation should no longer report as errors instances of exceptions derived from HTTPRedirection, raised to generate a HTTP redirect response.

  • Improvements to the newrelic-admin wrapper script and agent bootstrapping procedure to better deal with a local sitecustomize.py file. Changes will also better handle the case where the newrelic-admin wrapper script was used around a Python script using a different Python installation than that which the newrelic package was installed in, avoiding possible errors when the wrapped script was run, due to the mismatch.

Saturday, November 2, 2013 - 22:33
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 contains support for web applications and worker processes using 'gearman' for background task execution. The agent also switches to using the 'json' package from the standard library instead of a separate 'simplejson' package. This should result in potential reductions in base level memory usage by the agent and a reduction of CPU overhead for some environments.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly 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:

  • Instrumentation now provided for the gearman package. The support covers use of both the gearman client and worker interfaces. In the case of workers, each task executed by the worker will be recorded as a background task and be displayed as such in the New Relic UI.

  • The ignore_errors argument to newrelic.agent.record_exception() can now be a callable in addition to being able to pass a sequence. When it is a callable, the callback will be called with the three arguments exc, value and tb, being the same values as returned by sys.exc_info(). The callback should return True if the exception is to be ignored. False if the exception should never be ignored regardless of any other checks, and None if subsequent checks and inbuilt rules should determine if the exception should be ignored. A callback would normally return either True or None.

Bug fixes/Improvements:

  • The bundled 'simplejson' package has now been removed and is no longer used. This was previously used due to the requirement to support Python 2.5, for which support was removed in version 2.0.0 of the agent. Instead of simplejson, the 'json' package contained in the Python standard library is now used instead. This should see the base level memory usage of the agent drop as a result. Further, in environments where a C compiler was not available and the C extension modules could not be compiled, there should now be a minimal reduction in the CPU overhead when the agent is uploading data to our back end. This is because the optimised C extension in the json package will always be available as part of the Python standard library and will always be able to be used.

  • If a WSGI application was returning an iterable such as a generator, and an exception was raised when a specific part of the response content was yielded from the generator, the details of the exceptions were not being recorded.

  • In a multithreaded web application where deferred module imports were being performed in secondary threads, agent registration could fail the first time due to concurrent changes made by the secondary threads to sys.modules. Registration would succeed on a subsequent attempt. This bug was only occurring in Python 2 and was introduced in version 2.0.0 of the agent when Python 3 support was added.

  • Custom parameters which were explicitly supplied to newrelic.agent.record_exception() were being ignored and were not appearing in the error details page in the UI. Instead, only custom parameters added using newrelic.agent.add_custom_parameters() against the web transaction or background task itself were being shown. This bug was introduced in version 1.13.0 of the agent when support for cross application tracing was added.

  • The port number used in the URL for a web external call, was not being retained when the URL was added as a parameter against the web external node for transaction traces. The port would therefore not be displayed when drilling down into the details of a web external node in a transaction trace.

  • The newrelic-admin validate-config command will now work for enterprise high security mode accounts, provided of course that no setting is otherwise specified in the agent configuration file which is in conflict with that mode. That is, features such as SSL would still need to be enabled by the ssl setting and the capture_params setting indicating whether URL query string parameters should be captured, also set to false.

  • When using CherryPy, in addition to the explicit exception type 'NotFound' being ignored as an error, raising of a 'HTTPError' exception where the status is 404 will also be ignored. Similarly, instances of the 'HTTPError' exception will be ignored as an error when they are for a HTTP error in the 30X range.

Wednesday, October 16, 2013 - 05:04
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 is a bug fix release primarily to address a number of issues introduced in version 2.2.0.2 which have effected a small number of users.

This version of the agent is also the minimum recommended agent version required to be able to see percentiles and histogram charts. All reporting hosts for an application must be upgraded to the minimum agent version for the feature to be visible.

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.

Bug fixes/Improvements:

  • Fixed issues with instrumentation wrappers which caused failure of WSGI application integration for FASTCGI/SCGI/AJP using flup.

  • Fixed issues with instrumentation wrappers which caused failure of wrappers for external web service calls in certain uses cases.

  • Fixes issues with instrumentation wrappers which caused failure when queuing Celery tasks from within a web application using django-celery.

  • When using the ErrorTrace context manager to capture details of exceptions within a certain context, None can now be passed for the transaction and an assertion failure will not be raised. This avoids the need to check explicitly to see if a web request is being monitored and avoid using ErrorTrace where there isn't.

Friday, October 11, 2013 - 22:13
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 is a hot fix version to address a Celery instrumentation issue introduced with version 2.2.0.2.

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.

Bug fixes/Improvements:

  • Fixed bug with Celery instrumentation introduced with version 2.2.0.2 of the agent. The bug was causing a Python exception to be raised when the instrumentation was trying to derive the task name to use as the name of the background task.
Friday, October 11, 2013 - 02:22
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 is an incremental release and includes minor feature changes and enhancements.

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:

  • Use of HTTP proxies over SSL using the HTTP CONNECT tunnelling mechanism is now supported. Set the 'proxy_scheme' to 'http' to invoke this mode. This will become the default in a future version of the agent. If migrating from an older agent version and need to keep the existing behaviour going forward, set 'proxy_scheme' to 'https'. Alternatively, ensure you provide the scheme in the form of a URI as part of the 'proxy_host' setting.

  • Added request queueing support to the instrumentation for the Tornado ASYNC framework. Request queueing times should start showing in the APM Overview page when a front-end web server such as Nginx, has been configured to add the appropriate headers. For more details see our documentation on setting up tracking of queueing time.

  • The 'newrelic.agent.record_exception()' can now be called without actually passing it any exception details. In this case, the details of any current exception being handled will be used instead.

  • Added a new mechanism for automatic discovery of third party instrumentation modules as an alternative to having to list them explicitly in the agent configuration file. Any such instrumentation module should register entry points under the 'newrelic.hooks' group in 'setup.py' for that package. The entries should be of the form 'target-module = instrumentation-module:function'. When the 'target-module' is imported, the function 'instrumentation-module:function' will be executed and passed the module. Any instrumentation module should then use functions provided by our agent API under 'newrelic.agent' to instrument the module as necessary.

Bug fixes/Improvements:

  • When using the CherryPy web framework, the NotFound, InternalRedirect and HTTPRedirect exceptions if raised are now ignored and not treated as errors.

  • When using the Pyramid web framework, if a view could not be found to handle a request, it could cause the agents' Pyramid instrumentation to fail, causing an exception.

  • When using the Pyramid web framework, the PredicateMismatch exception if raised when trying to resolve a URL to a view handler is now ignored and not treated as an error.

  • Updated the instrumentation for the pywapi module to drop support for the now discontinued Google weather API.

  • Overhauled the mechanisms used to wrap instrumentation around functions to be monitored. When the agent is installed, if the optional C extension module can be compiled and installed, then the new wrappers should have a reduced overhead compared to the pure Python versions of the wrappers otherwise used.

  • Running thread profiles on coroutine (gevent/eventlet) based systems no longer cause a timeout in the UI. Although the UI now no longer times out, as explained in our status of the Python agent documentation, we still however do not generate any results when running thread profiling on coroutine based systems.

Wednesday, September 4, 2013 - 03:33
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 is a major new version and primarily focuses on the addition of support for Python 3.

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:

  • Python 3.3 or later is now supported. This includes support for popular web frameworks that have been ported to Python 3, such as CherryPy, Django, Flask, Pyramid and Tornado.

  • Added new instrumentation to track as external service calls, requests made by the 'thrift' client module.

  • Added new instrumentation to track memcache calls made by the 'bmemcached' client module.

Features Removed:

  • Python 2.5 is no longer supported. The minimum required Python version is now 2.6. If using Python 2.5, you should ensure that any requirement for the 'newrelic' module listed in a 'setup.py' or pip requirements file says 'newrelic<2.0.0.0'.

Bug fixes/Improvements:

  • Fixed broken instrumentation for 'httplib' module, which would cause an exception where the 'httplib' connect() method was being invoked via the Connection class type rather than an instance of the Connection class.

  • Fixed issue where if the host system clock was wound backwards, then the response time of active requests could be set as being zero, resulting in a ZeroDivisionError when calculating thread utilization.

  • Fixed issue where the use of SSL via a HTTP proxy by the agent to connect to the New Relic data collector to report data would fail.

  • Fixed broken instrumentation for sqlite database client module which resulted in the executescript() API call failing.

  • Add workaround for uWSGI issue where when using gevent mode of uWSGI, it would attempt to wait on all greenlets on process shutdown, instead of only on non daemon threads, specifically the request threads. The issue was causing processes to hang for 60 seconds on shutdown before the uWSGI master process killed the process. We are in discussion with uWSGI authors about a permanent fix to uWSGI.

Friday, July 5, 2013 - 13: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 includes a hot fix to address an issue whereby external web service calls made via HTTPS connections were failing. This issue was introduced with version 1.13.0.30 of the agent.

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.

Bug fixes/Improvements:

  • The Cross Application Tracing feature added in version 1.13.0.30 of the agent was causing failure of external web service calls made over HTTPS connections when that call was made via the 'httplib' module. As the 'httplib' module is used internally in other HTTP client libraries such as the 'urllib', 'urllib2', 'urllib3' and 'requests' modules, they would also have been affected.

  • Setting the 'cross_application_tracer.enabled' setting in the agent configuration file to 'false' to disable Cross Application Tracing would cause an exception when an external web service call was being made via the 'httplib' module.

Pages