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

Option to add safeguard to prevent overly broad time filters that hit too many indices #6514

Closed
ppf2 opened this issue Mar 11, 2016 · 0 comments
Labels
release_note:enhancement stale Used to mark issues that were closed for being stale Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@ppf2
Copy link
Member

ppf2 commented Mar 11, 2016

Use case is that there can be a number of clusters with many indices (>100 easily) fronted by the tribe node (or simply many indices in a single cluster). The number of indices queried today from Kibana is driven by the time range filter the user selects. There can be situations when the end user selects an overly broad time range (mistakenly, or simply not knowing the consequences of doing so), and cause the query to hit hundreds of indices (or maybe thousands of shards), resulting in poor performing queries that can add stress to the ES clusters.

One idea here is to add a safeguard option to limit the # of indices queried and block users from doing so. We are already doing some prep work using the field stats api to come up with a constrained set of indices to query based on the time filter selected by the end user. This can potentially be a safeguard we can build on top of that field stats check, eg. allow admins to configure a hard limit for the maximum number of indices a query can hit, and once we get the list of indices back from the field stats api, we can strip off the “extra” indices that exceed the threshold. In terms of which indices to return when the threshold is exceeded, maybe the “latest” N number of indices? Or give the user a few options when setting the threshold. Certainly, this will apply mostly for the time based indexing use case.

@stacey-gammon stacey-gammon added the Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc label Aug 8, 2018
@joshdover joshdover added the stale Used to mark issues that were closed for being stale label Jan 14, 2021
cee-chen added a commit that referenced this issue Jan 13, 2023
## Summary

`eui@71.1.0` ⏩ `eui@72.2.0`

---

- Added `onFullScreen` callback to expose the `isFullScreen` state of
the `EuiImage` ([#6504](elastic/eui#6504))
- Added an extra spacing between the title and subtitle to `EuiTour`
([#6512](elastic/eui#6512))
- Updated `EuiText.blockquote` styles to match the
`EuiMarkdownFormat.blockquote` styles
([#6514](elastic/eui#6514))
- Added the `repositionOnScroll` prop to `EuiToolTip`
([#6515](elastic/eui#6515))

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Jason Stoltzfus <jason.stoltzfus@elastic.co>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release_note:enhancement stale Used to mark issues that were closed for being stale Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

No branches or pull requests

3 participants