Improve query results cache hit ratio in the 'Mimir / Queries' dashboard #5423
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Marco Pracucci <[email protected]>
Signed-off-by: Marco Pracucci <[email protected]>
56quarters
approved these changes
Jul 5, 2023
7 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does
In #5235 I've introduced new fine-grained metrics to measure the query results cache hit ratio. The new metrics allow to get a better measurement because: (a) they only track the cache lookup done by query results cache (e.g. excluding cache usage done by query cardinality estimator) and (b) they're split by
request_type.In this PR I'm improving the
Mimir / Queriesdashboard to use the new metrics, while keeping backward compatibility:Query results cache hit ratio, fallback to the old oneQuery results cache hit ratiopanel because (a) not much useful (b) not even correct, given it includes cache misses from query cardinality estimatorHow the new dashboard row looks like:
NOTE: in the dev cluster where I took the screenshot there are no calls to the cardinality API, but I tested the new panel query in production (where we have traffic on cardinality API) and it looks good.
Which issue(s) this PR fixes or relates to
N/A
Checklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]