Skip to content

Anomaly detection service

You can use the anomaly detection service to identify data points of key metrics that are outside a metric's normal range of values. This service employs an advanced neural network algorithm, deep historical data, and frequent model training to deliver accurate, precise, and near real-time results.

When the service finds enough historical data for a key metric, it starts training a model of the metric. When a new data point arrives, the service compares the data point with the model and then scores it with a value between 0 and 1. A score of 0.0 is 100% normal, and 1.0 is 100% anomalous. Almost all scores have to be greater than 0.99 to be considered anomalous.

Turn on anomaly detection

The anomaly detection service is turned off by default. To turn on this service, file a ticket at Zenoss Support. Data modeling is scheduled to occur on the 1st and 15th of each month. Based on this schedule, you may need to allow up to 14 days before the service starts identifying anomalies.

After you turn on anomaly detection, you can add metrics to the service. See Adding a metric to anomaly detection.

You can use results from the anomaly detection service in the following locations:

  • On the Anomalies tile in Dashboards, view automatically highlighted anomalous entities.
  • In Smart View, view anomaly visualizations and anomaly shields on metric cards.
  • Use anomaly triggers in the Action service.

Adding a metric to anomaly detection

If you want to add a metric so the anomaly detection service trains models on it, perform the following procedures. For these tasks, your account must be assigned the Manager role.

Prerequisites

  • Identify the metric's source type.

    The source may be a Collection Zone, a Kubernetes agent, or any other custom data source in your environment. You don't need the name of the source, just the source type.

  • Identify the metric's name.

    You may know a metric by its display name, which Zenoss Cloud uses in dashboard and Smart View pages when a metric is included in the metric dictionary. For example, the display name for the openstackQueues_perfQueueCount metric is Perf Queue Count.

Process overview

First, determine if a custom anomaly policy exists for your metric's datasource. Then, either edit the existing custom policy or override the default policy.

Determine if a custom anomaly policy exists

  1. Navigate to the ADMIN > Policy page, and then click the POLICIES tab.

  2. In the Type column, select the Anomaly filter.

  3. In the Datasources column, enter the datasource for your metric.

    For example, for Collection Zones, enter cz.

  4. Do one of the following:

Edit an existing custom policy

  1. In the table of policies on the POLICIES tab, identify the custom policy.

  2. In the Actions column of the row of the policy to edit, click the Policy details icon.

  3. Review the list of metrics in the Metric Names list and do one of the following:

    • If the metric to add is in the list, stop.
    • If the metric to add is not in the list, continue with this procedure.

  4. In the Actions column of the row of the policy to edit, click the Edit policy icon.

  5. In the left column of the EDIT POLICY dialog box, click Main details.

  6. Verify that the policy is enabled.

  7. In the Metric field, enter the first few words of the name of the metric to add.

    For example, cpu.time.

  8. From the list of potential matches, select the metric to add, and then click SAVE.

Override a default policy

  1. In the table of policies on the POLICIES tab, identify the policy to override.

  2. In the Actions column of the row of the policy to override, click the Override policy icon.

  3. In the left column of the EDIT POLICY dialog box, click Main details.

  4. Verify that the policy is enabled.

  5. In the Metric field, enter the first few words of the name of the metric to add.

    For example, cpu.time.

  6. From the list of potential matches, select the metric to add, and then click SAVE.