prometheus

History

beorn7 7f912db15a 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>		9 months ago
..
fuzz-data	…
parser	fix: restore ability to match __name__ multiple times in selector	9 months ago
testdata	promql: Fix limiting of extrapolation to negative values	9 months ago
bench_test.go	Proposal to improve FPointSlice and HPointSlice allocation. (#13448 )	10 months ago
engine.go	Merge pull request #13536 from bboreham/faster-label-replace	9 months ago
engine_test.go	PromQL: improve warning for mixed values in aggregations	9 months ago
functions.go	promql: Fix limiting of extrapolation to negative values	9 months ago
functions_test.go	golangci-lint: enable testifylint linter (#13254 )	12 months ago
fuzz.go	promql: fuzz test needs symbol table for parser	9 months ago
fuzz_test.go	remove obsolete build tag	10 months ago
promql_test.go	sort_by_label: Switch to feature flag	1 year ago
quantile.go	Move from golang.org/x/exp/slices into slices now that we only support Go >= 1.21	9 months ago
quantile_test.go	PromQL: ignore small errors for bucketQuantile (#13153 )	1 year ago
query_logger.go	add Close for ActiveQueryTracker to close the file.	2 years ago
query_logger_test.go	golangci-lint: enable testifylint linter (#13254 )	12 months ago
test.go	sort_by_label: Switch to feature flag	1 year ago
test_test.go	Add context argument to Querier.Select (#12660 )	1 year ago
value.go	Optimize histogram iterators (#13340 )	10 months ago
value_test.go	Shortcut `ContainsSameLabelset()` (#11000 )	2 years ago