A diagnostic session captures detailed data about the processing of a transaction as transaction snapshots over a defined period of time. This data includes full call graphs.
Diagnostic sessions can be triggered manually through the user interface or configured to start automatically when thresholds for slow, stalled, or error transactions are reached. If the diagnostic session is triggered manually, the diagnostic session collects snapshots on all the nodes that the selected business transaction passes through. If the diagnostic session is triggered to start automatically, the diagnostics session collects snapshots on the triggering node.
Triggering a Diagnostic Session Manually
- Display the dashboard for the business transaction that you want to analyze.
- Click More Actions -> Start Diagnostic Session or right-click on the selected business transaction.
- Specify the snapshot collection duration at the bottom of the Start Diagnostic Session window.
- Click Start Diagnostic Session
AppDynamics starts collecting transaction snapshots for that business transaction.
Configure Automatic Diagnostic Sessions for Slow and Error Transactions
AppDynamics provides default thresholds to detect slow, very slow, stalled and error transactions. You can configure settings for triggering diagnostic sessions for these transactions.
- In the left navigation pane, click Configure -> Slow Transaction Thresholds.
- For configuring thresholds for business transactions click the User Transaction Thresholds tab.
For thresholds for background tasks, click the Background Tasks Thresholds tab.
- In the thresholds tree list, select the scope of the threshold: Default Thresholds or Individual Transaction Thresholds.
- In the right panel configure thresholds for starting diagnostic sessions. You can set a trigger based on the percentage of requests that exceed the Slow Request threshold. For performance reasons you may not want to trigger a diagnostic session each time a threshold is exceeded.
- Configure diagnostic session duration and collection frequency, including number of snapshots to collect over a specified time period, number of unsuccessful attempts per minute, and wait period between sessions.
For performance reasons you want to limit the duration and frequency of diagnostic sessions to the minimum required time to obtain the maximum amount of information for troubleshooting purposes.
When there are ongoing performance problems you do not want a diagnostic session to run continuously. You can set a wait period between sessions and increase the time as needed.
View a Diagnostic Session
You can access a diagnostic session from the transaction snapshot list.
- Navigate to the transaction snapshot list.
See To View Transaction Snapshots.
- Select a transaction snapshot from the list and either double-click it or click View Dashboard.
- Click the Diagnostic Sessions tab.
- From the list select a diagnostic sessions and click View Diagnostic Session.
From there you can double-click a transaction snapshot to dive deeper.
Configure Diagnostic Sessions for Asynchronous Activity
Diagnostic sessions are usually triggered based on the overall performance of a business transaction. However, the overall performance of the business transaction may not reflect the execution time of asynchronous activity. It's possible that the originating transaction executes within normal bounds, while the asynchronous activity takes much longer.
To configure diagnostic sessions for these scenario, you can create a custom health rule based on the average response time (or other performance metric) of the specific asynchronous activity, and use that health rule to set up a policy that triggers a diagnostic session on the transaction.
The general steps to do this are described in the following example that uses a metric for an async thread task.
- Create a custom health rule based on the asynchronous metric, such as average response time. The metrics for thread tasks are visible in the metric browser under the Thread Tasks node for transactions with asynchronous activity. Each thread task has an individual node (usually its simple class name). Remember to select Custom as the type for the health rule.
- Create a policy that is based on the baseline of the asynchronous metric of interest, for example, the average response time.
- Configure the policy to trigger a diagnostic session on the affected business transaction.