InfluxDB Line Protocol Bad Timestamp

Question

I'm trying to POST this data:

my_tests,SNR=533033200650344358002D00,TNR=test HelloWorld=123 1495179651177999872
my_tests,SNR=533033200650344358002D00,TNR=test HelloWorld=444 1495179651203000064

The POST Url looks like that

http://influx.local:8086/write?db=testdb&u=myuser&p=myasswd

Raw Response:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Request-Id: 4a1802d2-3ebd-11e7-8030-000000000000
X-Influxdb-Version: 1.1.4
Date: Mon, 22 May 2017 07:07:17 GMT
Content-Length: 147

{"error":"partial write:\nunable to parse 'my_tests,SNR=533033200650344358002D00,TNR=test HelloWorld=123 1495179651177999872\r': bad timestamp"}

The timestamp looks valid to me.
If I only POST one line (not two as in the example above) it works quite fine!
I'm also wondering what the "\r" is doing there at the end of the error log after the timestamp. Because I am writing "\n".

Interestingly I didn't have any problems writing to InfluxDB until recently. No version upgrade involved.

I'm running InfluxDB 1.x (not sure which version exactly)

To complete the confusion... if I entirely omit the timestamp (for testing purposes) it still doesn't work:

{"error":"partial write:\nunable to parse 'my_tests,SNR=533033200650344358002D00,TNR=test HelloWorld=123\r': invalid number"}

UPDATE: For testing purposes I installed InfluxDb 1.2.7 (Windows Standalone)
Payload is the same as previously

my_tests,SNR=533033200650344358002D00,TNR=test HelloWorld=123 1439856000
my_tests,SNR=533033200650344358002D00,TNR=test HelloWorld=444 1439856001

Influx reports back:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Request-Id: eca5283a-3ec4-11e7-8029-000000000000
X-Influxdb-Version: 1.2.4
Date: Mon, 22 May 2017 08:01:56 GMT
Content-Length: 147

{"error":"partial write: unable to parse 'my_tests,SNR=533033200650344358002D00,TNR=test HelloWorld=123 1439856000\r': bad timestamp dropped=0"}

All these tests where conducted using Fiddler Composer.

Answer 1

See the comments as they contain the answer. However, here is what is going on:

my_tests,SNR=533033200650344358002D00,TNR=test HelloWorld=123 1495179651177999872\r\n 
my_tests,SNR=533033200650344358002D00,TNR=test HelloWorld=444 1495179651203000064

The problem is that carriage return - also called newline (\n), and linefeed (\r) are separating the two entries. This convention is used by Windows (CRLF). The solution is to be sure you are using "Linux" conventions for line endings.

Even if only one line is sent, the linefeed character is problematic. An unrelated problem that is seen frequently is "invalid boolean". If the first use of a field can be construed by influx as boolean (any of 't', 'true', 'True', 'TRUE', 'f', 'false', 'False' or 'FALSE') then influx will forever make that field a boolean. Finally be careful about fields that may have embedded blanks, commas or other oddities. I recommend two preventive measures:

1. For any field that is an integer, suffix the value with i e.g.: HelloWorld=123i
2. For string values, be sure to quote them. As soon as a value arrives with a space in it, your linedata will bust. Eg. TNR="test" tells influx your data is a string.

See the Influx Line Protocol documentation for more.