...
For more information on the anomaly alert timeline and how alerts are updating, please see Anomaly alert timeline explained
The section of the alert immediately following either new [], updated [] or closed [], contains data about the overall alert. In the screenshot above we see that the alert:
is an update
has an overall “medium” severity. The alert severity is a reflection of the overall impact of all the metrics participating in the alert.
has a start date (when the alert was initially triggered).
has “null” as ended. This means that the alert is still ongoing.
has the “updated” timestamp populated. This means that there was an update of the initial alert at this timestamp.
has a unique Id. This Id will be the same throughout the alerts lifecycle until closed.
...
The “items” section contains details about which systems, nodes and metrics that are part of the alert (for Boomi, see Boomi data collector metrics & structure .
a node is a grouping of metrics. In the example over, the metric is in the node “Operating System”.
a system. In the example above, the system is an Atom. The name is derived from where the Atom is hosted, plus its ContainerId. A system can have multiple nodes.
metrics. A node can host multiple metrics, but in the example above, only a single metric on that node has an ongoing anomaly (“Process CPU Load”).
severity. The severity shown per metric does not have to be the same severity as for the alert.
started timestamp. When an anomaly on that metric was first detected.
updated timestamp. When a change in severity last occured.
...