- Fix copy-paste bug: smoothed branch in bare MatrixSelector eval now
says "smoothed modifier is not supported with histograms" instead of
"anchored".
- Change annosFromInterpolationError to take *annotations.Annotations,
consistent with all other histogram helper functions.
- Rename delta to result in interpolateHistograms to avoid the misleading
name (the variable holds the interpolated result, not a delta).
- Fix extendedRate doc comment: interpolates at boundaries, not
extrapolates.
- Fix stale comment in correctForCounterResetsHistogram that referenced
the nonexistent variable leftInterpolationHandledReset.
- Add comment explaining why right.Copy() is not redundant in
extendedHistogramRate.
- Hoist s.Labels().Get(labels.MetricName) out of the per-step loop in
smoothSeries; was called up to three times per step.
- Reset CounterResetHint to UnknownCounterReset on carry-forward
histograms in smoothSeries; a Reset hint at a new timestamp is
semantically misleading.
- Add TestInterpolateHistograms unit test covering exact-match, midpoint,
counter, reset, and quarter-point cases.
- Add rate(hist_counter[1m] anchored) test.
- Add delta(hist_counter[1m] anchored/smoothed) tests with
NativeHistogramNotGaugeWarning assertions.
- Add carry-forward test for smoothed vector selector.
- Add range eval test for rate(hist_counter[1m] smoothed).
- Add right-boundary reset interpolation test (right_boundary_reset).
- Fix stale test comment about "prev initialPrev path".
Signed-off-by: Julien Pivotto <291750+roidelapluie@users.noreply.github.com>
Add native histogram support for the smoothed and anchored rate
modifiers (rate, increase, delta). Previously these modifiers only
worked with float samples and errored on native histograms.
The implementation adds histogram interpolation helpers that mirror
the float versions, and a dedicated extendedHistogramRate() function
parallel to extendedRate(). The smoothSeries() function for smoothed
vector selectors now also handles histogram interpolation.
Signed-off-by: Julien Pivotto <291750+roidelapluie@users.noreply.github.com>
smoothSeries() was stamping output points at offset-adjusted timestamps
instead of evaluator timestamps. When the @ modifier is used, this
causes gatherVector() to miss the points because it matches by exact
timestamp equality against evaluator step timestamps.
Fix by iterating over evaluator timestamps and deriving data timestamps
by subtracting the offset, so output points align with what
gatherVector() expects.
Signed-off-by: Julien Pivotto <291750+roidelapluie@users.noreply.github.com>
When last_over_time or first_over_time is applied to a subquery that
contains functions like abs(), round(), etc., the DropName flag should
be preserved. Previously, the flag was unconditionally overwritten based
solely on the function name, ignoring the input series state.
This fix checks if the input series (from a subquery) already has
DropName=true and respects that flag by using OR logic.
Before this fix:
last_over_time(abs(metric)[10m:]) incorrectly returned {__name__="metric", ...}
After this fix:
last_over_time(abs(metric)[10m:]) correctly returns {...} without __name__
The same behavior applies to first_over_time().
Fixes#18397
---------
Signed-off-by: Vamsi Mathala <vmathala@redhat.com>
Some timestamp functions can be safely wrapped as a step invariant.
Then once we do that we never need to check or unwrap at evaluation time.
For instance; `timestamp(metric @ 1)` is step invariant, whereas
`timestamp(abs(metric @ 1))` is not.
Currently all `timestamp` `*parser.Call` are excluded from being
considered step invariant since it is listed in the
`AtModifierUnsafeFunctions` map.
This PR adds an extra check for timestamp functions which consider
the arguments, and if the argument is a simple VectorSelector then
the entire `*parser.Call` can be safely wrapped as a step invariant.
Signed-off-by: Andrew Hall <andrew.hall@grafana.com>
Co-authored-by: Bryan Boreham <bjboreham@gmail.com>
The query log embeds a spanID, but omits the traceID, making
log/trace correlation significantly more difficult.
Add the trace ID as well.
This might be better done with the otelslog wrapper in
https://github.com/go-slog/otelslog but this change is more
minimal.
This does not add trace and span IDs to other logging
emitted to Prometheus's standard logger during the processing
of activities in which traces may be active.
Fixes#18188
Signed-off-by: Craig Ringer <craig.ringer@enterprisedb.com>
Parser configuration is now per-engine/API/loader and no longer uses package-level flags, so behavior is consistent and tests don't rely on save/restore of global variables.
Signed-off-by: Martin Valiente Ainz <64830185+tinitiuset@users.noreply.github.com>
As for float samples, Kahan summation is used for the `sum` and `avg` aggregation and for the respective `_over_time` functions.
Kahan summation is not perfect. This commit also adds tests that even Kahan summation cannot reliably pass.
These tests are commented out.
Note that the behavior might be different on other hardware platforms. We have to keep an eye on test failing on other hardware platforms and adjust them accordingly.
Signed-off-by: Aleksandr Smirnov <5targazer@mail.ru>
Fix incorrect interpolation when counter resets occur in smoothed range
selector evaluation. Previously, the asymmetric handling of counter
resets (y1=0 on left edge, y2+=y1 on right edge) produced wrong values.
Now uniformly set y1=0 when a counter reset is detected, correctly
modeling the counter as starting from 0 post-reset.
This fixes rate calculations across counter resets. For example,
rate(metric[10s] smoothed) where metric goes from 100 to 10 (a reset)
now correctly computes 0.666... by treating the counter as resetting
to 0 rather than producing inflated values from the old behavior.
Signed-off-by: Julien Pivotto <291750+roidelapluie@users.noreply.github.com>
This implements the TRIM_UPPER (</) and TRIM_LOWER (>/) operators
that allow removing observations below or above a threshold from
a histogram. The implementation zeros out buckets outside the desired
range. It also recalculates the sum, including only bucket counts within
the specified threshold range.
Fixes#14651.
Signed-off-by: sujal shah <sujalshah28092004@gmail.com>
This implements the TRIM_UPPER (</) and TRIM_LOWER (>/) operators
that allow removing observations below or above a threshold from
a histogram. The implementation zeros out buckets outside the desired
range. It also recalculates the sum, including only bucket counts within
the specified threshold range.
Fixes#14651.
Signed-off-by: sujal shah <sujalshah28092004@gmail.com>