Troubleshoot a Single Application (Troubleshoot Application)

The Troubleshoot Application dashboard is an excellent starting point to investigate problems with a managed application (with activities). It displays the performance of an application from many angles, including checking which activities are slow, checking if the problem recurs at certain times, if it is restricted to a location, device type and many other possibilities. After choosing the attribute to investigate, you can drill down further to continue troubleshooting.

For example, if you received several calls about an application suddenly unable to display some colors correctly, it could be due to an incompatibility with the driver of the graphics card, so you could check if the problem is concentrated with particular device types. Alternatively it might be an incompatibility with the new 4K resolution screens in the Marketing department, so check if the problem is concentrated in that particular department.

The Troubleshoot Application dashboard for desktop applications

The response times of activities are split into client time ( light blue), and the combination or union of the backend time ( dark blue) and the network time ( blue).

Server, network and client time

After you isolated a likely cause, you can drill down to the Commonalities Analysis dashboard for further investigation. The Commonalities Analysis dashboard (for a single activity) performs automatic and intelligent troubleshooting to find the common elements of a seemingly random problem with that activity. It checks through hundreds of possible culprits (like the location, or time of day, laptop model and many more), and displays only the highest concentration of poor performers.

Procedure

  1. Step 1 Open a browser and sign in to Aternity.
  2. Step 2 Select Main Menu > Troubleshoot > Application.
    Accessing Troubleshoot Application
  3. Step 3 Select the name of the application (with defined activities) with problems, and the time the issue was first reported.
    Select the application to display in Troubleshoot Application
    Field Description
    Which application is problematic

    Select the managed application (with defined activities) whose problem you want to troubleshoot.

    Note

    The Troubleshoot Application dashboards currently only support applications with defined activities.

    What type of problem is this? (mobile apps only)

    If you selected a mobile application, select the type of mobile problem:

    • Application Issue indicates you want to troubleshoot a problem with the functionality of the mobile app.

    • Mobile Data Consumption is high indicates that the app is functioning, but you want to investigate this app's demands on data traffic to and from the mobile device. For more information, see the mobile app dashboards.

    When was this issue first reported

    Enter the date when you first became aware of the issue. Aternity displays the dashboard from some time prior to that, so you can perhaps view when the issue really began, and start to gather ideas on possible causes of the problem.

  4. Step 4 Troubleshoot your application by finding the common element where the performance problems are concentrated. Use the drop-down menu in one of sections on the right hand side to display any of the available attributes.

    Choose any of the criteria available to see if anything obviously jumps out as a concentration of slow performance. Look for an axis where most readings are fine, but only one or two entries are poor, and use this as an indication to isolate and troubleshoot the problem.

    Breakdowns of data to troubleshoot an application in both sections on the right hand side
    Field Description
    Activities

    Look for a specific activity where the application is slow to respond.

    Activities Trend

    (For managed applications only) See the trend of the application's performance during the dashboard's timeframe, by viewing the changes in the statuses of this application's activities, and their response times, to see when the problem occurred or even if it recurs at regular intervals.

    For example, if you see a surge of orange statuses every day at 9am, perhaps these delays are caused when many people simultaneously perform the same action when they start work. If those increases correspond with longer network time, you know the slowdown is in network communications at those times.

    Servers

    Check if the problem occurs for all users who connect to specific servers of this application. For example, sending a mail might be slow for only one Microsoft Exchange server.

    Business Locations

    Check if the problem impacts users working from a specific location (also collated by Cities, States, Countries, and Regions). You can also view this information on a map in the Geographies section.

    For example, if performance is poor only for users in the office in North London (a business location), check the networking infrastructure of that specific site. But if the problem affects all the offices in London (under Cities), you can check the wider infrastructure which is common to all those locations, like a data center.

    Aternity reports the location as Off-site when the device is not connected to the Microsoft Active Directory or if Aternity cannot determine the location name.

    CPU

    View the recent trend in the percentage CPU usage of this application over time, to correlate if any slowdown in performance (from the Trends section) is due to a problem in the application's usage of host resources.

    Memory

    View the recent memory usage of this application across all devices in the organization over time, to correlate a performance slowdown (from the Trends section) with a possible memory leak.

    Device Types

    Check if the problem only affects end users working on specific types of devices, like only those accessing the application on a tablet.

    Operating Systems

    Check if the problem is only on certain operating systems. For example, if you roll out a Windows update to some users and only those users register a drop in performance.

    Data Center Locations

    (Virtual deployments only) If you deployed your application with a virtual application server or virtual desktop infrastructure (VDI), check if there is a drop in performance at one of the servers.

    Data Center Locations in Aternity lists the locations of any virtual application servers (like Citrix XenApp) and VDI hypervisors (like in VMWare vSphere) which run the application. If the application is deployed both locally and virtually, one of the locations displays as Local.

    Hypervisors

    (VDI deployments only) If your application is running in a virtual desktop environment, like VMWare vSphere, check if the drop in performance in some virtual machines (VMs) is concentrated around a specific hypervisor.

    Departments

    Check if the drop in performance is centered around a specific department, which can point to a configuration which is unique to that group of users, by viewing the performance in the list of departments. For example, if you find that only the Sales department is suffering poor performance, you can trace it to an upgrade which only happened on their computers, like a new CTI which interferes with your application.

    Versions

    Displays the version number for this application, which the Agent for End User Devices retrieves from the executable's Properties > Details.

    Browsers

    (For web applications only) Displays the type of web browser housing the application.

    Browser Versions

    (For web applications only) Displays the version of the web browser housing the web application.

  5. Step 5 Check the response times in any of the sections, to isolate the slowdown to specific activities, and determine if the problem is due to slow computers, slow servers, or a slow network connection. Most sections have the following layout:
    Viewing the data about activities recorded for a single item
    Field Description
    Activity Status

    The color of the icon indicates the activity status for this item during the timeframe of the dashboard.

    In the Activities section, it represents the overall status of all instances of that activity. In the Departments section, it is the overall status of all the activities performed by people in that department. In the Operating System section, it is the status of all activities performed on that operating system, and so on.

    Total Activities

    The number next to the icon represents the volume of instances of the activities which were monitored during the timeframe of the dashboard.

    Response Time

    (For managed applications only) Displays the response time of the activity. The response times of activities are split into client time ( light blue), and the combination or union of the backend time ( dark blue) and the network time ( blue).

    • Backend time is the time required by all the servers to process data on the backend, which is part of the overall response time of an activity. It starts when the client sends a request to the target server, when the last message of that request arrives at the target server side. It ends when the server sends out the first message of its response.

    • Network time is the total time (union) taken for all messages to cross the network in either direction, between the client and the target server, while performing an activity. This does NOT include the time used for processing the request on the server (backend time).

    • Client time is the time used by the device itself as part of an activity to process data before sending its first message request to the server and after the last message response arrives back from the server. See client time.

    Hover over the response times to view more details about that item or drill down to the following dashboards:

    Drill down to other dashboards to troubleshoot further
  6. Step 6 Check the Trends section for any recent changes in response times (the upper graph) or the number of times an activity was performed, and its status (the lower graph).

    In the upper graph, see if the changes were due to increases in server time (light blue), network time (blue) or client time (dark blue).

    Use the volume (lower) graph to view the recent changes in activity statuses over the timeframe. The horizontal axis in both graphs are the same, so you can correlate any change in statuses with a lengthening of a particular type of response time.

    View recent changes in the statuses or response times

    For example, if you find that at certain times every day, the network time increases significantly, you can troubleshoot the network slowdown at those times, and whether the problem is limited to a single location by viewing the Business Locations section of the dashboard.

  7. Step 7 To isolate the times of slow performance, view the application's recent CPU usage in the CPU section, and its RAM usage in the Memory section.

    These readings are available in hourly slots during the dashboard's timeframe.

    For example, if the Trends section shows a spike in the response times, due to an increase in client time (dark blue), you can check the CPU and Memory sections to see if this is caused by a spike in the application's usage of CPU or memory at the same times.

    Check CPU and memory usage of this application
  8. Step 8 After you isolate a likely cause, select that element and view its activity response times in the Activities section, and its recent trend in performance in the Trends section.
    Isolate the concentration of problems and select to view the activities and trends

    For example, you can see if certain departments, locations, device types, or any of the other attributes where the poor response times seem to concentrate themselves, and use this as a clue to further isolate the problem. You can also determine if the poor response time is mostly due to its client, network or server times. If there was a pattern to the timing of that activity's performance slowdown, this would be clearly visible in the Trends section.

  9. Step 9 For a single activity and/or time period, you can drill down to the following dashboards for further investigation:
  10. Step 10 You can jump straight to related dashboards using the tabs at the top of the screen:
    Quickly jump to other application use cases from Troubleshoot Application
    Field Description
    Monitor

    Jump to the Monitor Application dashboard for this application.

    Validate Change

    Jump to the Validate Application Change dashboard for this application.

    Aternity automatically configures the change time to be at midnight just prior to the timeframe of this dashboard.

  11. Step 11 You can limit the display of the dashboard using the menus at the top of the window.
    Select the data to display in the dashboard
    Field Description
    Timeframe

    You can change the start time of the data displayed in the dashboard in the Timeframe menu in the top right corner of the dashboard.

    You can access data in this dashboard (retention) going back up to 30 days. This dashboard's data refreshes every five minutes.

    Activity

    Displays the data concerning only one activity in all the sections of the dashboard.