InfluxDB Metrics Sink

The Vector influxdb_metrics sink batches metric events to InfluxDB using v1 or v2 HTTP API.

Configuration

vector.toml
[sinks.my_sink_id]
# General
type = "influxdb_metrics" # required
inputs = ["my-source-id"] # required
bucket = "vector-bucket" # required
endpoint = "https://us-west-2-1.aws.cloud2.influxdata.com" # required
namespace = "service" # required
healthcheck = true # optional, default
# auth
org = "Organization" # required
token = "${INFLUXDB_TOKEN}" # required
13 items
v1v2tableoptional

batch

Configures the sink batching behavior.

v1v2int (events)commonoptional

max_events

The maximum size of a batch, in events, before it is flushed.

Default: 20 (events)
View examples
v1v2int (seconds)commonoptional

timeout_secs

The maximum age of a batch before it is flushed.

Default: 1 (seconds)
View examples
v1v2stringcommonrequired

endpoint

InfluxDB endpoint to send metrics to.

No default
View examples
v2stringcommonrequired

bucket

The destination bucket for writes into InfluxDB 2.

No default
View examples
v1stringcommonoptional

consistency

Sets the write consistency for the point for InfluxDB 1.

No default
View examples
v1stringcommonrequired

database

Sets the target database for the write into InfluxDB 1.

No default
View examples
v1v2boolcommonoptional

healthcheck

Enables/disables the sink healthcheck upon start.

See Health Checks for more info.

Default: true
View examples
v1v2stringcommonrequired

namespace

A prefix that will be added to all metric names.

No default
View examples
v2stringcommonrequired

org

Specifies the destination organization for writes into InfluxDB 2.

No default
View examples
v1stringcommonoptional

password

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

No default
View examples
v1v2tableoptional

request

Configures the sink request behavior.

v1v2int (requests)commonoptional

in_flight_limit

The maximum number of in-flight requests allowed at any given time.

See Rate Limits for more info.

Default: 5 (requests)
View examples
v1v2int (seconds)commonoptional

rate_limit_duration_secs

The time window, in seconds, used for the rate_limit_num option.

See Rate Limits for more info.

Default: 1 (seconds)
View examples
v1v2intcommonoptional

rate_limit_num

The maximum number of requests allowed within the rate_limit_duration_secs time window.

See Rate Limits for more info.

Default: 5
View examples
v1v2intoptional

retry_attempts

The maximum number of retries to make for failed requests.

See Retry Policy for more info.

Default: -1
View examples
v1v2int (seconds)optional

retry_initial_backoff_secs

The amount of time to wait before attempting the first retry for a failed request. Once, the first retry has failed the fibonacci sequence will be used to select future backoffs.

Default: 1 (seconds)
View examples
v1v2int (seconds)optional

retry_max_duration_secs

The maximum amount of time, in seconds, to wait between retries.

Default: 10 (seconds)
View examples
v1v2int (seconds)commonoptional

timeout_secs

The maximum time a request can take before being aborted. It is highly recommended that you do not lower value below the service's internal timeout, as this could create orphaned requests, pile on retries, and result in duplicate data downstream.

Default: 60 (seconds)
View examples
v1stringcommonoptional

retention_policy_name

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

No default
View examples
v2stringcommonrequired

token

Authentication token for InfluxDB 2.

No default
View examples
v1stringcommonoptional

username

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

No default
View examples

How It Works

Environment Variables

Environment variables are supported through all of Vector's configuration. Simply add ${MY_ENV_VAR} in your Vector configuration file and the variable will be replaced before being evaluated.

You can learn more in the Environment Variables section.

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.

Require Health Checks

If you'd like to exit immediately upon a health check failure, you can pass the --require-healthy flag:

vector --config /etc/vector/vector.toml --require-healthy

Disable Health Checks

If you'd like to disable health checks for this sink you can set the healthcheck option to false.

Metric Types

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.

The following matrix outlines how Vector metric types are mapped into InfluxDB Line Protocol fields.

Vector MetricsLine Protocol FieldsExample
Countervaluens.total,metric_type=counter value=1.5 1542182950000000011
Gaugevaluens.meter,metric_type=gauge,normal_tag=value,true_tag=true value=-1.5 1542182950000000011
Setvaluens.users,metric_type=set,normal_tag=value,true_tag=true value=2 154218295000000001
Histogrambuckets, count, sumns.requests,metric_type=histogram,normal_tag=value,true_tag=true bucket_1=1i,bucket_2.1=2i,bucket_3=3i,count=6i,sum=12.5 1542182950000000011
Summaryquantiles, count, sumns.requests_sum,metric_type=summary,normal_tag=value,true_tag=true count=6i,quantile_0.01=1.5,quantile_0.5=2,quantile_0.99=3,sum=12 1542182950000000011
Distributionmin, max, median, avg, sum, count, quantile 0.95ns.sparse_stats,metric_type=distribution avg=3,count=10,max=4,median=3,min=1,quantile_0.95=4,sum=30 1542182950000000011

Rate Limits

Vector offers a few levers to control the rate and volume of requests to the downstream service. Start with the rate_limit_duration_secs and rate_limit_num options to ensure Vector does not exceed the specified number of requests in the specified window. You can further control the pace at which this window is saturated with the in_flight_limit option, which will guarantee no more than the specified number of requests are in-flight at any given time.

Please note, Vector's defaults are carefully chosen and it should be rare that you need to adjust these. If you found a good reason to do so please share it with the Vector team by opening an issie.

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 retry_attempts and retry_backoff_secs options.