New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sum and sum_over_time returning incorrect value when increasing period #563
Comments
VictoriaMetrics may adjust the returned timestamps if the number of returned data points exceeds 50 - see the corresponding comment in the code for details. This behaviour can be disabled by passing |
The number of points are not increasing... We are just seeing the same
points from a longer perspective... And so we expect the same results. But
curiously when increasing the query period, the last interval is truncated
and so the count is false. You can see it in the query example I posted at
the beginning of this post.
Le jeu. 18 juin 2020 à 23:49, Aliaksandr Valialkin <notifications@github.com>
a écrit :
… VictoriaMetrics may adjust the returned timestamps if the number of
returned data points exceeds 50 - see the corresponding comment in the
code
<https://github.com/VictoriaMetrics/VictoriaMetrics/blob/a6f16dcc11891c7ab1dbe3e3129cee7210da17bc/app/vmselect/promql/eval.go#L23>
for details.
This behaviour can be disabled by passing -search.disableCache
command-line flag to VictoriaMetrics. Another option is to pass nocache=1
query arg to /api/v1/query_range.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#563 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEUPYQCLOB6V5VEUS43Z3CTRXKDXHANCNFSM4N6LIM5A>
.
|
Hello,
as you can see i have a tunnel to localhost:28428 that access directly to the VM API.
Okay this is what we expect - same result than on 7 days - same interval returned by the API
Bingo ! Here is the "bug" - the date interval suddenly changed with a +2:00:00 - changing the interval counts and even the number of interval. |
@omerlin , thanks for the detailed investigation! VictoriaMetrics should store and process all the timestamps in UTC. I'll double check this and return back with findings. |
@valyala, thanks for all your good work. |
@omerlin , see build instructions here. I'd suggest you exporting all the raw data that is used in the query via /api/v1/export (just pass |
@valyala, i'm working on it. Just one question about the /write API. We are using the InluxDB data format with the timestamp to do the backfilling. But do we need to have a TZ timestamp or a UTC timestamp ? |
VictoriaMetrics treats all the timestamps in the ingested data as UTC. |
@valyala i finally found the issue - this is not related to timezone but to the modulo function used to have cache buckets alignment.
As i'm using Grafana i cannot add a form &nocache=1 in my request and i'm entering in the
as line 26 we have :
then over 50 days, the start/end are altered with rounding logic inside the function Do you think it could be possible to make the nocache activation per configuration (as the server configuration search.nocache is not taken into account for this kind of query ) ... Btw ... when writing data using UTC and reading back with grafana i didn't have the issue because my start/step were modulo 86400 !! |
…api/v1/query_range` when `-search.disableCache` command-line flag is set Updates #563
…api/v1/query_range` when `-search.disableCache` command-line flag is set Updates #563
@omerlin , thanks for the investigation! The commit f0c678c stops adjusting of |
@valyala, thanks again for reactivity ! I have tested and it's working perfectly has expected. |
Yes. |
The bugfix has been included in v1.39.3. The bugfix stops adjusting Closing the issue as fixed. @omerlin , probably it would be better aligning |
This is not possible easily as the request is sent by grafana using day granularity ... so the start and end are by default defined using local TZ ... as VictoriaMetrics is using UTC for all its calculation. So using last 30 days, last 90 days buttons ... the start and stop are not aligned with internal caching |
Describe the bug
When querying data until current timestamp with sum() functions and increasing the period of aggregation (7 days, 30 days, 90 days ...), the count becomes incorrect
To Reproduce
Simply provision data in VM until now (7 days for instance). Then print out the total value of the data and see the same data in bigger window (30 days, 90 days, 1 year , ...)
You will see that the total value - that should be invariant - will decrease because the last interval is no more taken into account
Please note that this do not happen if the data are provisioned in the past ( 2 weeks ago for instance) - meaning this is completely related with last time interval.
For example:
This query on 7 days :
api/v1/query_range?query=sum%20by(profile_type)%20(sum_over_time(euicc_total%7Boperator%3D%22STC%22%20%2C%20profile_type%3D~%22profile3%22%2C%20mno%3D~%22TMNO3%22%7D))&start=1591567200&end=1592172000&step=86400
return
The same query on 90 days
api/v1/query_range?query=sum%20by(profile_type)%20(sum_over_time(euicc_total%7Boperator%3D%22STC%22%20%2C%20profile_type%3D~%22profile3%22%2C%20mno%3D~%22TMNO3%22%7D))&start=1584396000&end=1592172000&step=86400
return this:
as you can see the last interval timestamp has changed - and the last interval until now is missing
This has been reproduced on many screens ... always with the same side-effect.
Expected behavior
The count must not change
Screenshots
I could put screenshot but i think the investigation i did on the query are more clear
Version
The line returned when passing
--version
command line flag to binary. For example:Used command-line flags
/opt/victoriametrics/victoria-metrics-prod -storageDataPath /u01/reporting/victoriametrics/data -retentionPeriod 36 -influxSkipSingleField -search.maxStalenessInterval=5m
Additional context
The text was updated successfully, but these errors were encountered: