Anomaly Detection

Anomaly Detection Summary

Purpose: This section is designed to give you a high level overview of anomalous spend in your account in the form of a dynamic list of anomalies from system default rules or custom anomaly alert rules that you configure.

The Meters:

• Total Anomalous spend:
  • Over the expected range: Amount of cost associated with anomalies that are above your normal spend pattern
  • Under the expected range: Amount of cost associated with anomalies that are below your normal spend pattern
• of alerts triggered: Number of alerts triggered over the selected time period
• % of total spend: Percentage of your total spend that the amount of the anomalous spend represents $ of anomalous spend / $ of total spend in all projects

Before digging in further into the recommendations, it's useful to know how Ternary classifies Anomalies:

• Ternary essentially looks for anomalous spend within a certain category of spend ie compute, analytics etc. as well as anomalous spend within projects.
• We also allow you to create custom anomaly alert configurations which will be detailed later in this article

Anomaly Table

Measures:

• Source Alert Rule: The rule that generated the entry for the particular row
• Event Type: Type of event detected (currently, we support "Anomaly Detected" but expect to add additional categories of alerts
• Expected Range: The expected dollar range of spend, grouped by the dimension, based on previous 180 days of spend
• Actual Value: The actual dollar amount of spend that occurred which resulted in the anomaly
• Delta: Actual Value - Expected Range = Total delta in dollars
• Alerted At: When the alert was generated in Ternary
• Occurred At: The date when the anomaly actually occurred in the billing data. You can set the lookback period up to 90 days so you may see entries as old as 90 days after configuring a new rule.

View Alert Details:

When you click the ellipsis you can see additional details of the alert.

In this example, of a particular alert, you can see the Service that generated the alert because the rule was built to group data by Service Description.

Measures

• First Detected: Date the first time the anomaly was detected, in Ternary.

• Time of Anomaly: Date the anomaly actually occurred (in this case, we created a rule and set the lookback period to 30 days so it generated anomalies that would have been caught had this rule been configured previously

• Dimension Grouping (in this case, serviceDescription): The dimension that was used to group the data and look for anomalies. For example, skuDescription, serviceDescription, projectId, etc.

  Alert Rule Configuration

Creating an Alert Rule

Configuration Fields:

• Name: Name you create for the rule. We suggest using something descriptive such as "Ryland - $100 - Non-Production by Service" to describe what the rule is analyzing so others understand at a glance
• Cost or Percentage: Amount of cost you want to alert on such as $25, $100, $1000, etc. This is the threshold at which an anomaly will be generated based on the deviation outside the expected range. You can also select percentage to use a percentage deviation
• Granularity: You can set this to Day, Hour, Minute
• Direction: You can look for both Increases and Decreases, Increases only or Decreases only
• Lookback Days: The amount of days the rule will lookback to generate things that previously would have been identified had the rule been configured. 90-days is the maximum value for lookback days.
• Filters: Billing Accounts, Project IDs, Services and SKUs act as filters to filter the data set down that you want to analyze. For example, you can select a subset of projects, services or SKUs to filter the data set down too. We have customers, for example, who have created a rule to filter down to Production or Non-Production spend in separate rules as their threshold for production may be larger than non-production.
• Group By: After the data set is filtered down, the include labels field defines how the data is grouped by dimensions. You can use a label you have in your GCP environment, fields from the billing file, ternary specific dimensions and custom labels. For example, you may want to see deviations grouped by service. You would add serviceDescription to the include labels field.
• Subscribers: These are the individuals who will be notified when an alert is generated via e-mail. You can click edit subscribers to add or remove users. You also have the option to subscribe non-Ternary account e-mail addresses. For example, if you had executives who did not have an account in the tool or a distribution list you wanted the e-mail to go to.

Other Useful Functionality

Export Anomalies: Export the current Anomalies as a CSV