7

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.

user692942
  • 16,398
  • 7
  • 76
  • 175
lapsus
  • 2,915
  • 2
  • 32
  • 61
  • 1
    Odd. Have you started using a Mac on the client end recently? They have a bad habit of squeezing in \r where you meant \n. – Jason May 22 '17 at 23:47
  • No definitely no Macs here ;-) I believe what's happening is this: In Fiddler the line ending is always \r\n. Influxdb sees the \n and strips it away. \r remains... and that's probably the issue here - not the timestamp. Nor my client application. Using Fiddler for testing purposes caused brought up new errors. Influxdb should support CRLF! – lapsus May 23 '17 at 06:11
  • Ah, here we go... https://github.com/influxdata/influxdb/issues/6037 That and other Line Protocol oddities. Search for \r on the page. On Windows boxen, I've only been using the InfluxDB-Python package or used the CLI tool: INSERT etc. I haven't been rolling my own queries in Windows. The package and CLI tool must take care of this issue under the hood - I've not yet been bitten by this one. – Jason May 23 '17 at 07:42

2 Answers2

11

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.

0

I find curl useful for putting my data,i wrote my data on file. Then use this:

curl "http://localhost:9999/api/v2/write?org=YOUR_ORG&bucket=YOUR_BUCKET&precision=s" \ --header "Authorization: Token YOURAUTHTOKEN" \ --data-binary @pathfile/data.txt

I highly suggested --data-binary except --data because of \n not read on --data

https://v2.docs.influxdata.com/v2.0/write-data/#example-api-write-request

reihaneh
  • 7
  • 3