ExpediaGroup/adaptive-alerting

Refactor detectors for increased flexibility

Closed this issue · 1 comments

Currently there are multiple forecast-based detectors that tightly couple a point forecast algorithm with an interval forecast algorithm, even though these ought to be distinct choices. For example, EwmaDetector binds the EWMA point forecasting algo with an interval forecast based on Welford's algo. There's no reason to couple those two things, and doing so artificially limits the number of detectors.

We want to refactor the detectors such that point and interval forecasts are independently selectable.

For the time being we need to preserve the ability to work with the legacy detectors, since the UI creates legacy detectors. But the idea would be to transition away from those.

Acceptance criteria

  • AA supports config-driven creation of forecasting detectors with independently selectable point and interval forecast algos.
  • Legacy detectors still supported, temporarily, as UI needs to be able to create these.

Tasks

  • Implement LegacyDetectorFactory
  • Detector interface: remove hardcoded params generic type
  • Detector interface: remove anomaly type, since it doesn't apply to all detectors
  • Introduce ForecastingDetector implementation
  • Refactor EWMA to use ForecastingDetector
  • Refactor PEWMA to use ForecastingDetector
  • Refactor HoltWinters to use ForecastingDetector
  • Implement new detector factory based on generic detector configuration