promql: fix rate calculation with a counter reset after the 1st sample#15902
Merged
promql: fix rate calculation with a counter reset after the 1st sample#15902
Conversation
…gram If a rate (or increase) is calculated on native histograms, and there is a counter reset between the 1st and 2nd histogram, we never have to touch the 1st histogram, so it doesn't even matter if it has an incompatible bucket layout. So we should not error out in that case. This simply nulls out the 1st histogram in that case. Signed-off-by: beorn7 <beorn@grafana.com>
Contributor
|
Thank you @beorn7. |
charleskorn
added a commit
to grafana/mimir
that referenced
this pull request
Mar 11, 2025
…te` and `increase` if the second point is a reset (prometheus/prometheus#15902)
charleskorn
added a commit
to grafana/mimir
that referenced
this pull request
Mar 11, 2025
…te` and `increase` if the second point is a reset (prometheus/prometheus#15902)
charleskorn
added a commit
to grafana/mimir
that referenced
this pull request
Mar 11, 2025
…te` and `increase` if the second point is a reset (prometheus/prometheus#15902)
charleskorn
added a commit
to grafana/mimir
that referenced
this pull request
Mar 11, 2025
…te` and `increase` if the second point is a reset (prometheus/prometheus#15902)
charleskorn
added a commit
to grafana/mimir
that referenced
this pull request
Mar 12, 2025
* Upgrade mimir-prometheus * Bring in upstream test changes * Apply change to match prometheus/prometheus#15974 * Remove test case added in upstream in prometheus/prometheus#15975 * Add tests for case where range vector selectors and subqueries have 0 range Brings in change from #10586 * Update `sort` and `sort_desc` behaviour to match prometheus/prometheus#15964 * Add support for native histograms to `irate` and `idelta` to match prometheus/prometheus#15853 * Adjust test cases to match support for native histograms in `irate` and `idelta` * Change binop annotations to match behaviour in prometheus/prometheus#15895 * Ignore incompatible schemas between the first and second point in `rate` and `increase` if the second point is a reset (prometheus/prometheus#15902) * Adjust annotation test cases to match new behaviour introduced in previous commit * Disable tests failing due to prometheus/prometheus#16199 * Add changelog entry * Update `TestQuerySharding_FunctionCorrectness` to reflect changes in prometheus/prometheus#15964
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If a rate (or increase) is calculated on native histograms, and there is a counter reset between the 1st and 2nd histogram, we never have to touch the 1st histogram, so it doesn't even matter if it has an incompatible bucket layout. So we should not error out in that case.
This simply nulls out the 1st histogram in that case.
@NeerajGartia21 as discussed.