• EnglishEspañol日本語한국어Português
  • ログイン今すぐ開始

Python agent v2.24.0.21

August 6, 2014


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.


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 backend 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.
Copyright © 2024 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.