Detailed Documentation around Result Caching

[senkr132]

We are trying to understand how the result caching works for metrics queries in Loki and there seems to be not detailed documentation around it.

We did some testing and below are our high-level observation but it would be good to know the expected behaviour so that we can take advantage of the results cache for long duration queries.

• d1,d2,d3,d4,d5,d6,d7 - queried individualy but tried to query between d1 to d7 it is not using the cache
• We need to build the cache like d1,d1+d2,d1+d2+d3,d1+d2+d3+d4,d1+d2+d3+d4+d5,d1+d2+d3+d4+d5+d6,d1+d2+d3+d4+d5+d6+d7 and then it works

1. Detailed documentation of how results query works and best practice around logql to use caching effectively will be helpful
2. Also logging to indicate if the query is using the cache (full or partial or not using) will be good information to expose.

[MasslessParticle]

There isn't presently any detailed documentation on the results cache as it's something of an implementation detail. Loki's result cache is particularly suited to refreshing dashboards like you might see in Grafana.

Loki caches the result of a metrics query for a time range and then combines that with other cached time ranges to reduce the amount of total work that it needs to do. Loki keeps the interval of a query, it's step size, the query itself as part of the cache key.

• When a query is made that has not been cached, it is added to the cache
• When a subsequent query is made to the cache with the same step and interval we get a cache hit. Loki looks at the previously cached results and requests any non-cached data. Any new data is cached with it's own start-end times

It's worth noting that Loki automatically splits queries into 30m (by default) time ranges and those splits are cached seperately

In your example, if you query d1-d7 then d3-d4, your interval is changed so you're going to get a cache miss but if you calculate d2-d8, you'll reuse any wholly-cached responses as part of that.

If you're in something like the Grafana Explore interface, and you zoom in, you'll change the step and cause a cache miss.

To get more visibility into cache behavior you can look at a couple of metrics:

• loki_cache_fetched_keys: The number of cache requests
• loki_cache_hits: the number of cache hits

If your query your Loki with logcli you can also use the --stats flag to get detailed cache statistics for any given query

[GrafanaWriter]

@JStickler - FYI.

[senkr132]

@MasslessParticle Thanks for the clarification.

We have a use-use where we are trying to query last 7 days of data and since our log volume is really huge it is timing out or really slow. So we thought we will use the caching effectively by having higher TTL along with running these queries daily to load the cache.

If we cache last 7 days and if we keep running the same query for last 7 days will it keep using the cache for last 6 days and process the latest day's data.