With the Application View, you can monitor the health and performance of an application that is monitored by App Visibility agents. The view helps you pinpoint issues in the application and locate servers where you can begin investigating problems. You can examine and trend server metrics and correlate server issues with application-transaction issues. The Application View helps you diagnose and resolve performance and availability problems with your application; and monitor synthetic transactions to predict application health and user experience.
This topic contains the following topics:
Before you begin
- Ensure that App Visibility components are
installed
and
configured
.
To examine application issues
From the Applications page, you evaluate the impact and severity of events for all your applications. Select one application to closely examine application issues.
- From the navigation pane in the TrueSight console, select Monitoring > Applications.
- Select one application that you want to examine in detail.
If the application is automatically generated, the Application View tab opens by default.
Analyzing a problem in the Application View
The Application View represents the selected application's logical architecture. Each tier represents the aggregated performance and availability data of its member types, as described in the Data displayed in Application View tiers table.
With the Application View, you can pinpoint the application, date, time, and problem that you want to investigate.
Example of the Application View
To pinpoint the time and severity of application issues
- In the Application View, select the time and date that you want investigate:
- By default, the first time you open the Application View, the Live Traffic button is selected and application traffic is updated every five minutes. Click the button, or move the time slider, to stop viewing continual updates and to focus on a specific problem area.
- The timeline represents a 24-hour period. Move the time slider to select a specific 5-minute interval, or click the next or previous arrows to move 5 minutes on the timeline.
- From the Date action menu, select a specific date to display in the Application View.
- Select a problem period on the timeline:
- Move the time slider over a red or orange region of of the timeline.
The color of one or more tiers is the same as the region on the timeline. The timeline color reflects the color of the tier with the most severe issue for the selected five-minute period. (See the description of the tier severity , below.) - Click the next or previous arrows to move the problem picker on the timeline. The color of the arrows indicate the severity of the next or previous problem.
- Move the time slider over a red or orange region of of the timeline.
Select a specific tier, examine the tier member types and problems, and then drill down to further diagnostic data:
Data displayed in Application View tiers
Tier Description Reference User Experience of end users accessing the application. End users are counted by browser cookies.
- Impacted Users (number inside the circle). Number of active end users in the selected five-minute period that are experiencing latency issues or errors that exceed the defined thresholds.
- Colored part of the circle. Ratio of impacted users to total number of users. The color reflects whether the percentage of users experiencing issues exceeds the defined thresholds.
- Total. Total number of active application users in the selected five-minute period
App Visibility Manager adds the BMCTSEUM cookie to the browsers of end users and reads the cookies to monitor user experience.
Select this tier to see data about end-to-end times, AJAX requests, and errors.
The information presented by the tier is based on end-user monitoring data collected through the App Visibility proxy and App Visibility agents.
Analyzing end-user experience with the User tier Synthetic Results of completed synthetic executions based on defined SLA thresholds:
- Impacted Executions (number inside the circle). Number of executions that encountered problems
- Colored part of the circle. Ratio of problematic executions to total number of executions. The color reflects whether the percentage of executions experiencing issues exceeds the defined thresholds.
- Total. Total number of executions completed
Select this tier to see data about executions of synthetic transactions based on SLA thesholds. To see data based on metric rules, see Investigating application issues reported by synthetic health events.
The information presented by the tier is based on monitoring data from the Transaction Execution Adapter (TEA) Agents.
Monitoring synthetic transactions by application Network Experience of end users experiencing issues due to the calculated network latency:
- Impacted Users (number inside the circle). Number of end users experiencing network latency issues that exceed the defined thresholds. The color reflects whether the percentage of users experiencing issues exceeds the defined thresholds.
- Average Latency. Network latency, calculated as the average end-to-end transaction time minus the average aggregated server time
The information presented by the tier is based on end-user monitoring data collected through the App Visibility proxy.
N/A Web and Business Results of servers with transaction problems (latency violations or errors) or server problems (such as CPU, and Memory):
- Impacted Servers (number inside the circle). Number of impacted application servers
- Colored part of the circle. Ratio of impacted application servers to the total number of servers. The color reflects whether the percentage of servers experiencing issues exceeds the defined thresholds.
- Hits per second. Number of hits handled by the servers per second. The type of hit depends on the type of application server, for example, HTTP requests received by a web server, or messages received by a messaging server.
Select one of these tiers to see data about web servers and application servers that fulfill business needs.
The information presented by the tiers is based on monitoring data from the App Visibility agents.The assignment of an application server as a Web or Business tier depends how App Visibility Manager recognizes most of the transactions on the server:
- Web: A monitored server where most transactions are Transaction-type requests, that is, the server is the first to receive transaction requests within an application. For example, a web server that mostly receives end-user transaction requests, or a server that mostly receives requests from a non-monitored component (such as a PHP server), is recognized as a Web tier.
- Business: A monitored server where most transactions are Request-type requests, that is, the server receives most requests from a monitored server.
For information about transaction types, see Analyzing business transactions.
Investigating problems with Web and Business tiers Database Number of database instances that impact one or more transaction, causing latency violations or errors:
- Impacted Databases (number inside the circle). Number of impacted database instances
- Colored part of the circle. Ratio of impacted database instances to total database instances. The color reflects whether the percentage of databases experiencing issues exceeds the defined thresholds.
- Operations per second. Number of database queries and operations per second
Select this tier to see data about database operations.
The information presented by the tier is based on monitoring data from the App Visibility agents.
Analyzing database problems with the Database tier 1 Sometimes, background requests such as Remote Method Invocation (RMI) are monitored as if they are received from a non-monitored component. For example, in WebLogic, when you deploy and define an EJB client and server, a background process records the server-side communication. If the background requests continue for some time without new transactions requests, the server tier changes from Business to Web.
Tier severity
The severity of each tier represents the severity of performance and availability events from the tier's member types. The severity is determined by the highest severity of the members of the tier, and the severity of the member is determined by the highest severity of its performance and availability events. For example, if a tier has three members at the minor level, and one member at the critical level, the tier is displayed as critical.
The following table describes the severity of each tier:
Application View severity
| Severity | Icon | Description |
|---|---|---|
| Critical (red) | At least one member of the tier had at least one metric that exceeded the defined Critical SLA threshold. | |
| Minor (orange) | At least one member of the tier had at least one metric that exceeded the defined Minor SLA threshold . | |
| OK (green) | No members of the tier have any metrics which exceed defined SLA thresholds. | |
| No data (gray) | None | No data was collected, or no members are associated with the tier. |
Where to go from here
- Analyzing end-user experience with the User tier
- Analyzing user transaction details
- Investigating problems with Web and Business tiers
- Analyzing database problems with the Database tier
Related topics
Viewing the details of an application
Viewing event thresholds (SLAs) of applications
Investigating application issues reported by synthetic health events
Overview
Content Tools
Apps
Reporter Replacement
com.bmc.atlassian.bmc-util-plugin-2.section.label
Tasks
3 Comments
Bao Phac Do
Sara Kamen
Harihara Subramanian