Current view: XPLG V7 (Latest). Available: XPLG V6 and XPLG V5

Skip to end of metadata
Go to start of metadata

Synopsis

The anomaly function used a set of Anomaly Algorithms to filter out "normal" events and display outstanding ones.
The anomaly function expects a set of values, process it and displays only event which were out of the normal behavior. The result set includes:
Anomaly Name = the specific algorithm that returned an anomaly
Anomaly Time = the time in which the anomaly was detected
Anomaly Description = the details about the changes of values that led into conclusion that there is an anomaly
Confidence = the level of certainty of the detected anomaly based on the algorithms used
Anomaly Change = the change value between normal state and the anomaly identified event
Anomaly Value = the final value at the time of the anomaly

 

The following are some of the algorithms the engines use to detect anomalies:

Naive Sigma / Olympic Sigma
A naive seasonal model where the prediction for the next point is a smoothed average over previous n period.

Moving Average Sigma
The forecast is based on an artificially constructed time series in which the for a given time period is replaced by the mean of that value and the values for some number of preceding and succeeding time periods. The weighted moving average and native forecasting model are special cases of the moving average model.

Regression Sigma / Polynomial Regression Sigma / Multiple Linear Regression Sigma - Models the relationship between x & y using one of more variable.

Simple Smoothing Sigma - A popular model used to produce smoothed time series. The double and triple exceptional smoothing variants add trend and seasonality into the model. The model used for experiments automatically picks the best 'fit' exceptional smoothing model.



Syntax

COMPLEX SEARCH THAT AGGREGATES VALUES | anomaly

COMPLEX SEARCH THAT AGGREGATES VALUES = the anomaly engine expects a set of values therefore, a complex search that performs a count and group by <values> with an interval of some time bucketing must be used prior to the anomaly call.

Required Arguments

complex_query that includes count, group by and interval

Syntax: <character string>

Optional Arguments

mergealgorithms:false (default) - by default, the anomaly engine will display the name of the algorithm that detected the anomaly (in this mode there could be, potentially, multiple detections for specific events.
mergealgorithms:true - the anomaly results will be united.

Description

The anomaly engine scans the result model and will display only events that are suspected as out of normal


Examples

Example 1:  

error| count | group by ext.log as Source Log | interval 5 minutes | anomaly mergealgorithms:true| group by Source Log  | order by anomaly change desc

The query looks for events containing error, performs a count per log source in time buckets of 5 minutes, and runs anomaly detection on the result - result is displayed where the highest anomaly value is on top.

Example 2:  

* | count | group by ext.server as Source | interval 5 minutes | anomaly mergealgorithms:true| group by Source | max anomaly value | group by Source | interval 5 minutes

The query runs on all events, performs a count per source server in time buckets of 5 minutes, and runs anomaly detection on the result - result is displayed where the highest anomaly value is on top.

Example 3:  

* in log.access| count | group by URL | interval 5 minutes | anomaly mergealgorithms:true| group by Source | max anomaly value | group by URL | interval 5 minutes

The query runs on all events in access log, performs a count per URL in time buckets of 5 minutes, and runs anomaly detection on the result - result is displayed where the highest anomaly value is on top.

  • No labels