-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Incorrect value stored in database #6643
Comments
@bwight thanks for the report. I've tried to reproduce with the data provided but I'm unable to. Just to clarify—are you saying that the only points written to produce the bad result are the ones included in your report? Or was more data written to produce this? |
Hi @e-dard I appreciate your response. Yes there is a lot more data that we're inserting into influx. The data that I uploaded was only for that series for a period of about 2 hours. I'm going to try and make a script that can reproduce this bug and then I will share that here. |
That would be great @bwight thanks! |
Somewhat similar but not necessarily related issue: influxdata/telegraf#2050 |
Similar problem reproduces very often for us on Fedora 23, Linux 4.7.9-100.fc23.x86_64 #1 SMP Thu Oct 20 15:59:59 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux, InfluxDB 1.0.0. Haven't verified this on InfluxDB 1.1 yet. I've marked a specific point in time in the example below with "-MARK-". Before the mark the data does not match and there are negative values in influxdb, after the mark the data points match. Here's a sample of the input data:
Here's the same data points raw from influxdb using "select time, free from disk where host='7026' and time > now() - 25m and path =~ /service/":
Visually the error pattern is very similar most of the time, please see the screenshot in influxdata/telegraf#2050 |
In my case (message above) the problem disappeared after upgrading influxdb from 1.0 to 1.1. |
This is likely fixed by #7397 in |
Bug report
System info:
InfluxDB: 0.12.1
OS: linux 4.4.5-15.26.amzn1.x86_64
Docker Image: tutum/influxdb 0.12 33b36625800c
We're using the statsd protocol and using telegraf's statsd input plugin to write the points to influxdb.
Steps to reproduce:
We are not yet clear exactly how to reproduce this bug. However it does happen frequently due to the amount of metrics that we report. At least a couple times a day we're experiencing a bug that causes the query we run on the data to return values that we never inserted into the database.
We identified this issue because of unexpected negative values that were being reported from counters that we reported using the statsd protocol. Telegraf does not allow negative values to be reported as a counter, only the gauge type allows for negative values.
To help track down this issue to at least rule out Telegraf or our application counters as the issue we enabled write tracing on influx and here was the result.
Query
Query Result
As you can see here the unexpected value of -4 at 2016-05-13T23:04:10Z that was inserted. So knowing this we looked at the write tracing and here's a grep of that file to match the query that we show above.
Write Trace
We also noticed that its not just the -4 that's incorrect but also the 4 that was inserted on the line after that. The rest of the writes are in line with what was posted as well as the timestamps.
Retention Policy
Continuous Queries
write-trace-1463180650.txt
influxdb-config.txt
The text was updated successfully, but these errors were encountered: