The AppDynamics Python Agent helps you monitor Python applications in production to determine which applications are slower than normal or producing a lot of errors. It also provides tools for troubleshooting application problems so that you can take action before poor performance becomes apparent to your users.
The agent consists of two components:
- Python extension component: collects metrics from the Python application
- proxy component: reports metrics to the Controller, which stores, baselines and analyzes the data collected by the agent.
The Controller can be the AppDynamics SaaS controller or an on-premise AppDynamics controller at your workplace.
To access the data, you log in to the Controller from a Web browser using your AppDynamics credentials. You can also access the data programmatically using the AppDynamics REST API.
After you install the agent and run some traffic through your application, log in to the Controller. Typically the first thing you see is the application dashboard.
The flow map in the dashboard shows the flow of traffic through the entire application through the various application servers (tiers) to the backends (databases, HTTP services, caches, message queues, etc). The tiers are represented by circles.
The numbers inside the circles indicate how many nodes are in the tier. The node is the basic unit of processing that the agent monitors; for the Python Agent a node is a WGSI server. A tier represents a key service. The backends themselves are not instrumented by the Python Agent, but the agent reports metrics for flow from the tiers into them.
There are various pre-built dashboards throughout the AppDynamics UI.
To get an idea of how a user experiences various interactions with an application, monitor the application’s business transactions. A business transaction corresponds to a user request. Business transactions offer a customer-centric approach that helps you isolate where in your app users may be experiencing problems. Click Business Transactions in the left navigation pane or the Top Business Transactions tab in the application dashboard to see a list of business transactions in your application. Then double-click one of the business transactions in the list, perhaps one that is reporting long response times, to examine a single business transaction in depth.
You can examine individual instances of a business transaction taken at a point in time. These are called transaction snapshots. Transaction snapshots let you drill down to a call graph for the instance, to help you identify the root cause of the poor user experience for that transaction.
You may see business transactions in the flow map that pass through tiers that are not WSGI servers running Python applications. For example they may be Java or .NET or PHP or Node.js. Business transactions can be distributed over multiple tiers, which may be built on different platforms. The type of the transaction is based on the platform of the originating tier, which contains the entry point to the transaction. A business transaction is a Python business transaction if the user’s entry point into the transaction is a Python tier.
How business transactions are identified and named varies with the particular framework on which the the application was built and can be fine-tuned using custom transaction detection configuration.
A backend is an entity in the AppDynamics model that the app agent does not instrument directly, but reports traffic flows to it. The Python Agent monitors flows to HTTP and database exit points. See Python Supported Environments for the current list of supported backends.
The Python Agent collects a lot of metrics that do not appear in the standard dashboards. You can see all the metrics in the tree in the Metric Browser. You can create custom dashboards that display any of these metrics using a variety of widgets to create a visual display of information customized for specific types of users in your organization: executives, ops, developers, qa and so forth.
You can create health rules that stipulate certain levels of acceptable performance and then create policies that automatically send an alert or take an automated action when those rules are violated.