Error in line protocol

I’m trying to enter a single datapoint using line protocol.
Here is my entry:

certMeas,category=“Blended Learning” courseid=2403i,completion=100 1656367200

and this is the error:


I think my entry looks very similar to this example taken from Influx documentations:

measurement1,tag1=tagvalue1 field1=1i,field2=1,field3=“a” 1626118680000000000

so I can’t understand where the error is.
I tried padding timestamp with trailing zeros to no avail.

New to InfluxDB, but I think that your tag of category would not use quotes (only fields use quotes for values) as seen by field3 in your example. Use the \ operator to escape the space

Try the following:
certMeas,category=Blended\ Learning courseid=2403i,completion=100 1656367200

Note: ChatGPT may have been consulted for this question :sweat_smile:

Thank you for the tip, I partially solved my problem.
I was assuming you could have quoted strings as tag values, since in their “Time to Awesome” document they have this kind of examples:

measurement1,tag1="tagvalue1",tag2="tagvalue4" field1=1i 1626118620000000000

I recall trying to put a literal value, such as tag1 without succeeding anyway, but this was probably due to the second error source, an issue with timestamp.
If I use the correct syntax you suggested specifying a seconds precision:

certificates,category=Blended\ Learning courseid=2403i,completion=100 1656367200

I still get an error. If I drop the timestamp the line protocol works:

certificates,category=Blended\ Learning courseid=2403i,completion=100

According to ChatGPT, the new “Oracle” (in the ancient greek meaning of the term :nerd_face:):

In InfluxDB line protocol, the timestamp should be a 64-bit signed integer, which represents the number of nanoseconds since January 1, 1970 UTC. This means that the timestamp can have up to 19 digits, including negative values for timestamps before the epoch.

My Unix timestamp comes straight from a MariaDB table and is 10 digits wide, corresponding to elapsed seconds since origin of Unix time.
Since the default precision is nanoseconds, I added 9 digits to convert it to the right UOM:

certificates,category=Blended\ Learning courseid=2403i,completion=100 1656367200000000000

but InfluxDb still raises an error.

1 Like

I will open a separate thread for the timestamp issue

when you open the connection you specify the resolution of your timestamp. We use ms, so the timestamp in the line protocol in our case has to be in ms. If i remember well, default is ns. You have to specify if you use something else.

1 Like

I also see in your latest exmples that you have == rather than = between category key and category value. I wonder how it can work.

My apologies, it’s a mistype, the Line protocol uses just one = character.

Thank you for your advice.
I’m uploading individual Line protocol entries from the InfluxDB UI. From there I can control the timestamp resolution (seconds/milliseconds/noanoseconds), e.g. on my first try:

line is:

certificates,category=BlendedLearning courseid=2403i,completion=100 1656367200

I can change resolution to Milliseconds adding three trailing zeros to timestamp, e.g.:

and I can obviously do similar adjustments in microseconds or nanaseconds.
In all cases I get this error:


If I paste the line protocol example InfluxDB provides on the bottom of the same page I get an error as well:

I can’t help. Especially for this unknown error.
I’d try by deleting all the data you have written so far in this bucket and _measurement, and starting over.
Delete data | InfluxDB Cloud Documentation Might be worth trying if you have time.

Thank you for your suggestion, I had already tried that to no avail.
Just wondering, did you manage to enter data points specifying the timestamp?

yes sure. I do that from early influx 1. No issue. I use timestamp in ms.
Now we are still with influx 2.1.1 but it is such a basic feature that everybody would complain about it. I let someone else add suggestions

Thank you, that’s what I expected.
I agree it’s such a basic flaw it must either be a glitch on the very last version using the iox storage engine or it’s me doing something really weird/silly.

1 Like