Autoanomalies
Anomalies are observed in the well-structured data pattern. Autoanomalies are automatically generated when a metric violates all baselines and shows metric deviation (in sigma) values for a specific duration.
The following video (2:35) provides an overview of automatic anomaly detection in BMC Helix Operations Management.
The following image illustrates the benefits of enabling automatic anomaly detection versus disabling it:
As an administrator, configure the system to automatically generate anomaly events with a specific severity when a metric violates all baselines and breaches a deviation value in sigma. The baseline of a metric is calculated based on the historical data collected over time.
Configure automatic anomaly event generation for key performance indicators (KPIs) or all performance metrics with fewer manual configurations. Performance metrics monitor the health and performance of a specific device or service.
Performance metrics are a superset that consists of both KPI and non-KPI metrics. For example, the Idle Time (%) of a CPU is a performance metric, and KPI: Utilization (%) of a CPU is a KPI metric.
Metrics are marked as KPIs at the monitoring solutions or Knowledge Module (KM) levels. To learn more about performance and KPI metrics, see Monitoring solutions in BMC Helix Operations Management.
How are the hourly, daily, weekly, and monthly baselines computed
BMC Helix Operations Management uses historical data, including performance metrics, to calculate baselines on an hourly, daily, weekly, and monthly basis. Baseline values are calculated by using the minimum-maximum algorithm. The high baseline value is calculated by using 85% of the maximum value, while the low baseline value is calculated by using 15% of the minimum value. An autoanomaly event is generated when a data point breaches all baselines—hourly, daily, weekly, and monthly. This minimizes the event noise created by autoanomaly events.
The following table provides details about the baselines and how they are calculated.
Baseline | Description |
| Hourly | This baseline is calculated by using data of the same hour from the previous day. For example, to determine the baseline for 10:00 AM today, the calculation projected yesterday from 10:00 AM to 11:00 AM is used. |
| Daily | This baseline is calculated by using data from the previous day. For example, to determine the baseline for today, the calculation projected for yesterday is used. The daily baseline calculation is separate for weekdays and weekends and is calculated internally. By default, Saturday and Sunday are considered as the weekend days. You can configure the weekend by using REST APIs. To learn about configuring weekends by using REST APIs, see the POST global-configuration/weekends URL endpoint at Configuring weekends for calculating the daily baseline. If the monitoring of a device begins on a Saturday, data from the previous day, Friday, cannot be used for projection because it is a weekday. So, to calculate the baseline for Saturday, the system requires at least six hours of data to display on the performance overview graph. |
| Weekly | This baseline is calculated by using data from the same day in the previous week. For example, to determine the baseline for Monday, the calculation projected for the previous Monday is used. |
Monthly | This baseline is calculated by using data from the same date in the previous month. For example, to determine the baseline for February 1, the calculation projected for January 1 is used. |
The following graph shows hourly, daily, weekly, and monthly baselines in different colors with corresponding high and low data point values:
How is an anomaly detected
BMC Helix Operations Management collects the values for a monitor's attributes and performance metrics over a specific time. Historical data is used to determine low and high baseline values for a metric. Baseline calculation begins after six hours of aggregate data is available for a metric.
Anomaly events are automatically generated after a specific duration lapse for the following violations:
- Baseline violation
- Deviation violation
To learn about how sigma deviation works, see Variate-Policies. The anomaly event is automatically closed when the metric value returns to a normal state.
In the following example, an anomaly event generated only when the Traffic_out metric in a network violates the following parameters:
- Metric baseline (High baseline: 14663.847)
- Sigma (3)
The system waits until the metric deviates for 3 sigma before it generates the anomaly. - Duration (6 minutes)
The system waits for 6 minutes before it generates the anomaly.
The anomaly event is automatically closed when the CPU utilization returns to a normal state.
In the Performance Overview tab, if the selected duration is longer than 7 days, the graph shows aggregated data. Because of this constraint, only one data point is displayed every hour and the autoanomaly event icon might not appear in the correct position on the graph.
For durations shorter than 7 days, you can see the actual data in the graph and the autoanomaly event icon appears in the correct position on the graph.