Python Release Notes

Python Agent Release Notes

Wednesday, February 11, 2015 - 14:30 Download

Notes

This release of the Python agent includes a major update to how we capture and represent metrics for both SQL databases and NoSQL datastores. Metrics for both types of products will now be displayed in a unified "Databases" tab in the APM UI, and these metrics will also be associated with the specific product being used. In addition, we have enabled support for having key transactions on other transactions, such as 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 Status of the Python agent.

New Features

  • Unified view for SQL database and NoSQL datastore products.

    The response time charts in the application overview page will now include NoSQL datastores such as Memcached, Redis and MongoDB and also the product name of existing SQL databases such as MySQL, Postgres, Oracle etc.

    We also introduced a new unified view within the APM UI for visualizing time spent in queries made against SQL databases and NoSQL datastore products.

    For existing SQL databases, in addition to the existing breakdown of SQL statements and operations, the queries are now also associated with the database product being used.

    For NoSQL datastores such as Memcached, Redis and MongoDB, we have now added information about operations performed against those products, similar to what is being done for SQL databases.

    Because this introduces a notable change to how SQL database metrics are collected, it is important that you upgrade the Python agent version on all hosts. If you are unable to transition to the latest agent version on all hosts at the same time, you can still access old and new metric data for SQL databases, but the information will be split across two separate views.

  • Key transactions for other transactions.

    In addition to being able to create key transactions for web transactions, it is now possible to create key transactions for other transactions, such as background tasks executed by Celery.

    Key transactions enable the setting of a per transaction Apdex and alerts, as well as the ability to run X-Ray sessions, including transaction specific thread profiling.

  • No SQL datastore instrumentation.

    To complement our new unified view for SQL database and NoSQL datastore products in the APM UI, we have upgraded our existing instrumentation for Redis and MongoDB. Previously, these only provided a function breakdown in transaction summaries and sample transaction traces, but now they will report into the unified view for database and datastore products under their respective product categories.

    Existing instrumentation for Memcached clients have similarly been updated, as well as new support for the pymemcache module being added.

Sunday, January 18, 2015 - 07:25 Download

Notes

This release of the Python agent includes bug fixes for issues with agent registration and use of proxies which could result in no data being reported.

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

  • Agent not recovering when errors occur during registration

    If the agent initially registered with our data collector successfully, but subsequently failed to upload agent setting information due to a transient back end or network issue, the agent was not recovering from the error properly. The consequence of this was that the agent would not completely start up and no data would be collected or reported by that process. The operation of the web application as a whole would not have been affected. This issue, which was introduced in version 2.36.0.30 of the agent, is now fixed.

  • Agent not able to connect via some proxy servers

    The Python agent was not able to connect to our data collector to register when certain proxy server installations or configurations were being used. We have updated the version of the internal HTTP client library used to resolve the issue.

  • Identification of Python web server being used

    The Python agent was incorrectly reporting the Python web server being used as Tornado when both the 'gunicorn' and 'tornado' Python modules were being imported, even if the Tornado web server module wasn't actually being used. This did not affect the operation of the agent but could lead to confusion when trying to debug deployment issues.

Wednesday, December 3, 2014 - 09: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 enables the collection of transaction traces for Synthetics requests by default, and adds the individual trip trace visualization for Cross Application Tracing.

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.

New Features

  • Cross Application Tracing for individual transactions

    Version 2.38.0.31 of the Python agent introduced aggregated transaction maps. In this release, we have built on that feature to add the ability to view an end-to-end visualization of an individual transaction, in order to better understand what backend applications and external services were called during the course of a single transaction.

Features Changed

  • Synthetics support enabled by default

    When the Python agent added support for the collection of transaction traces for Synthetics requests in version 2.32.0.28, the feature had to be explicitly enabled in the agent configuration file. With this release, support for Synthetics is enabled by default.

Bug Fixes

  • Non ASCII characters in transaction names

    If a transaction name contained a Unicode character outside of the ASCII range, the generation of the cross application tracing attributes would result in a UnicodeEncodeError. This bug affected versions 2.38.0.31 through 2.38.2.33. The issue is fixed in the current release.

  • Parsing SQL statements referencing the database schema

    Previously, SQL statements that referenced a table from a database schema namespace, such as “schema.table_name”, would not always be parsed correctly, resulting in the table being identified as just “schema”. The agent now handles this case correctly, and the table is reported as “schema.table_name”.

  • Additional support for Tornado 1.X

    If Tornado 1.X was being used, the instrumentation would fail at run time causing all web requests to fail. Monitoring of Tornado 1.X applications should now work correctly.

Tuesday, November 25, 2014 - 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 fixes a memory leak which affects our Tornado instrumentation, and which was a factor in the recent issues we had with the Django template instrumentation.

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

  • Due to an issue with the low level function wrappers we use to instrument third party Python modules, memory was being leaked and process memory usage could increase over time. This issue affects version 2.32.0 through 2.38.0 of the Python agent and has been impacting on our Tornado instrumentation.

    The memory leak has also been identified as the root cause for memory leaks in our Django template instrumentation, affecting versions 2.32.0.28 through 2.36.0.30. The Django template instrumentation was disabled in the prior 2.38.0.31 release while we investigated the cause. It remains disabled by default.

Wednesday, November 12, 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 adds support for the mapping features of Cross Application Tracing, which provide a visualization of how requests flow through multiple applications within a distributed system.

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.

New Features

  • Cross Application Tracing

    The Cross Application Tracing feature is now enhanced with the aggregate transaction map visualizations. This new visualization will help users spot bottlenecks in external services and give them an end-to-end understanding of what other applications and services are called within a transaction. All agents involved in the cross application communication must be upgraded to see the complete graph.

Improvements

  • Tornado 3.x Instrumentation

    The newly refactored Tornado instrumentation is turned on by default. This was introduced in the python agent version 2.32.0.28 under an optional feature flag. This change improves upon the stability of our Tornado instrumentation and accounts for the incremental changes introduced to the Tornado 3.x source tree. It also provides a more granular view of where the time is spent in a WebTransaction, by distinguishing the time spent doing work vs time spent waiting on a asynchronous call.

    Please be advised that we currently do not have instrumentation for Tornado 4.x, but we are working to add support for it.

  • Capacity Analysis for mod_wsgi

    The capacity analysis report shows how many instances of your web application is running and how busy they are. For a web application, the measure of how busy the application is, is calculated by looking at how much of the time the total available set of request handler threads are busy.

    For the case of using Apache/mod_wsgi in daemon mode, the measure of how busy your application is, has been getting over reported due to the nature of how threads are managed by mod_wsgi. If you are using mod_wsgi version 4.1.0 or higher, this measure will now be more accurately reported as it will use information provided by mod_wsgi about the total number of request handler threads which are available, rather than trying to calculate it based on what threads have been seen to be handling requests.

Bug Fixes

  • In version 2.28.0.26 and 2.32.0.28 of the agent, we added new features to track template includes and inclusion tags when using the Django template rendering system. We have had a few reports that indicate that for some users, but not everyone, that the instrumentation implementing these features may be causing an ongoing growth in memory usage for the web application processes over time. Right now, we don't understand the root cause for why this might be occurring in some instances, so to be on the safe side we have disabled these two features while we investigate further.

    The consequence of these features being disabled is that the web transaction performance breakdown and sample transaction traces will no longer show as a separate metric or entry where one template has been included in another. Further, if the tracking of special inclusion tags had been configured, they will also no longer be shown. We anticipate re-enabling the features once we have worked out what is occurring and made changes to ensure it does not occur again.

Wednesday, October 29, 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 provides improvements to how we report agent configuration information. This enables us to better help you debug any issues you may experience with configuring the agent.

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.

New Features

  • Configuration Information

    Agent configuration information displayed in the New Relic UI will now reflect the final configuration used by the agent for an application. This includes the result of any server side configuration settings, which are applied on top of the agent defaults, agent configuration file or environment variables. Previously, the result of applying the server side configuration settings was not being displayed.

Bug Fixes

  • If running a system with a Linux 3.X kernel, the agent could fail when attempting to register with our data collector. No data would subsequently be collected or reported. This would occur for versions of Python 2 prior to Python 2.7.3 and versions of Python 3 prior to Python 3.3, if they were built on a system with a Linux 3.X kernel.

Wednesday, October 15, 2014 - 12: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 support for Labels and Rollups, making it possible to organize your applications in the APM UI into meaningful categories.

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.

New Features

  • Labels and Rollups

    The Python agent now supports the ability to apply labels to applications, so that you can easily sort, filter, and page through all of the applications on your account's Applications list.

    Configuration can be done in the newrelic.ini file:

    labels = Server:One;Data Center:Primary

    Labels can also be configured by setting a NEW_RELIC_LABELS environment variable:

    NEW_RELIC_LABELS=Server:One;Data Center:Primary
    More information on using labels to categorize your applications can be found in the New Relic APM documentation.

  • New CPU Reporting in Environment Snapshot

    Previously, the Python agent captured two CPU-related values to report to the Environment Snapshot: Logical Processors and Physical Processors. Now, it captures the following three values:

    • Logical Processors: The total number of hyper-threaded execution contexts available, including execution contexts that may exist on the same core. This value remains unchanged from previous agents.
    • Physical Cores: The total number of physical CPU cores available, counting hyper-threaded siblings as a single core. This value was previously reported as "Physical Processors."
    • Physical Processor Packages: The total number of processor packages or dies (each of which may contain multiple physical cores). This value is new with this agent release.

Bug Fixes

  • A "Runtime Error: transaction already active" will no longer be seen in the case where the agent created nested transaction wrappers and newrelic.agent.ignore_transaction() was called within the outer wrapper but outside the inner wrapper. Previously, this error could have also been triggered when using the WSGI environment setting for newrelic.ignore_transaction set by SetEnv in mod_wsgi.

  • Prior to this version, the HTTP_REFERER URL reported for a transaction contained query parameters, even if the capture_params setting was set to False. Now, the capture_params setting is respected when reporting the HTTP_REFERER URL.

Monday, September 29, 2014 - 13: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 provides a preview of a significant overhaul of our instrumentation for Tornado version 3.2 and earlier. Further improvements to our Django instrumentation are also included, allowing time spent in rendering Django sub templates to be viewed separately.

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.

New Features

  • Breakout of Django template rendering

    Previously when using Django templates, if the Django include tag was being used, the time spent rendering that sub template was shown under the generic Template/Render category. When the include tag is now used, a distinct metric is instead created corresponding to the rendering time for that sub template. This will appear in the transaction performance breakdown and also in sample transaction traces. In the case of sample transaction traces, as the name of the template will be included in the metric name, it now also provides additional context for understanding where any time is being spent when rendering that template.

Features Changed

  • Preview of improved Tornado instrumentation

    Our instrumentation for Tornado version 3.2 and earlier has been experiencing a number of issues which could result in recording of data stopping and in some cases cause runtime exceptions which would affect the outcome of the executing web request. Upon investigation we found this has come about due to incremental changes in the internals of Tornado which were performed after we originally implemented the instrumentation for Tornado and which we didn't pick up as having being made. The Tornado developers have also recently released version 4.0 of Tornado. This version of Tornado has much more significant internal changes that result in our instrumentation failing completely.

    Before we could embark on trying to support version 4.0 of Tornado, we deemed it necessary to completely overhaul our existing instrumentation for older versions first in order to gives us good foundation on which to then implement support for version 4.0 of Tornado. This release of the agent provides a preview of the improved instrumentation for older versions of Tornado prior to version 4.0. The new instrumentation is not enabled by default and you will need to explicitly enable it. We have provided it as an opt in change at this point to allow you to properly test with the update first and provide us with any feedback on it and any remaining issues you may find.

    To enable the preview of the new Tornado instrumentation, you will need to add to the [newrelic]section of the agent configuration file the setting:

    feature_flag = tornado.instrumentation.r2
    
    If you are running on Heroku and are not using an agent configuration file, you can instead set the NEW_RELIC_FEATURE_FLAG environment variable. You can do this by running the Heroku command:
    heroku config:set NEW_RELIC_FEATURE_FLAG=tornado.instrumentation.r2
    

Bug Fixes

  • When an exception was raised by a WSGI application during the yielding of response content via a generator, the recording of that web request by the agent may not be closed off properly. This would result in no further web requests handled by that thread being recorded and reported. If this occurred for all request handler threads, then no data would then be reported for the whole web process. This issue relates to behaviour of the Python garbage collector and when Python objects are destroyed. At this point in time we believe this only affects users of pypy and does not affect users of CPython as the reference counting model of CPython usually gives more deterministic behaviour around when Python objects are destroyed. We don't however rule out that it could affect CPython and may explain a situation matching this problem we have seen in a couple of cases where users were using uWSGI.

  • When attempting to use Tornado as a worker for gunicorn, an exception could occur on startup which would result in gunicorn failing immediately and exiting. In order to use this combination it was previously necessary to disable the gunicorn specific instrumentation related to WSGI applications by adding to your agent configuration file:

    [import-hook:gunicorn.app.base] 
    enabled = false
    
    If you were using the Tornado worker with gunicorn and using this workaround, the underlying problem has now been addressed and you should be able to remove that section from your agent configuration file.

  • The mechanism we used for applying function wrappers for instrumentation was not being performed in the most optimal way for methods of classes. This could result in problems, including unexpected runtime exceptions, especially when trying to apply instrumentation to class methods, or methods of an existing instance of a type.

Tuesday, September 16, 2014 - 09: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 improves instrumentation for the Flask web framework and adds database monitoring support when using the pymssql client with a Microsoft SQL Server database.

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.

New Features

  • Improved instrumentation for Flask

    The Python agent now provides better web transaction naming and performance breakdown metrics when Flask style middleware are being used. This means that time spent in Flask @before_request and @after_request functions will now be broken out as their own metrics. If a @before_request function actually returns a response, the web transaction will be correctly named after that function rather than the Flask WSGI application entry point. These changes, in addition to being applied on middleware functions registered directly against the Flask application, will also work when Flask blueprints are used to encapsulate behavior.

  • Browser monitoring auto-instrumentation when using Flask-Compress

    When the Flask-Compress package is used to perform response compression with Flask, insertion of browser monitoring tracking code into HTML responses is now automatically performed. Previously, if Flask-Compress was being used, manual instrumentation of HTML responses would have been required.

  • Monitoring of MSSQL database

    Instrumentation is now provided for the pymssql database client module to monitor database calls made against a Microsoft SQL Server database.

Bug Fixes

  • When using high security mode, the use of newrelic.capture_request_params in the per request WSGI environ to enable capture of request parameters, possibly by setting it using the SetEnv directive when using Apache/mod_wsgi, was not being overridden and disabled as required.

  • When using the DatabaseTrace context manager or associated wrappers explicitly to implement a custom monitoring mechanism for database calls, the instrumentation wrappers could fail with a TypeError exception when trying to internally derive the name of the database product being used.

Tuesday, August 26, 2014 - 15: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 improves data collection with the Django web framework. These improvements include better-targeted web transaction naming with the Django REST framework, better coverage of Django template inclusion tags, and better background task monitoring for Django management commands.

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.

New Features

  • Improved Django REST Framework naming

    Previously, when using the Django REST framework, web transactions were being named after the class based view that implemented the Django REST framework resources. Now, where such a view provides custom handler methods for different HTTP request method types or actions, the web transaction will be named after that custom handler method rather than the class as a whole. A new function breakdown metric will also be added for the custom handler method. This change will allow web requests using different HTTP request method types to be viewed separately.

  • Django inclusion tag monitoring

    Usage of inclusion tags in Django templates can now be monitored and will appear in the transaction breakdown table, charts and sample transaction traces.

    Due to the possibility that a large range of custom inclusion tags might be used and that they may be invoked a large number of times in tight loops, tracking of all inclusion tags may not be practical or may not produce worthwhile results in the transaction breakdown or sample transaction traces. As a result, monitoring of inclusion tags is off by default, with the preferred approach being that specific inclusion tags of interest be individually enabled through the agent configuration file.

    To enable monitoring of specific inclusion tags, a new section called import-hook:django should be added to the agent configuration:

    [import-hook:django]
    instrumentation.templates.inclusion_tag = prepopulated_fields_js date_hierarchy

    The instrumentation.templates.inclusion_tag setting within that section should then be set to a space separated list of the names of the inclusion tags to monitor. If there is any confusion over the identity of the inclusion tag, the full name of the inclusion tag function, with module name, can instead be listed. For example, data_hierarchy can also be identified using django.contrib.admin.templatetags.admin_list:date_hierarchy.

    In addition to specifying the names of the specific inclusion tags, it is also possible to specify * for instrumentation.templates.inclusion_tag in order to have usage of all inclusion tags be monitored:

    [import-hook:django]
    instrumentation.templates.inclusion_tag = *

    Enabling monitoring of all inclusion tags in this way is only recommended in development or test environments so as to get an initial idea of what inclusion tags are worth tracking. Once identified, the specific inclusion tags of interest should thereafter be listed individually in a production environment.

  • Better monitoring of Django management commands

    We previously published a blog post about how the agent could be used to monitor Django management commands. This required you to manually set up the instrumentation for each specific Django management command in the agent configuration file. We have now made that easier by integrating the functionality as part of the agent itself.

    Due to the limitations on what Django management commands can be monitored, you will still need to list explicitly the commands you want monitored, but it can now be done in a single location as a space separated list under the setting instrumentation.scripts.django_admin of the import-hook:django section:

    [import-hook:django] 
    instrumentation.scripts.django_admin = syncdb sqlflush
    

    By default, we automatically specify the startup timeout to be 10.0 seconds when monitoring the Django management commands. If you need to override the startup timeout, you can set the instrumentation.background_task.startup_timeout setting within the same import-hook:django configuration section.

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.

Pages