feat(anomaly detection): Dynamic Window for Matrix Profiling #1451
Conversation
aayush-se
force-pushed
the
anomaly-detection/dynamic-window
branch
from
cc46826
to
bf302c1
Compare
|
Waiting for codecov to give report -- will update test coverage upon receiving |
| if original_flag is None: | ||
| original_flag = "none" | ||
| original_flags.append(original_flag) | ||
| algo_data = MPTimeSeriesAnomalies.extract_algo_data(point.anomaly_algo_data) |
There was a problem hiding this comment.
Seems like this is not backward compatible as both mp_suss and mp_fixed are not there. So detection for existing alerts in production will fail, right?
There was a problem hiding this comment.
This was one thing I wanted to ask about -- if we were to use this class for prod, could we rerun calculation to populate the objects appropriately?
There was a problem hiding this comment.
Because to get the algo data for both suss and fixed, we would need to store the MP as a field in the object
There was a problem hiding this comment.
I think it will be best to just let the recalculation happen when data pruning happens. So this code should be backward compatible. We will need an unit test to check that. Also, test it locally with an alert pre-populated.
There was a problem hiding this comment.
Sure, will include those tests and confirm through local testing
| convert_external_ts_to_internal(timeseries), config, window_size=window_size | ||
| ) | ||
| anomalies_fixed = batch_detector.detect( | ||
| convert_external_ts_to_internal(timeseries), config, window_size=10 |
There was a problem hiding this comment.
We should add this 10 as a constant to the MPConfig class?
anomaly_algo_datato store matrix profile related information for both windows for a given alertMPTimeSeriesAnomaliesSingleWindowclass and updated theMPTimeSeriesAnomaliesclass to effectively manage and store the proper matrix profile related information and the boolean for determining which window logic to useanomaly_algo_data