Detecting anomalies by using static and dynamic thresholds

Anomalies are observations that diverge from a well-structured data pattern or an irregular spike in the time-series data or unclassifiable data points within a specific data set. An anomaly could occur independently or due to a combination of factors. For example, the combination of slow response time and high memory utilization together may impact the expected system behavior. 

As an administrator, create alarm and variate policies to help you monitor and manage the health of your system and detect anomalies. These policies can also help you detect abnormal behavior in your monitoring data more accurately by reducing:

• False positives: Scenarios where an alarm is raised even though the system exhibits normal behavior. 
• False negatives: Scenarios where the product failed to raise an alarm despite the occurrence of an abnormal metric condition.

Alarm policies use a combination of static and baseline thresholds, and variate policies use dynamic thresholds. In the monitoring world, a threshold is a defined value that determines whether a monitored metric, such as CPU utilization or memory usage, is above, below, or within a normal range in your infrastructure environment.

Static thresholds represent an absolute value above or below which an event is generated. In general, a static threshold is specified for attributes that have commonly accepted values, beyond which performance is known to degrade. For example, if the total CPU utilization of a Windows system is greater than 80%, performance degradation can occur.

Dynamic thresholds contain a set of low and high baselines, which are automatically generated. Users don’t need to manually set the threshold value. Dynamic thresholds can be used for attributes that degrade over time, for example, performance metrics such as response time.

Alarm policies

Alarm policies use the following threshold combinations to detect anomalies:

• Static thresholds only
• Baseline thresholds only
• Static and Baseline thresholds

Example scenarios for alarm policies

This section provides a few examples of alarm policies.

Scenario 1 - Static threshold

If the CPU Utilization crosses the threshold of 75% for 15 minutes, and if it violates the baseline determined for that event, an alarm event must be generated.

Scenario 2 - Static threshold

The storage server's power supply is degraded for more than 15 minutes, the service will be impacted and an event alert must be generated.

Scenario 3 - Static threshold

An Apache tomcat server's availability is offline or unavailable for more than 15 minutes, the service will be impacted and needs an alarm notification.

Scenario 4 - Baseline threshold

A Linux server's CPU utilization violates the baseline value, so an event alert of the Alarm class must be generated. This alert can have one of the following severity levels:

• Information
• Critical
• Major
• Minor
• Warning

Variate policies

As an administrator, create variate policies to receive event notifications. Variate policies use dynamic thresholds. Use these policies when you want to be alerted for metric anomalies where the threshold limits keep changing over time. The following table provides a few example scenarios for variate policies.

For more information, see variate policy concept and instructions for configuring a variate policy.

Example scenarios for variate policies

This section provides a few examples of variate policies.

Scenario 1

Under normal circumstances, a busy server might utilize 70% of its CPU without causing any concern. However, a relatively underutilized server that utilizes 50% of CPU capacity could indicate an issue.

Scenario 2

Use variate policies to analyze anomalies for a group of metrics together. All the metrics in a multivariate configuration are analyzed at the same time and contribute to a single anomaly score. A single anomaly event is generated based on that score.

Metrics for static thresholds

To see the static threshold metrics, use the Manage Metrics link on the Manage Auto Anomaly page. For more information, see Configuring autoanomaly event generation.

• Generate autoanomaly events for low baseline violations
• Generate autoanomaly events for high baseline violations
  This is the default configuration.
• Generate autoanomaly events for low and high baseline violations
• Do not generate autoanomaly events

Metrics for dynamic thresholds

The metrics for dynamic thresholds are configured to generate autoanomaly events for high baseline violations by default.