moving average prediction bug

[liorg2]

Elasticsearch version:
5.2
Plugins installed:
[x-pack]

JVM version:
java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)

OS version:
CentOS Linux release 7.2.1511

Description of the problem including expected versus actual behavior:
when trying to predict 2 different aggregation buckets - when the first is null,(not sure why), no prediction is provided for the other one as well.

Steps to reproduce:

this will return prediction for "plt" field:

query1.txt

response:

response1.txt

while this will not return "plt" field prediction:
query2.txt

response:
response2.txt

the only difference in the aggregations order, which should not matter in json documents

[colings86]

Something is definitely weird here because in botht hte responses the last non-prediction bucket is:

              {
                "key_as_string": "2017-02-26T00:00:00.000Z",
                "key": 1488067200000,
                "doc_count": 0,
                "avg__plt": {
                  "value": 14243.0556640625
                },
                "avg__connection_time": {
                  "value": null
                },
                "movavg__plt": {
                  "value": 13210.367580574217
                },
                "movavg__connection_time": {
                  "value": 359.128475
                }
              }

That bucket has a doc_count of 0 which is weird because 1) you have no extended_bounds on your histogram so it should not be returning empty buckets and 2) if the bucket is empty then the avg__plt agg should be returning null like the avg__connection_time agg is because there was no date for the bucket to compute the average for.

@polyfractal any ideas here?

[colings86]

@liorg2 are you able to try to come up with a recreation script that should this same behaviour on a fresh index? If so could you provide it here? (it would be good if your recreation script includes creating the index and indexing documents so we can fully reproduce what you are seeing)

[colings86]

@liorg2 also, could you do a query for "key":"75610c7ee12bc268af33ddb31828a4b8" and "create_date": [1488067200000 TO 1488153600000] to see if it matches any documents? (from those above responses it suggests you should get 0 hits

[liorg2]

thanks @colings86

there is one doc by this condition:

GET .../_search?ignore_unavailable
{
  "size": 10,
  "query": {
    "bool": {
      "filter": [
        {
          "range": {
            "create_date": {
              "gte": "2017-02-26T00:00:00",
              "lt": "2017-02-27T00:00:00"
            }
          }
        },
        {
          "terms": {
            "key": [
              "75610c7ee12bc268af33ddb31828a4b8"
            ]
          }
        }
      ]
    }
  }
}

it doesn't have this field though: "connection_time__stats"

is there a quick way to generate such a create/index script you mentioned?

[polyfractal]

Urgh, yeah, I have no idea what's going on here either. All the values are identical up until the missing prediction bucket.

I'm wondering if that second-to-last bucket with a count of zero is somehow getting overwritten/merged with a prediction bucket? E.g. here we create a new bucket for the prediction -- using any existing buckets -- but set the doc count to zero.

If the two series are not "lined up" then one of the aggs would overwrite a valid bucket with it's prediction, which may be the case here... I think.

I'm still not sure why the order matters and why the last bucket shows/doesn't show, but it may be related. I'll start debugging.

[polyfractal]

BTW @liorg2 , if there's any way you can create a small test case that demonstrates this behavior, it would be very appreciated! Still a bit stumped what's going on here :/

[liorg2]

No prob. Will do it on Monday

…

On Fri, 28 Apr 2017 at 16:04 Zachary Tong ***@***.***> wrote: BTW @liorg2 <https://github.com/liorg2> , if there's any way you can create a small test case that demonstrates this behavior, it would be very appreciated! Still a bit stumped what's going on here :/ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#24327 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABnP_ywaSHC62CY1uppgaKd3-9OQDbr3ks5r0eNJgaJpZM4NIihn> .

[liorg2]

I'm very sorry, but I don't have access to this data anymore. I really hope that you succeeded to reproduce this issue.....
anyway I think is that the missing field cause this issue

Lior

[polyfractal]

No luck reproducing, but after looking a bit closer there's definitely a bug with predictions overwriting doc counts on buckets. Perhaps that's the root cause, not sure. I'll work up a PR to fix that and hopefully it'll fix your problem :)

[liorg2]

Sorry, but the admin here deleted all "QA indices" from time to time. I will try to replicate it when I have more time.
BTW, it will be very nice of you guys to add also upper/lower fences, as few other libraries do.
also, can I ask, if you are using open source lib for the models/prediction calc ?