Anomaly Detection Alerts
Anomaly refers to an outlier in a given data set polled from an environment. It is a deviation from a conformed pattern. Anomaly detection is about identifying these anomalous observations. A set of data points collectively, a single instance of data or context-specific abnormalities help detect anomalies. For example, unauthorized copying of a directory from a container, high CPU or memory consumption, and so on.
Define an Anomaly Detection Alert
Set a unique name and description: Set a meaningful name and description that help recipients easily identify the alert
Severity: Set a severity level for your alert. The Priority:
Infoare reflected in the Alert list, where you can sort by the severity by using the top navigation pane. You can use severity as a criterion when creating events and alerts, for example: if there are more than 10 high severity events, notify.
Specify multiple segments: Selecting a single segment might not always supply enough information to troubleshoot. Enrich the selected entity with related information by adding additional related segments. Enter hierarchical entities so you have the bottom-down picture of what went wrong and where. For example, specifying a Kubernetes Cluster alone does not provide the context necessary to troubleshoot. In order to narrow down the issue, add further contextual information, such as Kubernetes Namespace, Kubernetes Deployment, and so on.
Select one or more metrics whose behavior you want to monitor.
Filter the environment on which this alert will apply. An alert will
fire when the value returned by one of the selected metrics does not
follow the pattern in the availability zone,
You can also create alerts directly from Explore and Dashboards for automatically populating this scope.
Trigger gives you control over how notifications are created and help prevent flooding your notification channel with notifications. For example, you may want to receive a notification for every violation, or only want a single notification for a series of consecutive violations.
Define the threshold and time window for assessing the alert condition. Supported time scales are minute, hour, or day.
If the monitored host or Kubernetes cluster is not available or not responding for the last 5 minutes, recipients will be notified.
You can set any value for % and a value greater than 1 for the time window. For example, If you choose 50% instead of 100%, a notification will be triggered when the entity is down for 2.5 minutes in the selected time window of 5 minutes.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.