Anomaly-Based Alerting in SolarWinds Observability Self-Hosted
For SolarWinds Observability Self-Hosted Advanced customers, we’re excited to announce the availability of Anomaly-Based Alerting, which leverages our cloud-based AIOps service. Anomaly-Based Alerting improves on standard SolarWinds Observability Self-Hosted alerting. It leverages machine learning to reduce the amount of "alert noise" that can happen for alerts that are solely based on static thresholds - even when small deviations that might trigger an alert are often expected.
Anomaly-Based Alerting requires a SolarWinds Platform server with an active SolarWinds Observability Self-Hosted Advanced license (non-evaluation) connected via Platform Connect to a SolarWinds Observability SaaS account. You can start a free trial of SolarWinds Observability SaaS to enable you to generate the token required by SolarWinds Observability Self-Hosted to send the metrics to the linked cloud tenant. After Platform Connect has been set up, only an active SolarWinds Observability Self-Hosted Advanced license is needed to use Anomaly-Based Alerts - an active SolarWinds Observability SaaS license is not required.
Initial setup for Anomaly-Based Alerts
To use Anomaly-Based Alerting, you first need to connect your SolarWinds Platform server with an active SolarWinds Observability Self-Hosted license to SolarWinds Observability SaaS with Platform Connect.
If you've already enabled Platform Connect, you can go straight to creating an Anomaly-Based Alert. If you have not already enabled Platform Connect, you will be directed to the Platform Connect setup wizard the first time you navigate to Anomaly-Based Alerts in the SolarWinds Web Console.
Alternatively, you can enable Platform Connect separately by navigating to Settings > All Settings, scroll down to the Platform Connect section > Add/Edit Platform Connector. Follow the on-screen instructions to set up Platform Connect.
Create an Anomaly-Based Alert
You can create Anomaly-Based Alerts through a wizard with a similar look and feel to the standard SolarWinds Observability Self-Hosted alerting.
In the SolarWinds Platform Web Console, navigate to Alerts & Activity > Anomaly-Based Alerts. This option will only be visible if you have an active SolarWinds Observability Self-Hosted Advanced license.
The wizard will guide you through the process. Select the Entity Type and Entities you want to alert on and the conditions under which the alert should trigger.
Anomaly-Based Alerts can now be created using an OR operator to alert when any conditions are met. This is in addition to the existing AND operator, allowing more flexible alert conditions.
Anomaly-Based Alerting training period
Before an Anomaly-Based Alert can take advantage of its anomaly-detection capability, it has to spend some time training. Anomaly-Based Alerts begin this training period immediately after creation, and the amount of time the training takes depends on the metric selected. This can take up to a few hours.
By default, an Anomaly-Based Alert will not trigger until the training period has completed. If you would like the alert to trigger based on the conditions you have configured, even if the training period has not completed, or if the Anomaly Detection Service is down or otherwise not available, you can check the “Trigger alert if conditions are met but metrics are not trained or Anomaly Detection Service is down” checkbox when creating the alert.
Note that Anomaly-Based Alerts triggered with this box checked while the training period has not yet completed or if the service is not available will function as a normal SolarWinds Platform alert that does not take advantage of anomaly detection functionality. After training has completed, Anomaly-Based Alerts that were created with this box checked will take full advantage of Anomaly Detection as long as the service is available.
What kind of entities does Anomaly-Based Alerting work with?
When creating an Anomaly-Based Alert, we only show the supported entity types that work with Anomaly detection. Anomaly-Based Alerts can be used with certain supported metrics. In 2022.4, we support network node metrics being sent to the SolarWinds AIOps service in SolarWinds Observability Saas via Platform Connect.
Anomaly-Based Alerts can now be defined for use with Linux and Windows servers, which now appear in the server filter during the entity selection step of the Anomaly-Based Alert creation flow. The supported metrics for Linux and Windows servers are CPU, memory, response time, and packet loss. Windows workstations are not supported.
Managing Anomaly-Based Alerts
You can manage Anomaly-Based Alerts in the same way that you would manage other SolarWinds Platform alerts using the standard SolarWinds Platform alerts interface. In the SolarWinds Platform Web Console, navigate to Alerts & Activity > Alerts. Then click Manage alerts.
Learn more about modifying alerts in the SolarWinds Platform Web Console.
Viewing Anomaly-Based Alerts
To see triggered Anomaly-Based Alerts, click Alerts & Activity > Anomaly-Based Alerts. Filter alerts by alert status or node status, and see all relevant Anomaly-Based Alerts that have triggered.
Anomaly-Based Alerts status view
Anomaly-Based Alerts detail view
With SolarWinds Observability Self-Hosted 2023.1 and later, click an anomalous alert on the timeline to see additional information on the right-hand side of the screen, such as normal operating ranges (NOR) for the time intervals and associated metric value to give you greater context for why an alert is considered anomalous.
Frequently asked Data security questions for using Anomaly-Based Alerts
What is sent from Platform Connect for system and networking configurations when using Anomaly-Based Alerts?
The following table lists the supported entities and shows what kind of information is sent as a metric from the SolarWinds Platform to SolarWinds Observability SaaS for each of those entities.
Learn more about standard network device metrics in SolarWinds Observability SaaS.
| Entity | Metric | Metric tags sent with metric data to SolarWinds Observability SaaS | Description |
|---|---|---|---|
| Node | Average CPU Utilization | sw.collector.CPULoad.AvgLoad
|
Average CPU usage of a monitored node. Displays as a percentage. |
| Average Memory Utilization | sw.collector.CPULoad.AvgPercentMemoryUsed
|
Average memory usages of the monitored node. Displays as a percentage. | |
| Average Response Time | sw.collector.ResponseTime.AvgResponseTime
|
The average time in milliseconds it takes the monitored node to respond. | |
| Packet Loss | sw.collector.ResponseTime.PercentLoss
|
The packet loss of the monitored node. Displays as a percentage. | |
| IP Address | sw.collector.Nodes.IPAddress
|
The IP address of the monitored node. | |
| DNS | sw.collector.Nodes.DNS
|
The DNS record of the monitored node. | |
| System Name | sw.collector.Nodes.SysName
|
The system name/hostname of the monitored node. | |
| Node Name | sw.collector.Nodes.Caption
|
||
| Contact | sw.collector.Nodes.Contact
|
The contact information originating from SNMP, WMI, API, or Agent polling. This might contain sensitive information depending on the configuration of the monitored nodes. | |
| Location | sw.collector.Nodes.Location
|
The location information originating from SNMP, WMI, API, or Agent polling. This might contain sensitive information depending on the configuration of the monitored nodes. | |
| Virtual Cluster | Average CPU Load | sw.collector.virtualization.ClusterStatistics.AvgCPULoad
|
Average CPU utilization of a virtual cluster instance or instances. Displays as a percentage. |
| Average Percent Memory Usage | sw.collector.virtualization.ClusterStatistics.AvgMemoryUsage
|
Average memory usages of the virtual clusters. Displays as a percentage. | |
| Virtual Host | Average CPU Load | sw.collector.virtualization.HostStatistics.AvgCpuLoad |
Average CPU usage of a virtual host instance or instances. Displays as a percentage. |
| Average Percent Memory Usage | sw.collector.virtualization.HostStatistics.AvgMemUsage
|
Average memory usages of the virtual hosts. Displays as a percentage. | |
| Average Network Utilization | sw.collector.virtualization.HostStatistics.AvgNetworkUsageRate
|
Average network usage of the virtual hosts. Displays as a percentage. | |
| Virtual Machine | Average CPU Load | sw.collector.virtualization.VMStatistics.AvgCPULoad
|
Average CPU usage of a virtual machine instance or instances. Displays as a percentage. |
| Average Percent Memory Usage | sw.collector.virtualization.VMStatistics.AvgMemoryUsage
|
Average memory usages of the virtual machines. Displays as a percentage. | |
| Average IOPS Read | sw.collector.virtualization.VMStatistics.AvgIOPSRead
|
Average rate of read records of all virtual machines on node. | |
| Average IOPS Write | sw.collector.virtualization.VMStatistics.AvgIOPSWrite
|
Average rate of write records of all virtual machines on node. | |
| Average IOPS Total | sw.collector.virtualization.VMStatistics.AvgIOPSTotal
|
Average rate of read and write records of all virtual machines on node. | |
| Average Network Usage Rate | sw.collector.virtualization.VMStatistics.AvgNetworkUsageRate
|
Average network usage of the virtual machines. Displays as a percentage. | |
| Network topology | N/A | N/A | This data is not sent. |
| Security configurations | N/A | N/A | |
| Admin credentials | N/A | N/A |
What data is stored in the Cloud when using Anomaly-Based Alerting?
Anomaly detection only uses time series metrics data. The data is associated with organization ids and entity ids as appropriate for detecting anomalies but is not mapped in any specific or personally identifiable way.
How long is the data stored in the Cloud?
Any historical data used for Anomaly detection calculation is stored for a maximum of 21 days.
Is any Personally Identifiable Information (PII) stored?
No. Personally Identifiable Information is never stored.