Different query response on 'same' query

InfluxDB 1
,
1

Hi guys I’m new here in the forum, use in InfluxDB (1.x) however already for some time. Now I am facing a problem that I just don’t understand. I couldn’t find anything similar in the forum (maybe I didn’t search for the right keyword).
I would appreciate your help very much.

I use InfluxDB in version 1.8, I have a database in which I store log files via Python. All timestamps are UTC. I now want to know the number of certain values in my fields over time. The following queries which I would expect to return the same, return something different:

4
41333×660 77.6 KB

First Query: As you can see there is a big difference in the results. I was a bit unsure about the timestamp as the second one is UTC and the first is my timezone (Europe/Berlin), thats why i tried this query.

Second Query: I just added the ‘tz’ at the end. For me this looks like, that Influx is just adapting the time. The query result stays the same.

Third Query: Now on the this query it gets really strange (well at least for me). I added the ‘tz’ parameter to my first query and i get a different result.

So there is a difference for Influx if i query with a custom time range or the predefined ‘now()’ keyword. But i would expect if i take the same time (like i do for my sample queries) for a custom range as for the predefined, i get the same results. I now that the returned data for the custom range is right but why i didn´t get that data on the predefined ‘time now()’.

Thank you in advance for your help

2

Hello @nicoina,
How are the two queries in the 1st screenshot equivalent? One is for an hour between a specific timestamp and the other one is from when you ran the query.

I don’t see any of the query results being the same. I’m not sure what you mean. From my understanding in the 1st screen shot you ran the query without the tz and added it the second. Your count values are different (161 and 155). It’s unclear to me what’s causing the discrepancy. Is it the tz? The use of now() and running the queries at different times? A combination of both?

Why is adding a timezone and getting a different result surprising? I would imagine that querying from a different time range would result in different values?

To test whether you’re getting different results I would match your timestamp with your now() value to the second with the same tz. I don’t know enough about your data to know whether it makes sense for you to write a few points in a couple minutes. Or in the case where you add tz if that change in range rationally explains why you have 30 more points. Is it possible that at another hour you wrote 2x as many points?Or that you’re writing an additional 2-4 points between in 2 minute query run time differences?That doesn’t sounds out of the ordinary though.

How frequently are you writing data?
Do you get the same results when you run the same query?
Can you please tell me more about how you’re writing data?
What did you expect with your queries?
Why don’t you think that tz or discrepancies between now()-1h and specified time ranges wouldn’t affect your count?

Any answers to these questions can help me. Thanks!!

3

Hi @Anaisdg

first of all thank you for your reply. I was not clear enough i think. Originally i discovered this “error” when using my measurement in Grafana. The data displayed with the range “Last hour” resulted in different results, than using the same time range (few seconds inbetween), but from the custom time range picker.

The time i´m exectuing the query with the now() keyword, was just before i used the custom time range. So the time between the two queries is just some seconds for each pair and i know from my datasource, that the difference can not be that high. The time difference between the 1. and 3. pair is because i was writing this thread in paralel. But for each pair, i would expect the same count (maybe one count difference)

So i started to localize the problem, which leads to the queries with the tz parameter, as my assumption was, that there is some issue between my timestamps and the timezone.

The frequency is given by a logfile, that is written by a MES system and is not equidistantly but below one second.

If i use the same way to define the time, i get the same results.

I have a logging tool, that is observing my logfile and i have a tail here. As well i know where my logging tool stopped (which line) in case something crashes. So nothing gets written twice. I am extracting relevant information from the logs and write this to Influx. I am using the timestamp, that is provided for every log line and transforming this to UTC.

I would expect, that my query independently of the way i am defining my time range, is returning the same. So if now()-1h is from 10 to 11 o´clock and it returns 42, then i would expect the same if i define the same time range by hand.

Maybe i dont know enough about the tz command, but for me it looks like, that the tz is just transforming the timestamp to the handed timezone. In case of the count command, that would mean for me, that i just get a “different” starting-timestamp like +2h (‘Europe/Berlin’) but the same count.
Of course there could be a difference, if the data gets written fast. In my case i am counting good/bad parts of my production machine and a new part is finished around every 2-3 minutes.

I have the feeling, i am on the wrong track, regarding the way how i write the timestamp. I was thinking all the time to transform them to UTC at first and the use that timestamp for my record.

4

Hello @nicoina,
Yes I believe you’re right. I was thinking about it wrong. I haven’t used influxQL in quite some time.
Thank you for your detailed response.
Can you please submit an issue?
I agree this looks like a bug but I don’t know how to fix it.

5

I didn´t gave up on my issue and i got it to work the way i expect it. The code i have implemented is in python. When i´m fetching my timestamp from the logs, that are already in my local timezone, i am additionally “casting” the datetime object to my local timezone. Following the saying, two is better than one.
Afterwards every datetime object has the additional information of +02:00. Now the query result returned by InfluxQL and also in Grafana is as i expect. So still not sure if i was to stupid or if it is really a bug but for me it solves my problem.

1 Like