Key Performance Indicator (KPI) Dashboard

Overview

Service level agreements (SLAs) are contracts for the delivery of a specified level of service, and connect IT more directly to the service requirements of businesses or customers. Successful SLAs consist of one or more very clear service level objectives that define the level of service covered by the overall agreement and must be measurable and achievable by the IT organization. To manage SLAs successfully, IT must construct and manage a meta-view of component behavior based on the impact on service levels. The AVIcode KPI Dashboard allows Operations personal to set and monitor SLA and OLA thresholds for overall application metrics and for specific application business functions metrics. Specific business functions can be defined based on specific ASP.NET pages, Web Service methods, or individual application methods.

AVIcode's .NET Management Pack enables organizations to create and monitor custom key performance indicators (KPIs), including the state of individual business transactions. For example, KPIs can be configured for average transaction execution time, number of calls per second, application failure rates, and performance degradation rates, along with any other business actions on a Web page, Web service method, or application function.

For additional insight into KPIs and business transactions, the .NET Management Pack can aggregate data across multiple computers and multiple application instances. In addition, it can calculate a baseline over time and compare actual application behavior with that baseline. By customizing Operations Manager rules, performance indicators that fall above or below baseline automatically trigger a health state and notification, providing proactive alerting to changes within the application environment.

The .NET Management Pack presents this data in a new KPI Dashboard that provides real-time reporting on application health state, computer health state, monitor key performance indicators and their performance versus baseline data. This information can also be made available within a custom view inside the Operations Manager console, such as AVIcode's application state summary view.

In addition, monitoring KPIs and developing a baseline for application behavior -- based on actual user load as opposed to synthetic transactions -- provides insight into trends that influence capacity planning. This provides organizations with a reliable tool, based on real-world usage, for hardware and other application environment planning needs.

Along with the .NET Management Pack's ability to gather root-cause data for application failures and performance bottlenecks, organizations can leverage KPI and transaction monitoring to enable a better means for quickly detecting and resolving problems in .NET application environments. AVIcode's new .NET Management Pack complements Microsoft's Service Level Dashboard Management Pack by enabling the definition and collection of key performance indicators and health state transition rules. This means organizations can better monitor and manage the applications that are critical to their business success.

Opening the Dashboard

Select one or more Distributed Application Object(s)

Select one or more Application Instance Object(s)

From the Operations Manager Reporting Tab

Understanding the Dashboard

Functionality State

For example, suppose that you have 8 monitored entities: The application monitor and transaction monitors #1, #2, #3, #4, #5, #6 and #7, so each functionality set is 12.5% of the total functionality. The pie diagram could display the following situation: The application is not monitored (12.5 % white), transaction sets  #1 and #2 are healthy (%25 green), transaction sets #3, #4and #5 are in a warning state (37.5% yellow), and transaction sets # 6 and #7 are in an error state (%25 red)

Application and transaction (to Web pages, Web Services or functions) functionality is measured via application load (or transaction usage as applicable) using any or all of these counters: Average Request Time exceeds threshold, Number of Monitored Requests/sec exceeds threshold, % Performance Events/sec exceeds threshold, % Exception Events/sec exceeds threshold. 

The functionality of monitored entities (application and transactions) is also measured via problem counts using any or all of these counters: Number of Connectivity Events exceeds error threshold or warning threshold, Number of Exception Events exceeds error threshold or warning threshold, Number of Performance Events exceeds error threshold or warning threshold, Number of Security Events exceeds error threshold or warning threshold. 

The instance state becomes unhealthy if the counter exceeds the configured threshold during the configured interval.

This count includes alerts that may have been auto-resolved by Operations Manager timeout. Therefore, this number may be larger than the number of active alerts displayed in the Alert View.

Clicking on the Functionality State pie chart opens the availability report. The Availability Report contains details for each of the functionality sets for the last 24 hours. This report displays availability uptime and downtime as both percentages and in hours:minutes:seconds.

Application Monitoring

For example, suppose that the selected application is being monitored on 8 servers: servers #1, #2, #3, #4, #5, #6, #7 and #8, so each application instance is 12.5% of the total instances. The pie diagram could display the following situation: The instance on server #1 is not monitored (12.5 % white), instances on servers  #2 and #3 are healthy (%25 green), instances on servers #4, #5and #6 are in a warning state (37.5% yellow), and instances on servers #7 and #8 are in an error state (%25 red)

This list will always contain, by default, the following counters: Monitored Requests/sec, Avg. Request Time, % Exception Events/sec and % Performance Events/sec. Any custom performance counters that have been added will also be displayed, either for a single selected instance or all instances (if 'Include all instances for the selected counter' was selected on the 'Application Monitoring' tab).

Note that counters which are aggregated from across multiple servers may have different aggregation algorithms applied. Monitored Requests/sec and Calls/sec use SUM, all other default (non-custom) counters use AVERAGE, and custom counters use the algorithm that was selected during the configuration process (SUM, MIN, MAX or AVERAGE)

Availability Report

Clicking on the Application Monitoring pie chart opens the availability report for the selected application. This report displays application availability uptime and downtime as both percentages and in hours:minutes:seconds.

Performance Report

Clicking on the functionality chart for any of the counter names opens the standard performance report, which includes 4 charts for every counter for all instances for the last 24 hours.

Transaction

Each transaction monitor has a separate section in the transaction table, and each represents a portion of the total functionality in the Functionality State pie chart. Additionally, each transaction monitor

Note that counters which are aggregated from across multiple servers may have different aggregation algorithms applied. Monitored Requests/sec and Calls/sec use SUM, all other default (non-custom) counters use AVERAGE, and custom counters use the algorithm that was selected during the configuration process (SUM, MIN, MAX or AVERAGE)

Availability Report

Clicking on the pie chart for a selected transaction opens the availability report. This report displays availability uptime and downtime as both percentages and in hours:minutes:seconds.

Performance Report

Clicking on the functionality chart for any of the counter names opens the standard performance report, which includes 4 charts for every counter for all instances for the last 24 hours.

Computer State

Availability Report

Clicking on the pie chart for a selected computer opens the availability report. This report displays availability uptime and downtime as both percentages and in hours:minutes:seconds.

Trend Graphs

Trend graphs are automatically displayed for Application Monitored Requests/sec and Avg. Request Time. If 'Show trend in dashboard' has been selected, then a more detailed graph will be displayed will also be displayed. To check if this option has been selected:

Note that counters which are aggregated from across multiple servers may have different aggregation algorithms applied. Monitored Requests/sec and Calls/sec use SUM, all other default (non-custom) counters use AVERAGE, and custom counters use the algorithm that was selected during the configuration process (SUM, MIN, MAX or AVERAGE)

Changing Dashboard Parameters

Report settings may be changed to modify parameters such as the report time of time zone. To access the parameters:

Parameters include:

Last update: Tuesday, June 08, 2010 03:19:09 PM