Commits on Mar 7, 2024

1. promql: Fix limiting of extrapolation to negative values …

   This is a bit tough to explain, but I'll try:
   
   `rate` & friends have a sophisticated extrapolation algorithm.
   Usually, we extrapolate the result to the total interval specified in
   the range selector. However, if the first sample within the range is
   too far away from the beginning of the interval, or if the last sample
   within the range is too far away from the end of the interval, we
   assume the series has just started half a sampling interval before the
   first sample or after the last sample, respectively, and shorten the
   extrapolation interval correspondingly. We calculate the sampling
   interval by looking at the average time between samples within the
   range, and we define "too far away" as "more than 110% of that
   sampling interval".
   
   However, if this algorithm leads to an extrapolated starting value
   that is negative, we limit the start of the extrapolation interval to
   the point where the extrapolated starting value is zero.
   
   At least that was the intention.
   
   What we actually implemented is the following: If extrapolating all
   the way to the beginning of the total interval would lead to an
   extrapolated negative value, we would only extrapolate to the zero
   point as above, even if the algorithm above would have selected a
   starting point that is just half a sampling interval before the first
   sample and that starting point would not have an extrapolated negative
   value. In other word: What was meant as a _limitation_ of the
   extrapolation interval yielded a _longer_ extrapolation interval in
   this case.
   
   There is an exception to the case just described: If the increase of
   the extrapolation interval is more than 110% of the sampling interval,
   we suddenly drop back to only extrapolate to half a sampling interval.
   
   This behavior can be nicely seen in the testcounter_zero_cutoff test,
   where the rate goes up all the way to 0.7 and then jumps back to 0.6.
   
   This commit changes the behavior to what was (presumably) intended
   from the beginning: The extension of the extrapolation interval is
   only limited if actually needed to prevent extrapolation to negative
   values, but the "limitation" never leads to _more_ extrapolation
   anymore.
   
   The difference is subtle, and probably it never bothered anyone.
   However, if you calculate a rate of a classic histograms, the old
   behavior might create non-monotonic histograms as a result (because of
   the jumps you can see nicely in the old version of the
   testcounter_zero_cutoff test). With this fix, that doesn't happen
   anymore.
   
   Signed-off-by: beorn7 <beorn@grafana.com>

   

   beorn7 committed Mar 7, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 7f912db
   • Browse repository at this point

   Copy the full SHA

   7f912db View commit details

   Browse the repository at this point in the history