Notes
This release of the Python agent adds the ability to strip exception messages from error traces, in order to prevent the inadvertent capture of sensitive information.
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
- Allowing Exception Messages
Because an exception message can contain sensitive information, the agent now provides the ability to strip exception messages before sending error traces to APM. Exception messages will be stripped automatically in high-security mode.
For exception messages you know to be safe, you can add them to an allow list so that those messages are passed unaltered to APM. Two new configuration settings control this feature: strip_exception_messages.enabled
and strip_exception_messages.whitelist
.
Bug Fixes
capture_request_params
API disabled for high-security mode
When operating in high-security mode, the agent should not capture query string parameters. However, prior to this release, it was possible to call newrelic.agent.capture_request_params(flag=True)
, even if the agent was in high-security mode, and the agent would capture and report query string parameters. Now, the capture_request_params
API call does not override the capture_params
setting when the agent is in high-security mode, so query parameters are not captured.
Notes
This release of the Python agent adds the ability to customize the hostname displayed in the APM UI, as well as updating the solrpy and pysolr instrumentation so that Solr metrics will now appear in the Databases tab in the UI.
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
- Customize hostname displayed in APM
A new configuration setting has been added: process_host.display_name
. When set in the newrelic.ini
configuration file, the display name will be used in the APM UI, in place of the hostname that the agent automatically captures. In addition, the display name can be set using the NEW_RELIC_PROCESS_HOST_DISPLAY_NAME
environment variable.
Features Changed
- Update solrpy and pysolr instrumention
Previously, solrpy and pysolr instrumentation reported metrics in the Solr
namespace. Now, to align them with our recent changes to SQL and NoSQL instrumentation, solrpy and pysolr have been updated to report metrics in the Datastore
namespace, which means that time spent in calls to Solr will be listed in both the main overview chart, as well as in the Databases tab in the UI.
Notes
This release of the Python agent adds support for Django 1.8.
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
- Support for Django 1.8.
Features Changed
- The list of modules loaded by the application will no longer include version numbers. In certain cases, attempting to determine the version numbers of packages can potentially generate excessive CPU overhead, so it has been preemptively disabled to prevent any such occurrence.
Bugs Fixed
- When using the psycopg2 Postgres database adapter, if the
pscyopg2.extras.register_json()
function was used, then instrumentation for the psycopg2 module would fail. Now,register_json()
is instrumented correctly. - If a Django class based view was registered as the view handler in urls.py, the transaction was named after the class name, and not the method of the class based view which handled the request. Now, the transaction is named after the method.
Notes
This release of the Python agent adds instrumentation for Elasticsearch as a new datastore product and a more granular breakdown of various SQL operations in the “Databases” tab in the APM UI. In addition, the stack traces captured by the agent are now being trimmed to remove any code snippets.
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 SQL Breakdown
This agent release adds the ability to see the breakdown of time spent in SQL statements such as CREATE, DROP, ALTER, SET, CALL, EXEC, EXECUTE, COMMIT and ROLLBACK. Execution of stored procedures through the callproc() or CALL statements will provide further breakdown based on the name of the stored procedure.
Elasticsearch Support
Instrumentation support for the official Elasticsearch client module and the separate pyelasticsearch module have been added. Time spent in calls made to Elasticsearch will be listed in both the main overview chart, as well as in the Databases tab in the UI. Previously, calls to Elasticsearch would have been shown as time spent in external web service calls.
Features Changed
Remove code snippets in stack traces
Stack traces captured for errors and slow SQL queries will no longer include code snippets. This change is to prevent the possibility of capturing sensitive data embedded within the code. It reduces the overhead in capturing stack trace information, and also avoids a potential problem caused when the code on disk has changed in the time since the process was started.
Bugs Fixed
- Ensure that messages sent to the data collector containing parts which were already compressed and encoded, were not being compressed a second time at the HTTP request level causing additional overhead.
- Guard against a potential agent error where an invalid URL was being passed to an instrumented external web service client.
- Motor (an asynchronous MongoDB library) incorrectly returns a non string object when the agent tries to access the
__name__
attribute on Motor objects. This caused the agent to fail when calculating the name for an object, since we rely on this value being a string as specified by the Python object model definition. The agent now overrides the incorrect behavior of Motor to ensure that we can still generate names of objects correctly. - When using Python 3 and audit logging was enabled, if messages being sent to our data collector were large enough that they were being compressed at the HTTP request level, the audit logging code would fail due to a bytes/Unicode mismatch.
- Instrumentation for the decr() method of umemcache client for Memcached was incorrectly calling the stats() method.
Notes
This release of the Python agent is a minor bug fix release, including changes which may help to reduce the incidence of spurious warnings about being able to communicate with our service.
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.
Bugs Fixed
Improved management of the network connection to our service
- When the agent registered itself with our data collector, it wasn't closing the socket connection immediately and instead it was holding it open for up to a minute when the first batch of data would be reported. If the socket connection was being closed remotely during that time, a
BadStatusLine
exception would be seen in the logs when the attempt was made to upload data. - When the agent received an internal restart request from our data collector as the result of a server side configuration change, the socket connection wasn't being closed explicitly. In the case of CPython it would still be cleaned up and closed immediately due to reference counting, but under PyPy when it was closed was dependent on when PyPy garbage collection occurred. This could mean that the socket descriptor could stay in use for a while.
- When the agent registered itself with our data collector, it wasn't closing the socket connection immediately and instead it was holding it open for up to a minute when the first batch of data would be reported. If the socket connection was being closed remotely during that time, a
Compatibility modules for transitioning from Python 2 to Python 3
When compatibility modules for Python 2/3 migration such as
pies2overrides
andfuture
were installed in a Python 2 installation, they were installing modules which mimic modules which would normally only ever exist in a Python 3 installation. The presence of these modules were confusing the agent's instrumentation mechanisms. The result of this was that use ofhttp.client
from Python 3 in a Python 2 application would fail.Failures when making calls to external web services
- If a HTTP client module was supplied
None
as the value for the URL being requested, this would cause an exception when the agent was recording the data for that transaction. - Use of the
ExternalTrace
context manager class directly, for recording external web services calls, would fail if there was no active transaction. This could occur in the time before the agent has successfully been able to register with our data collector.
- If a HTTP client module was supplied
Setting of response content length when using Django
The Django middleware installed by the agent to perform insertion of RUM monitoring code into responses, would always set the
Content-Length
even if it was not previously set. This could cause issues where a frontend had been set up with an expectation thatContent-Length
headers would never exist.
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.
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 backend 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.
Important
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 synthetic 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
Synthetic 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.
Important
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.
Important
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.