Line protocol

InfluxDB uses line protocol to write data points. It is a text-based format that provides the measurement, tag set, field set, and timestamp of a data point.

Syntax

  1. # Line protocol syntax
  2. <measurement>[,<tag_key>=<tag_value>[,<tag_key>=<tag_value>]] <field_key>=<field_value>[,<field_key>=<field_value>] [<timestamp>]

Example

  1. # Line protocol example
  2. myMeasurement,tag1=value1,tag2=value2 fieldKey="fieldValue" 1556813561098000000

Lines

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

Line protocol is whitespace-sensitive. Line protocol string elements may support certain special characters.

Elements of line protocol

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

  1. measurementName,tagKey=tagValue fieldKey="fieldValue" 1465839830100400200
  2. --------------- --------------- --------------------- -------------------
  3. | | | |
  4. Measurement Tag set Field set Timestamp

Measurement

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

*Data type: String*

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 naming restrictions.

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

Canonical form

Canonical form describes a tag set 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:

  1. # The tag set below is in canonical form.
  2. 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 naming restrictions.

*Key data type: String
**
Value data type:* Float | Integer | UInteger | String | Boolean

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

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

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

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: Unix timestamp*

Example

  1. myMeasurementName fieldKey="fieldValue" 1556813561098000000
  2. -------------------
  3. |
  4. Timestamp

Whitespace

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 measurement and the tag set from the field set. The second unescaped space delimits the field set from the timestamp.

  1. measurementName,tagKey=tagValue fieldKey="fieldValue" 1465839830100400200
  2. | |
  3. 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

  1. myMeasurement fieldKey=1.0
  2. myMeasurement fieldKey=1

InfluxDB supports scientific notation in float field values.

  1. myMeasurement fieldKey=-1.234456e+78

Integer

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

Minimum integerMaximum integer
-9223372036854775808i9223372036854775807i

Integer field value examples

  1. myMeasurement fieldKey=1i
  2. myMeasurement fieldKey=12485903i
  3. myMeasurement fieldKey=-12485903i

UInteger

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

Minimum uintegerMaximum uinteger
0u18446744073709551615u

UInteger field value examples

  1. myMeasurement fieldKey=1u
  2. myMeasurement fieldKey=12485903u

String

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

String example

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

Boolean

Stores true or false values.

Boolean valueAccepted syntax
Truet, T, true, True, TRUE
Falsef, F, false, False, FALSE

Boolean field value examples

  1. myMeasurement fieldKey=true
  2. myMeasurement fieldKey=false
  3. myMeasurement fieldKey=t
  4. myMeasurement fieldKey=f
  5. myMeasurement fieldKey=TRUE
  6. myMeasurement fieldKey=FALSE

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

Unix timestamp

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).

Minimum timestampMaximum timestamp
-92233720368547758069223372036854775806

Special characters

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

The following contexts require escaping certain characters with a backslash (\):

Escaping rules

Escape sequenceSupported in elements
\n is replaced with U+000A (newline)string field values
\r is replaced with U+000D (carriage-return)string field values
\t is replaced with U+0009 (tab)string field values
\ is replaced with U+0020 (space)all except string field values
\, is replaced with ,all except string field values
\= is replaced with =all except string field values and measurements
\” is replaced with string field values
\ is replaced with \string field values

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 escaping rules imply the following for tag keys, tag values, field keys, and measurements:

  • 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:

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

InfluxDB writes the following points:

_measurement_sensor_id_field_value
airSensorTLM=0201desc\=My data==\
air\\\SensorTLM=0201desc\”==My data\==\

Examples of special characters in line protocol

  1. # Measurement name with spaces
  2. my\ Measurement fieldKey="string value"
  3. # Double quotes in a string field value
  4. myMeasurement fieldKey="\"string\" within a string"
  5. # Tag keys and values with spaces
  6. myMeasurement,tag\ Key1=tag\ Value1,tag\ Key2=tag\ Value2 fieldKey=100
  7. # Measurement name and tag key with quotes
  8. joe'smeasurement,pat'sTag=tag1 fieldKey=100
  9. # Emojis
  10. 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.

  1. # This is a comment
  2. myMeasurement fieldKey="string value" 1556813561098000000

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 time.
  • Tag keys cannot be named field.

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

Duplicate points

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 handles duplicate points.

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 parsing errors.

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 how to troubleshoot issues writing data to InfluxDB.

write line protocol syntax