Alerts
Different anomalies on a single time series are grouped in an alert containing several nodes, to give a bigger context to each anomaly and also to reduce the number of alerts sent to the user. Time series that are in the same node are already considered related, so they will always be alerted together. To capture inter-node relations we are using the groups created by using correlations among nodes. Time series which belong to nodes in the same group are alerted together.
Nodes that have at least one metric with an anomaly that reaches a certain score are included in an alert. The alert is customizable to alert on different criticalities: yellow, orange, or red. As more time series are added to the alert the user is re-alerted by using an alerting formula. The alert formula takes into consideration not only how many nodes in a group have anomalies of a certain criticality, but also how many time series have reached that criticality in each of the nodes. As the alert grows not all the single metric anomalies are immediately re-alerted, but they are alerting in growing batches.
Anomaly alert timeline explained
An anomaly alert will always have the following events:
- Alert started (=1)
- Alert updated (>=0)
- Alert closed (=1)
For instance, we can start an initial anomaly alert with the timestamp 2024-01-04T03:55:00Z, and only HeapMemoryUsage is affected. At 2024-01-04T04:30:00Z, an anomaly alert update is made, which now also includes AverageExecutionTime. At 2024-01-04T04:47:00Z, an anomaly alert is closed, meaning that both metrics are back within their normal ranges, and the alert is ended.
All alerts will contain fields for the started timestamp and the last updated timestamp (updates can also include the closed timestamp as it is an update).
We recommend that you use both the from/to parameters when checking for anomaly alerts with the Eyer Partner Connector. Depending on the alert timeline and the time range of the query, the response can return different responses, as seen below.
