Strange behavior when using "to" function in a task

Hello,
I have a task executed each 10 minutes, which is in charge to sum several values, stored in several measurement (let’s say cpu_global = cpu1 + cpu2 + cpu3…) – in the task, the values are summed and then the result is saved into a destination bucket with the “to” function,
The sum is correctly computed, stored in destination bucket, but it seems that the time precision is not always the same.
What makes me think this is that when I’m trying to retrieve values from the measurement “cpu_global”, values are returned in different tables (so the graph is displayed with zigzags and strange shapes). The only way to get them in the same table and display it correctly is to “truncate” the _time column to put all the records at the same time unit : r with _time: date.truncate(t: r._time, unit: 1s)).

What is the expected behavior for “to” function (or maybe (or maybe I’m not using the “to” function in the correct way?) How to ensure the time precision in a task and avoid this kind of issue ?

The code for my task :

from(bucket: “test”)
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r._measurement =~ /cpu.*/)
|> aggregateWindow(every: 10m, fn: sum, createEmpty: true)
|> group(columns: [“_time”], mode: “by”)
|> sum(column: “_value”)
|> group()
|> map(
fn: (r) => ({r with _measurement: “cpu_global”, _field: “bla”, units: “bla”, location: “bla”}),
)
|> keep(
columns: [
“_time”,
“_measurement”,
“_value”,
“_field”,
“units”,
“location”,
],
)
|>to(bucket: “destination”)

1 ) Query to get the result :
from(bucket: “destination”)
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r._measurement == “cpu_global”)

==> data splitted in table 0 and table 1 and strangely graphed

2 ) Query with the truncated :

import “date”
from(bucket: “destination”)
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r._measurement == “cpu_global”)
|> map(fn: (r) => ({ r with _time: date.truncate(t: r._time, unit: 1s) }))
|> sort(columns: [“_time”])

==> only one table and graph is OK

@Sissi Can you share a sample of the data that gets returned when you query the destination bucket?

@scott sorry for the late reply, hereafter a sample of the data returned by a query (executed with postman – hoping it suits for the investigation, otherwise let me known what I can add as a complement)
cpu_global.txt (14.5 KB)

Hi,
now idea of the source of your problem…
can you check the full time precision of your data using a request from the API ?
But i don’t think it’s the source of the problem, i did check with fake data and even with different precision it’s going in the same table in my test:

,result,table,_start,_stop,_time,_value,_field,_measurement,tagKey
,_result,0,2024-02-06T11:18:44.544017833Z,2024-02-06T11:28:44.544017833Z,2024-02-06T11:27:15.099319329Z,fieldValue1,fieldKey,test_timestamp,tagValue1
,_result,0,2024-02-06T11:18:44.544017833Z,2024-02-06T11:28:44.544017833Z,2024-02-06T11:27:34.572886Z,fieldValue1,fieldKey,test_timestamp,tagValue1

So it’s strange why applying the map on time merge your tables…

Hi @thomasbromkapsdata you asked me to check the full time precision of my data using a request from the API : any suggestion / how can I do it ?
If it’s not the source of the problem, maybe there is something I did wrong in the query to compute cpu_global, which is writing data into the destination bucket in different tables ? I’m still quite lost…
thanks a lot!

Hi,
you can use “curl” by example from your command line interface.
API doc
I guess you do quit the same with postman but the timestamps in your output example are only with second precision, so it’s hard to tell the effect of your truncation.
But again, i don’t think it come from the time precision… in my usual experience 2 tables say we have to different times series so 2 sets of tag values…