Skip to content
This repository was archived by the owner on Aug 23, 2023. It is now read-only.

request: a way to block expensive/problematic queries #1850

Closed
Dieterbe opened this issue Jun 19, 2020 · 4 comments
Closed

request: a way to block expensive/problematic queries #1850

Dieterbe opened this issue Jun 19, 2020 · 4 comments

Comments

@Dieterbe
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Some user created an auto-refreshing grafana dashboard that would periodically call "/tags/autoComplete/values" with a very expensive query (one that would return a large result set out of a large tag index that's slow to search into, I imagine). the http.tagdb-default-limit value doesn't help much because it only filters after the results are generated, and also the query from grafana has this value set to 10k, something the MT admin can't override. (not that restarting a MT cluster to deploy a config update would be feasible). This query is so expensive that many other queries would fail or become very slow. (I don't know the exact specifics on this, there's some backstory here that @replay and @robert-milan are more familiar with)

Describe the solution you'd like

A rejection list for queries. A way to provide a combination a url path and set of parameters that, when found, should be flat out rejected. This way an operator could easily manually intervene by posting an update to the rejection list.

Describe alternatives you've considered

  • Automatically block "slow" queries -> to tricky too implement. how do you measure what is slow in a reliable, consistent and fairi way.
  • provide more tunables for each specific http path -> lots more hassle and hard to get a similar level of blocking.
@Dieterbe Dieterbe added this to the sprint-14 milestone Jun 19, 2020
@Dieterbe
Copy link
Contributor Author

added sprint 14 to open the discussion.

@shanson7
Copy link
Collaborator

Might be related to this (WIP, PoC) PR too: #1847. Long read requests cause lots of blocking in the index. We have been running the above PR for a while and things are considerably better (although there is still a scenario in which long reads can block things up).

@Dieterbe
Copy link
Contributor Author

consensus:

  • will go in query nodes
  • use config file use literal string matching (not regex)

@Dieterbe Dieterbe removed this from the sprint-14 milestone Aug 3, 2020
@stale
Copy link

stale bot commented Nov 1, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Nov 1, 2020
@stale stale bot closed this as completed Nov 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants