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.
For a list of known issues with the Python agent see our online help article on the status of the Python agent.
- 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
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
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
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_SECURITYenvironment 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_URIvariable passed by gunicorn in the WSGI
environdictionary. 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.
- 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.