Exposing Helpful Anomaly Detection Metadata from Anomaly Strategies (ie Anomaly Check Range/Thresholds) through backwards compatible function

[arsenalgunnershubert777]

Description of changes:

This PR adds functionality to expose anomaly detection metadata for anomaly checks.

There is a legacy PR here, and this PR addresses feedback to make the anomaly detection metadata functionality backwards compatible.

• AnomalyDetectionExtendedResult is a newly exposed field that contains metadata for anomaly check runs. The user is able to see these details from ConstraintResult.
• The user can see those extended results when using a new addAnomalyCheckWithExtendedResults method in the verification suite builder (instead of addAnomalyCheck)
• The original addAnomalyCheck functionality works the same (though it now internally uses the new detectWithExtendedResults function see point about that below)
• There are the following changes to make this happen
  • First of all a new AnomalyDetectionDataPoint class
    • This class has the following fields:
      • dataMetricValue: The metric value that is the data point.
      • anomalyMetricValue: The metric value that is being checked for the anomaly detection strategy, which isn't always equal to the dataMetricValue.
      • anomalyCheckRange: The range of bounds used in the anomaly check, the anomalyMetricValue is compared to this range.
      • isAnomaly: If the anomalyMetricValue is outside the anomalyCheckRange, this is true.
      • confidence: The confidence of the anomaly detection.
      • detail: An optional detail message.
    • AnomalyDetectionExtendedResult is currently just a wrapper for this AnomalyDetectionDataPoint class.
  • All the anomaly detection strategies extend a new trait called AnomalyDetectionStrategyWithExtendedResults
    • In the batch normal strategy for example, the new detectWithExtendedResults function extends the new trait.
  • The new detectWithExtendedResults function is also updated to be the function that the regular detect function uses after mapping from the AnomalyDetectionDataPoint to the original Anomaly class, since they are using the same underlying calculations. If preferred to keep them independent, I can separate those.
  • Using the detectWithExtendedResults function all the Anomaly Strategies output all the AnomalyDetectionDataPoints with those extra Anomaly details corresponding to all the data points in the search interval via ExtendedDetectionResults
  • The last AnomalyDetectionDataPoint which corresponds to the new metric being checked is passed along the through the following:
    • The new isNewestPointNonAnomalousWithExtendedResults function
    • The new Check.isNewestPointNonAnomalousWithExtendedResults function called by the above
    • The new getNewestPointAnomalyResults function called by the above which returns a new kind of Anomaly assertion function
    • This new anomaly assertion function called by the above returns a new AnomalyDetectionAssertionResult.
    • The new AnomalyDetectionAssertionResult contains both an assertion boolean as well as the AnomalyDetectionExtendedResult wrapping the data point of the newest data point. The assertion boolean is determined from that data point's isAnomaly field.
      • This is different from the previous anomaly assertion function which just returns a boolean, because this allows the passing through of the anomaly detection data point.
    • This new anomaly assertion function uses a new AnomalyExtendedResultsConstraint class to handle the assertion function.
    • In the future if the Anomaly Check focuses on multiple datapoints instead of just one, the AnomalyDetectionExtendedResult can add another field and be adjusted accordingly.
  • The anomaly detection metadata is added to the ConstraintResult class as an optional field
    • Maybe in the future this can be separated into a different class that inherits from a common trait since the AnomalyDetectionMetadata does not pertain to other non anomaly checks, would take a lot more refactoring/changes
  • Tests are updated to reflect the above changes
  • Documentation with links to an example executable is added in this anomaly detection with extended results page that is linked from the previous anomaly detection page

Let me know if anyone has any questions/feedback, thanks!

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[rdsharma26]

@arsenalgunnershubert777 Thanks for the PR! Please allow for additional time to review the PR given the amount of changes. In the meantime, would it be possible to rebase your branch off of latest master so that it reduces the number of commits in the PR?

[arsenalgunnershubert777]

Hey @rdsharma26 thanks for reaching out. I think I have some issues with the conflicts (and I also can improve my understanding of Git)
So for now I may just create a clean branch and apply the changes on top of that manually and open a new PR, so there's just 1 commit

[rdsharma26]

Thanks @arsenalgunnershubert777
After syncing your forked repository with the main repository, you could try:

git checkout master
git pull
git checkout exposeAnomalyThresholdBackwardsCompatible
git rebase master
git push origin exposeAnomalyThresholdBackwardsCompatible

[arsenalgunnershubert777]

@rdsharma26 got it yea when I run that it has more conflicts, and I notice some classes have reverted to previous states