The "resolution" option disappears in Grafana 8.5

[Pamalosebi]

What happened:
The "resolution option" disappears.

What you expected to happen:
The "resolution" does not disappear

How to reproduce it (as minimally and precisely as possible):
change the "resolution" to 1/1 and see it gone

Anything else we need to know?:

Grafana_resolution.mp4

Environment:

• Grafana version: 8.5
• Data source type & version: Prometheus 2.35.0
• OS Grafana is installed on: Rocky Linux 8.5
• User OS & Browser: Arch / Chrome
• Grafana plugins: -
• Others: -

[joshhunt]

Kind of able to replicate this - it doesn't look like the resolution field does not appear for new Prometheus queries.

This looks like a deliberate change, but couldn't find anything in the changelog about this

grafana/public/app/plugins/datasource/prometheus/querybuilder/components/PromQueryBuilderOptions.tsx

Lines 85 to 95 in 68aac0b

	{query.intervalFactor && query.intervalFactor > 1 && (
	<EditorField label="Resolution">
	<Select
	aria-label="Select resolution"
	menuShouldPortal
	isSearchable={false}
	options={INTERVAL_FACTOR_OPTIONS}
	onChange={onIntervalFactorChange}
	value={INTERVAL_FACTOR_OPTIONS.find((option) => option.value === query.intervalFactor)}
	/>
	</EditorField>

[belm0]

This is a regression-- query resolution is an important setting. Please escalate it.

@torkelo is this an oversight from the transition to the new Prometheus query UI? (#45260)

Adds resolution option (when it's not 1)

[torkelo]

It was removed on purpose, it's being deprecated.

You can lower resolution by setting a lower max data points under query options (at top of query tab in panel edit)

[Pamalosebi]

Oh, well good to know. Then that is something to get used to.

At a first glance it seems to do the job, but the results are not similar.

The Upper one is the “old” resolution behavior.

With the resolution of 1/10.

At the lower one I changed the resolution to 1/1, so the option disappears and changed the max data points to 148.
148 since it is arount 10% of 1478 data points, which it had. In my logic that would be a resolution of 1/10, right?

Maybe I have to dig some more into that, but I did like the old results better. (At the first glance at least).

[belm0]

@torkelo is there a discussion or design document you could cite to help us understand the decision? It seems like a substantial change to replace a relative resolution ratio with an absolute "max points".

We relied on resolution "1/2" to mean "whatever the rendered size of the panel, fetch half as many points in order to save fetch time, backend load, and client processing". That is no longer possible with an absolute max points parameter. Additionally, we were able to control the resolution individually per panel query (important because some queries are much heavier than others)-- but that has been lost.

Given that a panel designer has decided that it's tolerable to display a series at lower than the available screen pixels, with this change we've gone from "whatever the rendered panel size, fetch and render at a multiple faster", to "set a worst case-limit on points, which will only apply to panels rendered larger than some certain size".

[belm0]

I'll attempt a summary. (Shouldn't this change be mentioned in the changelog and documented?)

before: Resolution option - control the number of fetched points as a ratio of displayed pixels. If we set resolution to 1/2, it will be half the number of points, regardless of rendered panel size. Each query of the panel could be set differently.

after: Max data points option - control the absolute maximum fetched points. If we set the max to 500, it will only affect panels rendered at larger than 500 pixel width (for example, panel size 1,000 will fetch 1/2 of points, panel size 2,000 will fetch 1/4). The setting is applied to all queries of the panel.

[Pamalosebi]

It seems like a substantial change

This feature should not be deprecated without proper replacement. :(

It might be off topic, but I have to say, it slowly gets tiring. Since a long time Grafana Is my way to visualize data. And it always has been a great experience. But some decisions recently are just... "off". And the question is "why" which doesn't properly gets answered.

Three recent examples:

1. Sort in the newest Time Series was gone for a few months -> Time series: Add ability to sort series via legend #35429
   Luckily it's fixed already.

2. Images removed from the new notifications -> Add "include image" option into Grafana Alerting #38030
   Thats just a horrible Idea. Apparently there are plans to fix that too.

3. Deprecation of the resolution functionality -> Here
   Above are some negative replies already.

[bjakubski]

We're using resolution setting pretty heavily recently, so that is a bummer.
I'm not sure how can I use max data points for this purpose given dynamic width of panels being displayed (I do want more points when viewing the same panel using 100% width on 4k display and I do want less points when same panel is displayed on my phone in vertical orientation)

[belm0]

another limitation of the new scheme:
using a "Max data points" default of "panel width" is nonsensical if the panel shows tabular data

For example, we have a panel employing various transforms that ultimately outputs a detailed table, and 1:1 data points are required as input. With Max data points there isn't a way to represent "all data points in range" other than entering an arbitrarily large number.

[torkelo]

@belm0 the same was true before. resolution was just a way to specify how many times to divide max data points by

[breezewish]

I raised a feature in discussion. A better alternative to the resolution is to support a relative max data points, like 10% of the panel width. This would be better than the resolution 1/10 that it expands details when time range is small while collapse multiple data points into one when time range is large, always displaying as many data points as possible.

#50134

[srclosson]

I've responded to the discussion. I think we need to be very careful about sampling data without the help of a query language. For example, if you only wanted 10% of the points, what insight is wanted by sampling down the data? The max, the min, the average? If the query language does not provide this ability, perhaps the query language should?

[torkelo]

@srclosson not sure I understand what you mean, time series queries almost always involve some sort of sampling (for longer time ranges). And most query languages / APIs have ways to handle this downsampling (but in different ways). Prometheus does it via step and range vector (which has a delicate interplay).

The resolution option was just a handy way to divide max data points, max data points is still there and kicking. We might add back resolution but I think then it will be under Query options (so it can be shared with all data sources)

[srclosson]

@torkelo Oh, I see! I guess I didn't understand.

I guess I'm still wondering what max data points means. Let's say between time A and time B there are 100000 data points. If you are just requesting raw data, and wanted 1/10 the resolution, does that mean you request the first 10000 points in the dataset between A and B?

[breezewish]

@srclosson Usually the 10000 points should be distributed evenly in the time range. For example in Prometheus data source, the resolution and the max data points will influence the "step" option, causing it to be a larger "step".

[BBQigniter]

this resolution option was quite handy and useful

[rdugan]

This feature was useful for showing different stats at varying resolutions in multi-query panels. For instance, i often create line graphs (with accompanying table of values) overlaying bar graphs, and the resolution allowed higher fidelity on the line graphs/table, with lower fidelity for the bar graphs so they actually look like bar graphs, and not a bunch of 1px lines.

[ooliver1]

For those that still want this feature that was randomly removed...

Go to Query Inspector, edit JSON, scroll down to targets, and add the reciprocal of resolution into the object, such as "intervalFactor": 5.

Like so:

  "targets": [
    {
      "datasource": {
        "type": "prometheus",
        "uid": "yIBQYVL4k"
      },
      "editorMode": "code",
      "expr": "(\n  (1 - sum without (mode) (rate(node_cpu_seconds_total{job=\"node\", mode=~\"idle|iowait|steal\", instance=\"$instance\"}[$__rate_interval])))\n/ ignoring(cpu) group_left\n  count without (cpu, mode) (node_cpu_seconds_total{job=\"node\", mode=\"idle\", instance=\"$instance\"})\n)\n",
      "legendFormat": "{{cpu}}",
      "refId": "A",
      "intervalFactor": 5
    }
  ]

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last year. It will be closed in 30 days if no further activity occurs. Please feel free to leave a comment if you believe the issue is still relevant. Thank you for your contributions!

[BBQigniter]

unstale :|