Policies

Policies enable you to configure AppResponse to detect and alert you when logical network objects exhibit traffic or performance behavior that is noteworthy or otherwise merits examination. Some examples of logical network objects are an IP address, an IP conversation representing the interaction of two IP addresses over the network, a web server, a database server, etc. Policies enable you to specify conditions on the behavior of network objects (i.e., on metric values). When those conditions are met, the policies generate violations. You can review these violations in the web UI and, optionally, configure notifications so that external systems can be informed when these violations occur.

AppResponse furnishes dedicated packet analysis features that analyze traffic to detect the presence of specific types of network objects and calculate feature-specific metrics for each of those objects.

◼ See Application Stream Analysis (ASA) Metrics for the list of network objects that are tracked by the ASA module and the metrics it calculates for each object.

◼ See Web Transaction Analysis (WTA) Metrics for the list of network objects that are tracked by the WTA module and the metrics it calculates for each object.

◼ See Database Analysis (DBA) Metrics for the list of network objects that are tracked by the DBA module and the metrics it calculates for each object.

◼ See Unified Communications Analysis (UCA) Metrics for the list of network objects that are tracked by the UCA module and the metrics it calculates for each object.

Each feature analyzes network traffic, detects the presence of network objects in the traffic, calculates a set of feature-specific metrics for each object, and stores the network object and its corresponding metric information every minute. Policies allow you to specify conditions only on the 1-minute metric values that are calculated for network objects; therefore, a policy is always checking the most recent 1-minute value of a metric for an object against a user-specified or built-in policy condition. AppResponse provides a number of Built-In Policies that track changes in common network behaviors used often by IT/network operations to track how well a network is doing its job. Most of the built-in policies are enabled by default.

AppResponse enables you to define your own policies, also. You can have up to 750 user-defined policies. The Policies page shows the number of active policies that are defined out of the maximum allowed 750.

Once a policy has been defined, you can edit it to place additional conditions on the traffic it monitors, to change the violation criteria, to add notification recipients, and so on. A policy is Enabled by default.

Policies support two types of metric comparisons: static and adaptive.

A static policy uses discrete trigger criteria for one or more metrics. When the value of a metric matches or exceeds a discrete threshold, an alert is sent to the recipients. All metrics support static policies. One example of a policy with a static condition is:

Host Group Denver should be in Minor violation state when the total throughput to Denver’s IP addresses exceeds 25 Mbps, in a Major violation state when the total throughput exceeds 50 Mbps, and in Critical violation state when total throughput exceeds 75 Mbps.

This is a static policy because the violation state is determined by applying user-defined static thresholds for metric values, i.e., the latest current-minute metric value of Total Throughput for HG Denver is compared against the static threshold values for Minor (25 Mbps), Major (50 Mbps) and Critical (75 Mbps) configured by the user.

An adaptive policy uses relative trigger criteria for one or more metrics. When the value of a metric deviates by a specified factor from what is normal for that time period, an alert is sent to the recipients. Not all metrics support adaptive policies. One example of a policy with an adaptive condition is:

Web User Group San Francisco should be in Minor violation state when the average Page Time experienced by the users in San Francisco across all web apps deviates from normal by one standard deviation, in Major violation state when the deviation is two standard deviations, and in Critical state when the deviation is three standard deviations.

This is a adaptive policy because the violation state is determined by assessing the extent to which the current-minute metric value has changed from an autocomputed normal value. In other words, the current-minute metric value is compared to a autocomputed normal value that adapts over time.

2. Click Add to open the Create New Policy wizard. The wizard provides four pages for defining the policy, listed in the pane at the left of the wizard. Complete each page in order:

◼ General Properties - The name and description of the policy, as well as its comparison type (Static or Adaptive), and whether it is Enabled or not.

◼ Alert On & Filtering Properties - The traffic objects or attributes the policy monitors. Each object you want the policy to monitor must exist before you create the policy. For example, entities such as Host Groups and Preferred Applications must be defined before you can include them in a policy definition.

◼ Trigger Properties - Define the thresholds for triggering alerts. For static policies, these are discrete thresholds; for adaptive policies, they are relative thresholds.

◼ Notification Properties - The person or system to be notified when a policy violation triggers an alert. This can be a notification recipient that you’ve defined previously, or an ordinary Email address.