Adaptive time window to avoid timeouts in Discover

[bitkowitz]

My cluster has a combination of dense indices with fine-grained events as well as summary indices with aggregated results for dashboarding. It is presently common for users to encounter a timeout as soon as they select the dense indices on the discover tab. A user would need to either narrow the time window to <1 day OR know to pre-filter for a particular type of event in order to avoid these timeouts.

Presently, the only knobs that I have are the global advanced settings options below:
discover:sampleSize
timepicker:timeDefaults

I had considered reducing the sample size and drastically narrowing the time window to reduce these timeouts with dense indices but then that degrades the experience when browsing all of the lighter-weight indices.

Is it possible for the time window to be adaptive to avoid timeouts? It should start narrow and focus on quickly getting something on the screen. It can then incrementally add more content and grow the default time window based on the speed of the cluster. This would at least give users a starting place for the discover process vs. staring at an empty results page after waiting 30 seconds.

[Bargs]

I bet these timeouts are related to #15732. ES is looking into fixes here elastic/elasticsearch#28727

Could you try running one of the discover queries that times out in Console without the date histogram agg? You should be able to grab the query from the network tab of your browser's dev tools, look for the _msearch request.

[bitkowitz]

I tried your suggestion. It still times out. I even reduced the query so it only has to return one document within a large time window. It still times out. I can only get a fast response if I restrict the time range of the query.

As an alternative to adaptively discovering the time window to use for discover, I would be fine with having an option for a default time range per index pattern. This would allow me to configure a narrow default time range for dense indices and a broad time range for light-weight indices.

[Bargs]

Hmmmm, this is the first time I’ve heard of timeouts without the date histogram in play. It’s reasonable to expect discover not to choke on index patterns with large numbers of indices and docs. I think we’ll need to do some investigation into the root cause of the slowness to know what the best solution will be.

[lukasolson]

Closing for inactivity. Please feel to re-open if this is still an issue.