Influxdb suddenly stopped accepting incoming data (status code 400)

I’m trying to understand the log excerpt below. Its from around the time when my influxdb instance stopped accepting values that are being sent to it every minute (and which it had been writing fine for several hours before).

So, as you can see: until 04:19:31, everything was working fine. and then suddenly it started failing.

The error message I’m getting on the other end (i.e. on 192.168.1.8) is InfluxdbError: Request failed (status='400', reason='Bad Request', params='db=FTX&precision=ns').

[httpd] 192.168.1.8 - - [01/Sep/2020:04:15:30 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 204 0 "-" "-" 02493513-ebf9-11ea-84a7-4c5262097e59 12035,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:16:30 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 204 0 "-" "-" 26082106-ebf9-11ea-84a8-4c5262097e59 7782,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:16:30 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 204 0 "-" "-" 2631ef09-ebf9-11ea-84a9-4c5262097e59 11820,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:17:30 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 204 0 "-" "-" 49ea5cc6-ebf9-11ea-84aa-4c5262097e59 9402,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:17:31 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 204 0 "-" "-" 4a148335-ebf9-11ea-84ab-4c5262097e59 11225,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:18:31 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 204 0 "-" "-" 6dd1abaa-ebf9-11ea-84ac-4c5262097e59 86541,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:18:31 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 204 0 "-" "-" 6e0010a1-ebf9-11ea-84ad-4c5262097e59 27788,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:19:31 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 204 0 "-" "-" 91cd70ad-ebf9-11ea-84ae-4c5262097e59 12279,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:19:31 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" 91e1edf5-ebf9-11ea-84af-4c5262097e59 38205,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:19:33 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" 9319bb81-ebf9-11ea-84b0-4c5262097e59 71,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:19:37 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" 957d2bef-ebf9-11ea-84b1-4c5262097e59 73,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:19:45 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" 9a438f33-ebf9-11ea-84b2-4c5262097e59 74,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:20:01 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" a3cfe081-ebf9-11ea-84b3-4c5262097e59 72,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:20:33 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" b6e67d2a-ebf9-11ea-84b4-4c5262097e59 73,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:21:33 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" daab7fad-ebf9-11ea-84b5-4c5262097e59 84,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:22:33 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" fe758c0a-ebf9-11ea-84b6-4c5262097e59 71,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:23:33 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" 223f4e66-ebfa-11ea-84b7-4c5262097e59 73,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:24:33 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" 460bf2eb-ebfa-11ea-84b8-4c5262097e59 70,
ts=2020-09-01T02:25:17.681949Z lvl=info msg="Retention policy deletion check (start)" log_id=0OyS6Be0000 service=retention trace_id=0Oys_1SG000 op_name=retention_delete_check op_event=start,
ts=2020-09-01T02:25:17.681981Z lvl=info msg="Retention policy deletion check (end)" log_id=0OyS6Be0000 service=retention trace_id=0Oys_1SG000 op_name=retention_delete_check op_event=end op_elapsed=0.044ms,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:25:33 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" 69d4ffce-ebfa-11ea-84b9-4c5262097e59 70,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:26:33 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" 8d9dbfb6-ebfa-11ea-84ba-4c5262097e59 82,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:27:33 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" b16ab053-ebfa-11ea-84bb-4c5262097e59 72,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:28:33 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" d53742b5-ebfa-11ea-84bc-4c5262097e59 72,
ts=2020-09-01T02:29:31.910163Z lvl=info msg="Cache snapshot (start)" log_id=0OyS6Be0000 engine=tsm1 trace_id=0OysoYXW000 op_name=tsm1_cache_snapshot op_event=start,
ts=2020-09-01T02:29:31.999448Z lvl=info msg="Snapshot for path written" log_id=0OyS6Be0000 engine=tsm1 trace_id=0OysoYXW000 op_name=tsm1_cache_snapshot path=/var/lib/influxdb/data/FTX/autogen/2 duration=89.302ms,
ts=2020-09-01T02:29:31.999482Z lvl=info msg="Cache snapshot (end)" log_id=0OyS6Be0000 engine=tsm1 trace_id=0OysoYXW000 op_name=tsm1_cache_snapshot op_event=end op_elapsed=89.333ms,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:29:34 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" f8ffd9e4-ebfa-11ea-84bd-4c5262097e59 69,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:30:34 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" 1cc9e706-ebfb-11ea-84be-4c5262097e59 75,
[httpd] 192.168.1.8 - - [01/Sep/2020:04:31:34 +0200] "POST /write?db=FTX&precision=ns HTTP/1.1" 400 310 "-" "-" 40952c73-ebfb-11ea-84bf-4c5262097e59 70,

In case it matters: I’m running influxdb in a docker container and I’m not using any username or password. The FTX database is up and running, from what I can tell based on this:

I’m new to influxdb, so any hint would be appreciated.

Edit:
I realize that the default data type for numbers is float and I’m not sure where the limits for that data type is but I have one field value that is at 27665997 (and it is not being sent as an integer). Is that too large a value for a float? If so, is there a way of having influxdb accept it as an integer (even without the appended i?

I still don’t quite understand what caused the error but I seem to have solved it by declaring my integer values as integers (by appending an i). Influx has been accepting incoming data now for over 24 hours, so I guess it’s working now.

1 Like