Python agent release notesRSS

Notes

This release of the Python agent adds support for reporting datastore instance information for the python-memcached library. It also addresses a couple of Python 3 issues related to naming metrics and transactions.

Over the past few releases, support has been added to the agent for collecting datastore instance information for a number of drivers. See a complete list of supported packages.

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

New Features

• Datastore instance information for python-memcached

  For most memcached operations made using the python-memcached package, the Python agent will collect the host and port of the memcached server, as well as the memcached database index number. This data will be displayed in transaction traces and in slow query traces in APM.

  Supported operations include: add, append, cas, decr, delete, get, gets, incr, prepend, replace, set.

  Currently, the Python agent does not collect instance information for operations that interact with multiple memcached instances. These include: delete_multi, flush_all, get_multi, get_slabs, get_stats, set_multi.

Bug Fixes

• Names for subclass methods in Python 3

  Previously, when using Python 3, if a method was defined on a base class, but was called as a method on an instance of a subclass, the agent would generate a metric name or transaction name for that method using the base class. It would also use the module name of the base class in the metric or transaction name.

  With this release, the metric name or transaction name will use the class name of the subclass, as well as the module name of the subclass. This is consistent with how the naming works for Python 2.

• Names for Flask pluggable views in Python 3

  When monitoring Python 3 Flask applications, the agent would create metric and transaction names for Flask pluggable (or, class-based) views using the name of the View.as_view() classmethod, making it impossible to distinguish between different views in APM. Now, the metric and transaction name uses the name that is passed into View.as_view().

  For example, a view defined as view_func=ShowUsersView.as_view('show_users') would use show_users as the view name. This is consistent with how the naming works for Python 2.

• Redis client with custom connection pool

  If a custom connection pool was used with the redis client, the agent could throw an AttributeError when attempting to gather datastore instance information. One library known to define a custom connection pool that encountered this issue is Redis Blaster. With this release, the agent will no longer throw an error for custom connection pools. In addition, the agent will now be able to gather datastore instance information for some operations, even when using a custom connection pool.

• Developer Mode error message during "fake" harvest

  When using the configuration setting of developer_mode = True, the agent does not transmit any data to New Relic. Instead, it performs a "fake harvest". In some cases, it was possible for the agent to log an AssertionError during the "fake harvest", but this issue has now been fixed.

Notes

This release of the Python agent adds support for reporting datastore instance information for both the redis and MySQLdb drivers.

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

New Features

• Datastore instance information for redis

  For redis operations made using the redis-py package, the Python agent will collect the host and port of the redis server, as well as the redis database index number. This data will be displayed in transaction traces and in slow query traces in APM.

• Datastore instance information for MySQLdb

  For queries made with the MySQLdb driver, the Python agent will collect the host and port of the database server, as well as the database name. This data will be displayed in transaction traces and in slow query traces in APM.

Notes

This release of the Python agent is a hotfix release to address a problem introduced in our last release (v2.72.0.52) where users of the psycopg2 Postgresql database adapter could see extra Datastore entries in the Breakdown Table on the Transactions page in APM.

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

Bug Fix

• Remove extra Datastore segments from the Transactions Breakdown Table

  Due to the extra Datastore segments in the Breakdown Table on the Transactions page in APM, the "% Time" column would add up to greater than 100%. This problem has now been fixed. Users of psycopg2 who are using v2.72.0.52 of the Python agent are encouraged to upgrade to this latest version.

Notes

This release of the Python agent adds support for reporting datastore instance information for the psycopg2 Postgresql driver.

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

New Feature

• Datastore instance information for psycopg2

  For queries made with the psycopg2 Postgresql driver, the Python agent will collect the host and port of the database server, as well as the database name. This data will be displayed in transaction traces and in slow query traces in APM.

Notes

This release of the Python agent adds support for the improved Django middleware introduced in Django v1.10, and also adds instrumentation for the boto3 and awscli packages.

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

New Features

• Django 1.10 Middleware Support

  As described in Django Enhancement Proposal 5 and in the Django v1.10 middleware documentation, Django introduced a new style of middleware in version 1.10. Previously, Django allowed you to define certain methods on middleware classes: process_request() methods would run before the view handler was invoked, and process_response() methods would run after the response was generated. Accordingly, the Python agent would instrument these as separate, self-contained methods, and in the Transaction Trace Details view, they would be displayed at the same level as the view handler in the segments hierarchy.

  With the improved version in Django v1.10, the middleware classes form a "chain", and each middleware calls the next middleware, until it reaches the end of the chain and calls the actual view. This means that new-style middleware acts as a wrapper, and each one is nested inside the previous one. As a result, in the Transaction Trace Details view, each middleware will be nested inside the previous one, and the actual view handler will be displayed nested inside the innermost middleware class. Furthermore, the duration of each middleware segment will include the duration of the middleware nested inside it.

  Because Django v1.10 is backwards-compatible with the old-style middleware, the agent also supports instrumenting old-style middleware in Django v1.10

• Boto3 and AWS CLI Support

  With this release, API calls to Amazon Web Services endpoints made with the boto3 and awscli packages will be recorded as External Traces and will be visible in the External Services tab in APM. This is achieved by instrumenting the botocore library, which both boto3 and awscli utilize.

Bug Fixes

• Proxy Scheme Output of network-config Command

  Prior to this release, the newrelic-admin network-config command would output the incorrect proxy scheme. That is now fixed.

• Debug Console Works with Python 3

  The newrelic-admin debug-console is now compatible with Python 3.

Notes

This release of the Python agent is a bug fix release that addresses several recently reported issues.

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

Bug Fixes

• WebSocket requests could cause application errors

  When an application is using gevent-websocket to serve a mixture of WSGI and WebSocket endpoints, it is possible for WebSocket requests to interfere with the instrumentation of non-WebSocket requests, and cause application errors. While a fix for this has been added to the 'gevent-websocket` main branch, that fix has not been released to PyPI yet. To address the problem now, the Python agent explicitly ignores WebSocket requests.

• Disabling browser monitoring inadvertently disabled other features

  Disabling browser monitoring had the unintended effect of disabling certain other Response-related features of the agent. Specifically, the response.status attribute was not recorded, and the Cross Application Tracing headers were not added to the HTTP headers of the outgoing response. With this release, those features now work when using the configuration setting of browser.monitoring.enabled = False.

• Calling a Celery task within another task could cause a RuntimeError

  The Python agent would throw a RuntimeError('transaction already active') when instrumenting a Celery task that performed the following combination of actions:

  1. Utilized the agent API to end the transaction early (end_of_transaction), or to ignore the transaction altogether (ignore_transaction).
  2. After ending or ignoring the transaction, called another Celery task that would run synchronously.

  This scenario, which most commonly occurs when taking advantage of Celery Workflows to compose multiple tasks together, will no longer result in a RuntimeError.

Notes

This release of the Python agent is a bug fix release that addresses several outstanding issues. In addition, the agent's instrumentation for the Pyramid web framework was updated to handle changes introduced in version 1.7 of Pyramid.

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 Feature

• Support for Pyramid 1.7

  In version 1.7 of the Pyramid web framework, the ViewDeriver class was removed and replaced with a custom view pipeline, composed with view derivers. This required a change to where the agent applied it's instrumentation, since we were previously instrumenting the ViewDeriver class.

Bug Fixes

• Gevent and Python 3.4+

  When running the agent with gevent in Python 3.4+, the agent would throw an AttributeError when accessing the _sleep attribute in the threading module, which was removed in Python 3.4. The agent now handles this properly.

• Possible missing application exceptions in APM Error Analytics

  Using the record_exception() API, it is possible to record an exception against the application, but outside of a transaction. If there was a time window in which no transaction exceptions were recorded, but only application exceptions were recorded, then no exceptions would be displayed when viewing that time window in APM Error Analytics. With this release, application exceptions show up as expected, whether or not transaction exceptions were also recorded.

• CherryPyWSGIServer and keyword arguments

  Previously, the agent would fail to instrument CherryPyWSGIServer correctly when it was initialized using keyword arguments. That is now handled correctly.

• Missing attributes in Transaction Events

  In version 2.60.0.46 of the agent, two response header attributes were renamed, but they were not added to Transaction Events as they should have been.

  • response.headers.contentLength
  • response.headers.contentType

  These attributes are now included in Transaction Events.

Changed Feature

• Capture port for all HTTP requests to External Services

  Prior to this release, the agent would capture the port for HTTP requests to external services for only some of the HTTP libraries that the agent instruments. Notably, the port was missing when using these libraries directly: httplib, httplib2, and urllib3. The agent now captures the port for these libraries.

Notes

This release of the Python agent is a bug fix release which improves our introductory support for instrumenting Tornado 4 applications. Full details about the status of our Tornado 4 support can be found on our Introductory Tornado 4 support page.

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 Feature

• New attributes captured for Tornado 4 applications

  The following attributes are now captured for requests made to Tornado 4 applications:

  • request.headers.accept
  • request.headers.host
  • port

Bug Fixes

• Potentially too many metrics created for tornado.httpclient function traces

  The tornado.httpclient instrumentation for Tornado 4 applications could cause a "metric grouping issue" in the function traces it created, if it was used to make requests to a large number of unique URLs. To address this issue, the URL is no longer included in the name of the function trace.

• Transactions in Tornado 4 applications could be created with invalid agent settings

  In the prior release, if a transaction started before the agent had completed registration with the collector, the transaction could have invalid settings, which would result in various errors in the agent log, including an AttributeError when an external call was made during the transaction. These errors only happened at application startup until registration was complete. With this release, transactions cannot start with invalid settings.

• The httplib2 instrumentation did not process the cross application tracing headers in the response

  Failing to process the response headers resulted in the inability to link to cross application tracing details in the Transaction Trace Details view, as well as missing ExternalTransaction and ExternalApp metrics. Now, the httplib2 instrumentation in the agent processes the cross application tracing headers correctly.

Known Tornado 4 Limitations Addressed

• Explain plans for queries made with psycopg2's "async mode" are disabled automatically

  Currently, the Python agent does not support explain plans for queries made in psycopg2's "async mode." In the prior release, it was necessary to add the configuration setting transaction_tracer.explain_enabled = false to disable explain plans, or else errors would occur during data harvest, potentially causing loss of data. With this release, the agent disables explain plans automatically when async mode is detected.

• Added support for synthetics transaction traces

  Tornado 4 applications will now recognize incoming requests from synthetics and generate transaction traces for Synthetic requests.

Status of Tornado 4 Support

A current list of known limitations can be found on our Introductory Tornado 4 support page. No new known limitations have been added since our introductory release (v2.62.0.47). In the next few releases, we plan to continue addressing these issues.

Notes

This release of the Python agent adds introductory support for instrumenting Tornado 4 applications.

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 Feature

• Introductory Support for Tornado 4. (See below for details.)

Bug Fix

• Django Template Tags for Browser Monitoring Fixed for Django 1.9

For manual insertion of the browser monitoring javascript for page load timing, the Python agent offers two Django template tags: newrelic_browser_timing_header and newrelic_browser_timing_footer.

Starting in Django version 1.9, the output of simple_tag is now escaped, which results in the browser monitoring javascript being included as escaped text in the HTML output. To fix this issue, the agent now uses django.utils.safestring:mark_safe() to prevent automatic escaping for these two template tags.

Introductory Support for Tornado 4

New Relic is pleased to announce introductory support for Tornado 4. While not all features are supported at this point, providing it at an early stage allows interested customers to preview our Tornado 4 support, and provide feedback on what works well and what doesn't.

For detailed information about the introductory Tornado 4 support, including Supported Features, Design Decisions, and Known Limitations, see Introductory Tornado 4 support.

Status of Tornado 4 Support

The following is a list of known limitations for our Tornado 4 support as it exists in the current version of the agent. In the next few releases, we plan to address these issues.

• If you use psycopg2 in aynchronous mode, you must disable explain plans in the Python agent, or else the agent will throw an error when it attempts to run an explain plan query. Add this setting to your newrelic.ini configuration file:

  transaction_tracer.explain_enabled = false

  카피

• Metric names should be more consistent. For a method of a class, the metric name should contain both the name of the class and the method, but sometimes, the metric name will be missing the class name.

• The nesting of segments in a Transaction Trace should be improved. Right now, transaction traces give a good indication of the order that callbacks run on the IOLoop, but they do not group together callbacks that belong to the same coroutine, nor do they show how callbacks relate to each other.

• Transaction Traces mislabel time spent in "Application code". Because the Tornado 4 instrumentation traces all callbacks that run on the IOLoop, nearly everything that happens in a transaction is recorded. Very little is uninstrumented "Application code". When you see "Application code" time in a transaction trace, that usually means that the IOLoop was either busy running callbacks belonging to another transaction, or was waiting and not doing any work. This will be made clearer in a future release.

• In the current version of the agent, the Total Time for a transaction will always equal the duration of the transaction. In future versions, we may begin measuring the time spent waiting for asynchronous External Traces and Datastore Traces to return results, which will increase the Total Time for a transaction, making it possible to have a Total Time greater than the duration of the transaction.

• When using tornado.httpclient, no Cross Application Tracing headers are added to the outgoing requests. (This is true for both HTTPClient and AsyncHTTPClient.) That means that the application that the httpclient connects to will not show up in any of the following: trace maps, transaction maps, and service maps.

• Asynchronous External Traces only trace the initial HTTP connection. They do not trace the time for the response to come back.

• If you monitor your Tornado 4 application with synthetic monitoring, the Python agent will not capture transaction traces for synthetic checks, so you will be unable to connect your synthetic results to APM transaction traces.

• Measuring thread utilization is disabled for Tornado applications.

• Exceptions thrown in RequestHandler.initialize() are not recorded.

• Use of Tornado's built-in multi-process mode to start multiple processes and have them all share the same port is untested and unsupported.

• Use of tornado.wsgi.WSGIAdapter and tornado.wsgi.WSGIContainer is untested and unsupported.

• Use of tornado.platform.asyncio to bridge between asyncio and Tornado IOLoop is untested and unsupported. Currently, the agent only supports the use of the tornado.ioloop.IOLoop.

• Use of the async and await keywords is untested and unsupported.

• Integration with Twisted is untested and unsupported.