Page tree
Skip to end of metadata
Go to start of metadata

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

  • To perform this procedure, you must have Application Operator-level access, or higher.

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.

  1. From the navigation pane in the TrueSight console, select Monitoring > Applications.
  2. 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

  1. 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.
  2. 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.
  3. 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

    TierDescriptionReference
    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 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.

    1

    The information presented by the tiers is based on monitoring data from the App Visibility agents.
    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

SeverityIconDescription
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)NoneNo data was collected, or no members are associated with the tier.

Where to go from here

Related topics

Viewing the details of an application

Viewing event thresholds (SLAs) of applications

Investigating application issues reported by synthetic health events

Viewing an application model


 

 

3 Comments

  1.  

    1.  

      1.