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:
From the Applications page, you evaluate the impact and severity of events for all your applications. Select one application to closely examine problems in the Application View.
If the application is automatically generated, or if synthetic monitoring is activated for a manually added application, then the Application View tab opens on the Application Monitoring page. Otherwise, the application Model tab opens (see Viewing an application model for information).
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 later in this topic.
With the Application View, you can pinpoint the application, date, time, and problem that you want to investigate.
Example of the Application View
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
Experience of end users accessing the application. End users are counted by browser cookies.
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|
Results of completed synthetic executions, :
Select this tier to see data about executions of synthetic transactions.
The information presented by the tier is based on monitoring data from the Transaction Execution Adapter (TEA) Agents.
|Monitoring synthetic transactions by application|
Experience of end users experiencing issues due to the calculated network latency:
The information presented by the tier is based on end-user monitoring data collected through the App Visibility proxy.
Results of servers with transaction problems (latency violations or errors) or server problems (such as CPU, and Memory):
Select one of these tiers to see data about web servers and application servers that fulfill business needs. 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: For information about transaction types, see Analyzing business transactions.
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:
For information about transaction types, see Analyzing business transactions.
The information presented by the tiers is based on monitoring data from the App Visibility agents.
|Investigating problems with Web and Business tiers|
Number of database instances that impact one or more transaction, causing latency violations or errors:
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|
1Sometimes, 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.
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
|Critical (red)||At least one member of the tier had at least one metric that exceeded the defined|
|Minor (orange)||At least one member of the tier had at least one metric that exceeded the defined Minor SLA|
|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.|