Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ML] Unexpected interim results after advancing time into new empty bucket #324

Closed
dimitris-athanasiou opened this issue Nov 30, 2018 · 1 comment
Assignees

Comments

@dimitris-athanasiou
Copy link
Contributor

How to reproduce

  1. Create a job with simple count detector and a bucket span of 5m
  2. Run some data through the job up to the end of a bucket (using the end parameter of the start datafeed API)
  3. Open the job again (it should have been auto-closed from step 2)
  4. Call the flush API:
POST _xpack/anomaly_detectors/{job_id}/flush?advance_time={time}&calc_interim=true

where {time} should be a timestamp into the current bucket. E.g., if end was 2018-12-01T00:00:00Z, {time} should be 2018-12-01T00:00:01Z

Observed Behaviour

If you get the anomaly records, you should see a record which is interim and has an actual value of 0.0. This shouldn't have been created. Interestingly, calling step 4 with {time} being one millisecond forward makes that record disappear.

Also, this is broken since version 6.4.

@edsavage edsavage self-assigned this Dec 3, 2018
dimitris-athanasiou added a commit to dimitris-athanasiou/ml-cpp that referenced this issue Feb 26, 2019
…calc

This commit sorts detectors before caclulating interim results making sure
that the simple count detector goes first. We rely on that being the case
as the simple count model updates the interim results corrector with the
current bucket count. If it does not get updated first, then the bucket
completeness will be thought to be full and interim results may be
created when they should not.

Closes elastic#324
@dimitris-athanasiou
Copy link
Contributor Author

For future reference, it might be useful to note this bug was introduced by #97

dimitris-athanasiou added a commit that referenced this issue Feb 26, 2019
#416)

This commit sorts detectors before caclulating interim results making sure
that the simple count detector goes first. We rely on that being the case
as the simple count model updates the interim results corrector with the
current bucket count. If it does not get updated first, then the bucket
completeness will be thought to be full and interim results may be
created when they should not.

Closes #324
dimitris-athanasiou added a commit to dimitris-athanasiou/ml-cpp that referenced this issue Feb 26, 2019
elastic#416)

This commit sorts detectors before caclulating interim results making sure
that the simple count detector goes first. We rely on that being the case
as the simple count model updates the interim results corrector with the
current bucket count. If it does not get updated first, then the bucket
completeness will be thought to be full and interim results may be
created when they should not.

Closes elastic#324
dimitris-athanasiou added a commit to dimitris-athanasiou/ml-cpp that referenced this issue Feb 26, 2019
elastic#416)

This commit sorts detectors before caclulating interim results making sure
that the simple count detector goes first. We rely on that being the case
as the simple count model updates the interim results corrector with the
current bucket count. If it does not get updated first, then the bucket
completeness will be thought to be full and interim results may be
created when they should not.

Closes elastic#324
dimitris-athanasiou added a commit to dimitris-athanasiou/ml-cpp that referenced this issue Feb 26, 2019
elastic#416)

This commit sorts detectors before caclulating interim results making sure
that the simple count detector goes first. We rely on that being the case
as the simple count model updates the interim results corrector with the
current bucket count. If it does not get updated first, then the bucket
completeness will be thought to be full and interim results may be
created when they should not.

Closes elastic#324
dimitris-athanasiou added a commit to dimitris-athanasiou/ml-cpp that referenced this issue Feb 26, 2019
elastic#416)

This commit sorts detectors before caclulating interim results making sure
that the simple count detector goes first. We rely on that being the case
as the simple count model updates the interim results corrector with the
current bucket count. If it does not get updated first, then the bucket
completeness will be thought to be full and interim results may be
created when they should not.

Closes elastic#324
dimitris-athanasiou added a commit that referenced this issue Feb 26, 2019
#416) (#420)

This commit sorts detectors before caclulating interim results making sure
that the simple count detector goes first. We rely on that being the case
as the simple count model updates the interim results corrector with the
current bucket count. If it does not get updated first, then the bucket
completeness will be thought to be full and interim results may be
created when they should not.

Closes #324
dimitris-athanasiou added a commit that referenced this issue Feb 26, 2019
#416) (#421)

This commit sorts detectors before caclulating interim results making sure
that the simple count detector goes first. We rely on that being the case
as the simple count model updates the interim results corrector with the
current bucket count. If it does not get updated first, then the bucket
completeness will be thought to be full and interim results may be
created when they should not.

Closes #324
dimitris-athanasiou added a commit that referenced this issue Feb 27, 2019
…sult … (#422)

This commit sorts detectors before caclulating interim results making sure
that the simple count detector goes first. We rely on that being the case
as the simple count model updates the interim results corrector with the
current bucket count. If it does not get updated first, then the bucket
completeness will be thought to be full and interim results may be
created when they should not.

Closes #324
dimitris-athanasiou added a commit that referenced this issue Feb 27, 2019
…sult … (#423)

This commit sorts detectors before caclulating interim results making sure
that the simple count detector goes first. We rely on that being the case
as the simple count model updates the interim results corrector with the
current bucket count. If it does not get updated first, then the bucket
completeness will be thought to be full and interim results may be
created when they should not.

Closes #324
dimitris-athanasiou added a commit to dimitris-athanasiou/elasticsearch that referenced this issue Feb 27, 2019
This is an integration test that captures the issue described in
elastic/ml-cpp#324
dimitris-athanasiou added a commit to elastic/elasticsearch that referenced this issue Feb 28, 2019
…39447)

This is an integration test that captures the issue described in
elastic/ml-cpp#324
dimitris-athanasiou added a commit to elastic/elasticsearch that referenced this issue Feb 28, 2019
…39447)

This is an integration test that captures the issue described in
elastic/ml-cpp#324
dimitris-athanasiou added a commit to elastic/elasticsearch that referenced this issue Feb 28, 2019
…39447)

This is an integration test that captures the issue described in
elastic/ml-cpp#324
dimitris-athanasiou added a commit to elastic/elasticsearch that referenced this issue Feb 28, 2019
…39447)

This is an integration test that captures the issue described in
elastic/ml-cpp#324
dimitris-athanasiou added a commit to elastic/elasticsearch that referenced this issue Feb 28, 2019
…39447)

This is an integration test that captures the issue described in
elastic/ml-cpp#324
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants