Add cortex_frontend_query_result_cache_requests_total and cortex_frontend_query_result_cache_hits_total metrics #5235
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 #5212 I've added the optional and experimental support to lookup cardinality queries from the cache. However, we don't have a way to track the cache hit ratio specifically for the cardinality API endpoints. Reason is that today we measure the query-frontend cache hit ratio looking at the underlying memcache metrics (e.g.
thanos_cache_memcached_hits_total / thanos_cache_memcached_requests_total
) which are not split by request type / route (and not easy to do).In this PR I propose to add a couple of new metrics which specifically track the query results cache cache hit ratio. I haven't changed the "Mimir / Queries" dashboard yet because I would like to see the new metrics deployed first before changing the dashboard (changes will be backward compatible).
Note to reviewers:
cortex_frontend_query_result_cache_
to keep it consistent with other metrics we already haveroute
and propagating it would be quite tedious. On the other hand, I would prefer to not add logic to detect the route from the requestURL
, so I went to a simpler path which is a simple hardcodedrequest_type
whose values could bequery_range
orcardinality
.Which issue(s) this PR fixes or relates to
N/A
Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]