You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While doing dome experiments with the elastic/logs track I saw that the "@timestamp" fields of the documents ending up in the ".ds-logs-redis.log-default-*" datastream do not seem to be affected by the "start_date"/"end_date" or "bulk_start_date"/"bulk_end_date" track parameters. I'm wondering if those are then correctly queried in the querying challanges.
Ways to reproduce locally:
I run the "logging-querying" challenge with the following parameters:
I inspected the data after re-starting the cluster used by that race.
My expectation was that all documents lie in a data range between 2020-01-01 and 2020-01-02, that would also be the defaults. Looking at date histograms of the "@timestamp" field I found that mostly the above mentioned "redis" datastreams have documents in todays time range:
While doing dome experiments with the elastic/logs track I saw that the "@timestamp" fields of the documents ending up in the ".ds-logs-redis.log-default-*" datastream do not seem to be affected by the "start_date"/"end_date" or "bulk_start_date"/"bulk_end_date" track parameters. I'm wondering if those are then correctly queried in the querying challanges.
Ways to reproduce locally:
I run the "logging-querying" challenge with the following parameters:
Running race like this:
I inspected the data after re-starting the cluster used by that race.
My expectation was that all documents lie in a data range between 2020-01-01 and 2020-01-02, that would also be the defaults. Looking at date histograms of the "@timestamp" field I found that mostly the above mentioned "redis" datastreams have documents in todays time range:
I'm curious about whether this is an error and/or a problem for when querying this tracks data.
The text was updated successfully, but these errors were encountered: