grafana / grafana/pyroscope

Fulfill queries partially outside max query window

Open
#3,072 0 comments 0 reactions 0 assignees View on GitHub
backend enhancement
Dominant language
Go
Stars
11.7k
Forks
802
Avg merge
1d 19h
Merged PRs (30d)
80

Description

Related: https://github.com/grafana/grafana/issues/83644

### Problem

Pyroscope limits the maximum time span of queries and if a query is larger than this window, it fails outright.

https://github.com/grafana/pyroscope/blob/38218a8e16b67af9c777003dd29878673918ebed/pkg/validation/validate.go#L317-L323

The complete failure is a somewhat jarring experience for users as there generally is data to we could serve, but we don't attempt to fulfill it.

### Solution

We can copy what we do when a query is partially outside a retention window and [trim the query time range](https://github.com/grafana/pyroscope/blob/38218a8e16b67af9c777003dd29878673918ebed/pkg/validation/validate.go#L294-L314) to satisfy the query length limit. The only drawback is deciding how to trim the query time range. We have three options:

1. Trim from the `start` side of the query
```
max query length: 1d

now-3d now-2d now-1d now
▼ ▼ ▼ ▼
requested range: [=======================]
truncated range: [=======]
▲ ▲ ▲ ▲
now-3d now-2d now-1d now
```
2. Trim from the `end` side of the query
```
max query length: 1d

now-3d now-2d now-1d now
▼ ▼ ▼ ▼
requested range: [=======================]
truncated range: [=======]
▲ ▲ ▲ ▲
now-3d now-2d now-1d now
```
3. Trim equally from `start` and `end`
```
max query length: 1d

now-3d now-2d now-1d now
▼ ▼ ▼ ▼
requested range: [=======================]
truncated range: [=======]
▲ ▲ ▲ ▲
now-3d now-2d now-1d now
```

Option 1 seems to be the most natural heuristic as it mimics the notion of "Let's start at some point in time and include results as far back as possible." Option 2 is the inverse of option 1, but feels slightly less natural. Option 3 is a compromise of the two, but is the least natural as it makes the resulting range highly unpredictable.

If we choose to implement this feature, we should also include a mechanism whereby we can signal to clients that the query range had to modified in a specific way to return results. This will help UIs warn users the query results aren't precisely what they asked for.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.