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.
For a list of known issues with the Python agent see Status of the Python agent.
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.
Tornado 3.x Instrumentation
The newly refactored Tornado instrumentation is turned on by default. This was introduced in the python agent version 184.108.40.206 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.
In version 220.127.116.11 and 18.104.22.168 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.