Line protocol

• Quotes
• Comments
• Duplicate points
• Parse errors

Syntax

Example

myMeasurement,tag1=value1,tag2=value2 fieldKey="fieldValue" 1556813561098000000

Line protocol consists of zero or more entries, each terminated by the newline character (\n). A line contains one of the following:

• that represents a point in InfluxDB
• blank line that consists entirely of
• comment that starts with # optionally preceded by whitespace.

Line protocol is . Line protocol string elements may support certain special characters.

Elements of line protocol

Lines that represent data points contain a measurement name, optional , at least one field, and an optional .

measurementName,tagKey=tagValue fieldKey="fieldValue" 1465839830100400200
--------------- --------------- --------------------- -------------------
       |               |                  |                    |
  Measurement       Tag set           Field set            Timestamp

(Required) The measurement name. InfluxDB accepts one measurement per point. Measurement names are case-sensitive and subject to naming restrictions.

*Data type: *

To learn more about designing efficient measurements for InfluxDB, see best practices for schema design.

Tag set

Optional – All tag key-value pairs for the point. Key-value relationships are denoted by the = operand. Multiple tag key-value pairs are comma-delimited. Tag keys and tag values are case-sensitive. Tag keys are subject to .

*Key data type: String
**Value data type:*

Canonical form

Canonical form describes a in which the tags’ decoded values are in lexical order, lowest to highest. Line protocol consumers are often more efficient at decoding points with tags in canonical form.

The data point in the following example has a tag set in canonical form:

# The tag set below is in canonical form.
foo,a\ b=x,aB=y value=99

To learn more about designing efficient tags for InfluxDB, see best practices for schema design.

Field set

(Required) All field key-value pairs for the point. Points must have at least one field. Field keys and string values are case-sensitive. Field keys are subject to .

*Key data type: String
**Value data type:* | Integer | | String |

Always double quote string field values. Learn more about using quotes in line protocol.

measurementName fieldKey="string field value" 1556813561098000000
measurementName fieldKey="\"quoted words\" in a string field value" 1556813561098000000

Timestamp

Optional – Unix timestamp for the data point. InfluxDB accepts one timestamp per point.

If no timestamp is provided, InfluxDB uses the system time (UTC) of its host machine. To ensure a data point includes the time a metric is observed (not received by InfluxDB), include the timestamp.

Nanoseconds is the default precision for timestamps. If your timestamps are not in nanoseconds, specify the precision when writing the data to InfluxDB.

*Data type: *

Example

Whitespace in line protocol determines how InfluxDB interprets the data point. Allowed whitespace characters are regular spaces ( ) and carriage-returns (\r). Carriage-returns (\r) are only allowed as whitespace when they immediately precede a newline (\n). The first unescaped space after the start of the measurement delimits the and the tag set from the . The second unescaped space delimits the field set from the timestamp.

measurementName,tagKey=tagValue fieldKey="fieldValue" 1465839830100400200
                               |                     |
                           1st space             2nd space

Data types and format

Character set

Line protocol is composed of Unicode characters encoded in UTF-8. Non-printable ASCII characters (0x00 - 0x1f and 0x7f) are not allowed.

Float

64-bit floating-point numbers. Note that non-finite numbers (NaN and Inf) are not allowed. Default numerical type.

Float field value examples

myMeasurement fieldKey=1.0
myMeasurement fieldKey=1

InfluxDB supports scientific notation in float field values.

myMeasurement fieldKey=-1.234456e+78

Integer

Signed 64-bit integers. Trailing i on the number specifies an integer.

Integer field value examples

myMeasurement fieldKey=1i
myMeasurement fieldKey=12485903i
myMeasurement fieldKey=-12485903i

Unsigned 64-bit integers. Trailing u on the number specifies an unsigned integer.

UInteger field value examples

String

Plain text string. Length limit is 1.8432MB. 64K is the recommended length limit.

String example

# String measurement name, field key, and field value
myMeasurement fieldKey="this is a string"

Boolean

Stores true or false values.

Boolean field value examples

myMeasurement fieldKey=true
myMeasurement fieldKey=false
myMeasurement fieldKey=t
myMeasurement fieldKey=TRUE
myMeasurement fieldKey=FALSE

Do not quote boolean field values. Quoted field values are interpreted as strings.

Unix timestamp

within the range 1677-09-21T00:12:43.145224194Z to 2262-04-11T23:47:16.854775806Z (i.e., almost the range of a 64-bit signed integer when expressed as nanoseconds from the epoch, but with a few nanoseconds removed at either end to allow for sentinel values).

• Line protocol supports special characters in string elements.
• Line protocol supports both literal backslashes and backslashes as an escape character.

To unescape a character within a backslash escape sequence, InfluxDB removes the last backslash and its following character and replaces them with the replacement character. If the backslash is followed by a character that the line protocol element doesn’t support, InfluxDB leaves the backslash and the following character in place, unchanged.

The imply the following for tag keys, , field keys, and :

• they cannot end with a backslash (\).
• they accept double quote (") and single quote () characters as part of the name, key, or value.

In string field values with two contiguous backslashes, the first backslash is interpreted as an escape character.

Given the following line protocol:

# Escaped = in tag value.
# Literal backslash at start of string field value.
# Escaped backslash at end of string field value.
airSensor,sensor_id=TLM\=0201 desc="\=My data==\\"
# Measurement name with literal backslashes.
# Escaped = in tag value.
# Escaped \ and escaped " in string field value.
air\\\\\Sensor,sensor_id=TLM\=0201 desc="\\\"==My data\==\\"

InfluxDB writes the following points:

Examples of special characters in line protocol

# Measurement name with spaces
my\ Measurement fieldKey="string value"
# Double quotes in a string field value
myMeasurement fieldKey="\"string\" within a string"
# Tag keys and values with spaces
myMeasurement,tag\ Key1=tag\ Value1,tag\ Key2=tag\ Value2 fieldKey=100
# Measurement name and tag key with quotes
joe'smeasurement,pat'sTag=tag1 fieldKey=100
# Emojis
myMeasurement,tagKey=🍭 fieldKey="Launch 🚀" 1556813561098000000

Comments

If a line contains # as the first non-whitespace character, line protocol interprets it as a comment and ignores all subsequent characters until the next newline \n.

Naming restrictions

InfluxDB reserves the underscore (_) namespace and certain words for system use.

• Measurement names, tag keys, and field keys cannot begin with an underscore (_).
• Tag keys and tag values cannot end with a backslash (\).
• Tag keys and field keys cannot be named .
• Tag keys cannot be named field.

To make your schema easier to query, avoid using Flux keywords and special characters in keys.

A point is uniquely identified by the measurement name, tag set, and timestamp. If you submit line protocol with the same measurement, tag set, and timestamp, but with a different field set, the field set becomes the union of the old field set and the new field set, where any conflicts favor the new field set.

See how InfluxDB .

Out of range values

Fields can contain numeric values, which have the potential for falling outside supported ranges. Integer and float values should be considered out of range if they can’t fit within a 64-bit value of the appropriate type. Out of range values may cause .

For detail about supported ranges, see the minimum and maximum values for data types.

Parse errors

When a line protocol decoder encounters an invalid line, tag, or field (e.g., with an out-of-range value), the decoder may choose to recover from the error by ignoring the offending value or it may fail the decoding. One common approach to handling syntax errors is for the decoder to recover by discarding data until the next newline character and then resume parsing.

See to InfluxDB.

Related

• InfluxDB schema design