The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco Prime Assurance lets network operators investigate performance issues starting from any of the many parameters that contribute to them: raw server performance, competition for bandwidth from other applications and users, connectivity issues, device alarms, peak traffic times, and so on. This flexibility makes shorter troubleshooting time and quicker solutions.
In the following workflow, a network administrator is responding to scattered complaints from multiple branches about poor performance for a newly deployed application. He suspects a malfunctioning edge router at the application server site to be the problem, but needs to see if other factors are contributing to the issue.
Step 1 Select Operate > Detail Dashboards > Application.
Step 2 Limit all the dashlets on this page to the newly deployed applicatio: On the Filters line, select the Application and click Go .
Step 3 See the Application Server Performance dashlet, which gives statistics on response times for the servers hosting the application. Look for sudden increases in server response time.
Step 4 Compare the data in Application Server Performance with the data in Worst N Clients by Transaction Time and Worst N Sites by Transaction Time. See if peaks in server response time match one or more users' experience of poor transaction times, or are more generalized across sites.
Step 5 See Application Traffic Analysis for peaks in usage. Use the lower graph Pan and Zoom handles to investigate the time frames of observed traffic peaks. Compare the peaks in application response time with these periods of peak usage.
Step 6 See Top N Clients (In and Out) to identify the largest bandwidth consumers for the application. Then see Worst N Sites by Transaction Time. Compare the information in these two dashlets to see if the biggest bandwidth consumers are also part of the worst-performing sites.
Step 7 Examine the worst site in Worst N Sites by Transaction Time: Click on the site name in the Site column. If needed, filter the data on the Site Detail Dashboard by the newly deployed application, as you did in Step 2.
Step 8 On the Site Detail Dashboard, see the Top N Applications by Volume and Top N Clients (In and Out) dashlets to confirm your picture of the top application users on this site and the time periods when performance was a problem for this application.
Step 9 See the Top N Devices with Most Alarms to see if any of the site's servers or edge routers currently have alarms that may indicate why the application performance at this site is so poor.
Step 10 Use Device Reachability Status to confirm that the suspect device is still reachable. If it is, click on its Device IP to launch its 360 View.
Step 11 In the 360 View:
•Click the Interfaces tab and confirm that sessions for the affected application flow over this device.
•Click the Alarms tab to see a summary of current alarms for the device.
Step 12 If this device seems to be the source of the application performance problem at this site: Click on the Alarm Browser icon at the top of the 360 View to see all alarms for this device. Use the Show field to limit the alarms shown to those in the time frame of the problems.