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.
- Elements of line protocol
- Data types and format
- Quotes
- Special characters
- Comments
- Naming restrictions
- Duplicate points
- Out of range values
- Parse errors
Syntax
# Line protocol syntax
<measurement>[,<tag_key>=<tag_value>[,<tag_key>=<tag_value>]] <field_key>=<field_value>[,<field_key>=<field_value>] [<timestamp>]
Example
# Line protocol example
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:
- data point that represents a point in InfluxDB
- blank line that consists entirely of whitespace
- comment that starts with
#
optionally preceded by whitespace.
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.
measurementName,tagKey=tagValue fieldKey="fieldValue" 1465839830100400200
--------------- --------------- --------------------- -------------------
| | | |
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:
# 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 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.
measurementName fieldKey="string field value" 1556813561098000000
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
myMeasurementName fieldKey="fieldValue" 1556813561098000000
-------------------
|
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.
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.
Minimum integer | Maximum integer |
---|---|
-9223372036854775808i | 9223372036854775807i |
Integer field value examples
myMeasurement fieldKey=1i
myMeasurement fieldKey=12485903i
myMeasurement fieldKey=-12485903i
UInteger
Unsigned 64-bit integers. Trailing u
on the number specifies an unsigned integer.
Minimum uinteger | Maximum uinteger |
---|---|
0u | 18446744073709551615u |
UInteger field value examples
myMeasurement fieldKey=1u
myMeasurement fieldKey=12485903u
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 value | Accepted syntax |
---|---|
True | t , T , true , True , TRUE |
False | f , F , false , False , FALSE |
Boolean field value examples
myMeasurement fieldKey=true
myMeasurement fieldKey=false
myMeasurement fieldKey=t
myMeasurement fieldKey=f
myMeasurement fieldKey=TRUE
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 timestamp | Maximum timestamp |
---|---|
-9223372036854775806 | 9223372036854775806 |
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 sequence | Supported 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:
# 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:
_measurement | _sensor_id | _field | _value |
---|---|---|---|
airSensor | TLM=0201 | desc | \=My data==\ |
air\\\Sensor | TLM=0201 | desc | \”==My data\==\ |
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
.
# This is a comment
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.