Besides minor language corrections, this tries in particular to
provide some clarity about the `step` setting in the Prometheus range
query and the `$__interval` variable:
- First of all: They are both always the same.
- What's really confusing (and arguably really un-helpful) is that the
_Min time interval_ is multiplied by the resolution
factor. Therefore, I just state the fact here now but don't add
anything like "This should be the scrape interval" because it is not
true (if resolution is `1/10`, a meaningful _Min time interval_ is
generally a tenth of the scrape interval).
- More helpful is the _Min step_ parameter, because it is not
multiplied by the resolution factor (which I have now stated
explicitly). Of course, the _Min time interval_ has to be set to
something small so that the _Min step_ parameter can kick in.
It would be good if we could also override the _Min time interval_
tool tip because that is where most people will look, and the current,
very Graphite-centric tool tip is very confusing for the Prometheus
query editor, in particular because it doesn't have any hint about the
resolution factor being applied. See #21413.
Signed-off-by: beorn7 <beorn@grafana.com>
* Prometheus data source: Update tooltip for _Scrape interval_
The old tool tip was plainly wrong. The globally configured scrape
interval is not necessarily the most used scrape interval, so the new
wording is describing what actually matters. The evaluation interval
wasn't even mentioned before. And finally, the configured value is
not strictly a lower limit for the step query parameter as it can be
overridden by the panel option _Min time interval_.
I plan to explain the overriding intricacies in the tool tip for _Min
time interval_.
Signed-off-by: beorn7 <beorn@grafana.com>
* Improve tooltip for _Min step_
The previous tool tip was mostly addressing aspects that are not
specific to _Min step_ (and might be more appropriate to be added to
the _Min time interval_ tool tip as that setting has a wider
scope). The new version emphasizes the important gotchas: that this is
an _additional_ lower limit, and that it is _not_ multiplied by the
resolution factor.
Signed-off-by: beorn7 <beorn@grafana.com>
* Fixed snapshot
Co-authored-by: David <david.kaltschmidt@gmail.com>
Much easier to wrap one's head around it if it is expressed more
directly.
This is not mathematically the same as the previous version involved
more rounding than necessary because of the way the intervalFactor was
handled. I'd argue the new version is better because it gets closer to
the 11,000 points limit and thus approaches better what the user
wanted within the limits of Prometheus.
Note that in practice, the 11,000 points limit should never be of
relevance. (Even a 4k screen doesn't have 11k points on the x axis.)
Signed-off-by: beorn7 <beorn@grafana.com>
Björn Rabenstein
