InfluxDB Metrics

Example Configuration

Counter

Config
Input
Output
1[sinks.my_sink_id]
2type = "influxdb_metrics"
3default_namespace = "service"
1{
2 "metric": {
3 "kind": "incremental",
4 "name": "logins",
5 "counter": {
6 "value": 1.5
7 },
8 "tags": {
9 "host": "my-host.local"
10 }
11 }
12}
1"service.logins,metric_type=counter,host=my-host.local value=1.5 1542182950000000011"

Distribution

Config
Input
Output
1[sinks.my_sink_id]
2type = "influxdb_metrics"
1{
2 "metric": {
3 "kind": "incremental",
4 "name": "sparse_stats",
5 "namespace": "app",
6 "distribution": {
7 "samples": [
8 {
9 "value": 1,
10 "rate": 1
11 },
12 {
13 "value": 5,
14 "rate": 2
15 },
16 {
17 "value": 3,
18 "rate": 3
19 }
20 ],
21 "statistic": "histogram"
22 },
23 "tags": {
24 "host": "my-host.local"
25 }
26 }
27}
1"app.sparse_stats,metric_type=distribution,host=my-host.local avg=3.333333,count=6,max=5,median=3,min=1,quantile_0.95=5,sum=20 1542182950000000011"

Gauge

Config
Input
Output
1[sinks.my_sink_id]
2type = "influxdb_metrics"
3default_namespace = "service"
1{
2 "metric": {
3 "kind": "absolute",
4 "name": "memory_rss",
5 "namespace": "app",
6 "gauge": {
7 "value": 1.5
8 },
9 "tags": {
10 "host": "my-host.local"
11 }
12 }
13}
1"app.memory_rss,metric_type=gauge,host=my-host.local value=1.5 1542182950000000011"

Histogram

Config
Input
Output
1[sinks.my_sink_id]
2type = "influxdb_metrics"
1{
2 "metric": {
3 "kind": "absolute",
4 "name": "requests",
5 "histogram": {
6 "buckets": [
7 {
8 "upper_limit": 1,
9 "count": 2
10 },
11 {
12 "upper_limit": 2.1,
13 "count": 5
14 },
15 {
16 "upper_limit": 3,
17 "count": 10
18 }
19 ],
20 "count": 17,
21 "sum": 46.2
22 },
23 "tags": {
24 "host": "my-host.local"
25 }
26 }
27}
1"requests,metric_type=histogram,host=my-host.local bucket_1=2i,bucket_2.1=5i,bucket_3=10i,count=17i,sum=46.2 1542182950000000011"

Set

Config
Input
Output
1[sinks.my_sink_id]
2type = "influxdb_metrics"
1{
2 "metric": {
3 "kind": "incremental",
4 "name": "users",
5 "set": {
6 "values": [
7 "first",
8 "another",
9 "last"
10 ]
11 },
12 "tags": {
13 "host": "my-host.local"
14 }
15 }
16}
1"users,metric_type=set,host=my-host.local value=3 154218295000000001"

Summary

Config
Input
Output
1[sinks.my_sink_id]
2type = "influxdb_metrics"
1{
2 "metric": {
3 "kind": "absolute",
4 "name": "requests",
5 "summary": {
6 "quantiles": [
7 {
8 "upper_limit": 0.01,
9 "value": 1.5
10 },
11 {
12 "upper_limit": 0.5,
13 "value": 2
14 },
15 {
16 "upper_limit": 0.99,
17 "value": 3
18 }
19 ],
20 "count": 6,
21 "sum": 12.1
22 },
23 "tags": {
24 "host": "my-host.local"
25 }
26 }
27}
1"requests,metric_type=summary,host=my-host.local count=6i,quantile_0.01=1.5,quantile_0.5=2,quantile_0.99=3,sum=12.1 1542182950000000011"

Configuration Options

Required Options

bucket(required)

The destination bucket for writes into InfluxDB 2.

TypeSyntaxDefaultExample
stringliteral["vector-bucket","4d2225e4d3d49f75"]
database(required)

Sets the target database for the write into InfluxDB 1.

TypeSyntaxDefaultExample
stringliteral["vector-database","iot-store"]
endpoint(required)

The endpoint to send data to.

TypeSyntaxDefaultExample
stringliteral["http://localhost:8086/","https://us-west-2-1.aws.cloud1.influxdata.com","https://us-west-2-1.aws.cloud2.influxdata.com"]
org(required)

Specifies the destination organization for writes into InfluxDB 2.

TypeSyntaxDefaultExample
stringliteral["my-org","33f2cff0a28e5b63"]
token(required)

Authentication token for InfluxDB 2.

TypeSyntaxDefaultExample
stringliteral["${INFLUXDB_TOKEN}","ef8d5de700e7989468166c40fc8a0ccd"]
inputs(required)

A list of upstream source or transform IDs. Wildcards (*) are supported.

See configuration for more info.

TypeSyntaxDefaultExample
arrayliteral["my-source-or-transform-id","prefix-*"]
encoding(required)

Configures the encoding specific sink behavior.

TypeSyntaxDefaultExample
hashliteral[]
type(required)

The component type. This is a required field for all components and tells Vector which component to use.

TypeSyntaxDefaultExample
stringliteral["influxdb_metrics"]

Advanced Options

consistency(optional)

Sets the write consistency for the point for InfluxDB 1.

TypeSyntaxDefaultExample
stringliteral["any","one","quorum","all"]
password(optional)

Sets the password for authentication if you’ve enabled authentication for the write into InfluxDB 1.

TypeSyntaxDefaultExample
stringliteral["${INFLUXDB_PASSWORD}","influxdb4ever"]
retention_policy_name(optional)

Sets the target retention policy for the write into InfluxDB 1.

TypeSyntaxDefaultExample
stringliteral["autogen","one_day_only"]
tags(optional)

A set of additional fields that will be attached to each LineProtocol as a tag. Note: If the set of tag values has high cardinality this also increase cardinality in InfluxDB.

TypeSyntaxDefaultExample
arrayfield_path["field1","parent.child_field"]
default_namespace(optional)

Used as a namespace for metrics that don't have it. A namespace will be prefixed to a metric's name.

TypeSyntaxDefaultExample
stringliteral["service"]
batch(optional)

Configures the sink batching behavior.

TypeSyntaxDefaultExample
hash[]
healthcheck(optional)

Health check options for the sink.

TypeSyntaxDefaultExample
hash[]
request(optional)

Configures the sink request behavior.

TypeSyntaxDefaultExample
hash[]
username(optional)

Sets the username for authentication if you’ve enabled authentication for the write into InfluxDB 1.

TypeSyntaxDefaultExample
stringliteral["todd","vector-source"]

How it Works

State

This component is stateless, meaning its behavior is consistent across each input.

Health checks

Health checks ensure that the downstream service is accessible and ready to accept data. This check is performed upon sink initialization. If the health check fails an error will be logged and Vector will proceed to start.

Partitioning

Vector supports dynamic configuration values through a simple template syntax. If an option supports templating, it will be noted with a badge and you can use event fields to create dynamic values. For example:

[sinks.my-sink]
dynamic_option = "application={{ application_id }}"

In the above example, the application_id for each event will be used to partition outgoing data.

Rate limits & adapative concurrency

Retry policy

Vector will retry failed requests (status == 429, >= 500, and != 501). Other responses will not be retried. You can control the number of retry attempts and backoff rate with the request.retry_attempts and request.retry_backoff_secs options.