InfluxDB Logs Sink
The Vector influxdb_logs
sink
sends logs to
InfluxDB.
Configuration
- v2
- v2 (adv)
- v1
- v1 (adv)
- vector.toml
- vector.yaml
- vector.json
[sinks.my_sink_id]# Generaltype = "influxdb_logs" # requiredinputs = ["my-source-or-transform-id", "prefix-*"] # requiredbucket = "vector-bucket" # requiredendpoint = "http://localhost:8086/" # requirednamespace = "service" # required# Authorg = "my-org" # requiredtoken = "${INFLUXDB_TOKEN}" # required# Encoding# Healthcheckhealthcheck.enabled = true # optional, default
- optionaltable
batch
Configures the sink batching behavior.
- commonoptionaluint
max_bytes
The maximum size of a batch, in bytes, before it is flushed.
- Default:
1049000
(bytes)
- Default:
- commonoptionaluint
timeout_secs
The maximum age of a batch before it is flushed. See Buffers & batches for more info.
- Default:
1
(seconds)
- Default:
- commonrequiredstring
bucket
The destination bucket for writes into InfluxDB 2.
- Syntax:
literal
- View examples
- Syntax:
- optionaltable
buffer
Configures the sink specific buffer behavior.
- commonoptionaluint
max_events
The maximum number of events allowed in the buffer. See Buffers & batches for more info.
- Only relevant when: type = "memory"
- Default:
500
(events)
- commonrequired*uint
max_size
The maximum size of the buffer on the disk. See Buffers & batches for more info.
- Only required when: type = "disk"
- View examples
- enumcommonoptionalstring
type
The buffer's type and storage mechanism.
- Syntax:
literal
- Default:
"memory"
- Enum, must be one of:
"memory"
"disk"
- View examples
- Syntax:
- enumoptionalstring
when_full
The behavior when the buffer becomes full.
- Syntax:
literal
- Default:
"block"
- Enum, must be one of:
"block"
"drop_newest"
- View examples
- Syntax:
- commonoptionalstring
consistency
Sets the write consistency for the point for InfluxDB 1.
- Syntax:
literal
- View examples
- Syntax:
- commonrequiredstring
database
Sets the target database for the write into InfluxDB 1.
- Syntax:
literal
- View examples
- Syntax:
- commonrequiredtable
encoding
Configures the encoding specific sink behavior.
- optional[string]
except_fields
Prevent the sink from encoding the specified labels.
- View examples
- optional[string]
only_fields
Prevent the sink from encoding the specified labels.
- View examples
- enumoptionalstring
timestamp_format
How to format event timestamps.
- Syntax:
literal
- Default:
"rfc3339"
- Enum, must be one of:
"rfc3339"
"unix"
- View examples
- Syntax:
- commonrequiredstring
endpoint
The endpoint to send data to.
- Syntax:
literal
- View examples
- Syntax:
- commonoptionaltable
healthcheck
Health check options for the sink. See Health checks for more info.
- commonoptionalbool
enabled
Enables/disables the healthcheck upon Vector boot.
- Default:
true
- View examples
- Default:
- commonrequiredstring
namespace
A prefix that will be added to all logs names.
- Syntax:
literal
- View examples
- Syntax:
- commonrequiredstring
org
Specifies the destination organization for writes into InfluxDB 2.
- Syntax:
literal
- View examples
- Syntax:
- commonoptionalstring
password
Sets the password for authentication if you’ve enabled authentication for the write into InfluxDB 1.
- Syntax:
literal
- View examples
- Syntax:
- optionaltable
request
Configures the sink request behavior.
- optionaltable
adaptive_concurrency
Configure the adaptive concurrency algorithms. These values have been tuned by optimizing simulated results. In general you should not need to adjust these.
- optionalfloat
decrease_ratio
The fraction of the current value to set the new concurrency limit when decreasing the limit. Valid values are greater than 0 and less than 1. Smaller values cause the algorithm to scale back rapidly when latency increases. Note that the new limit is rounded down after applying this ratio.
- Default:
0.9
- Default:
- optionalfloat
ewma_alpha
The adaptive concurrency algorithm uses an exponentially weighted moving average (EWMA) of past RTT measurements as a reference to compare with the current RTT. This value controls how heavily new measurements are weighted compared to older ones. Valid values are greater than 0 and less than 1. Smaller values cause this reference to adjust more slowly, which may be useful if a service has unusually high response variability.
- Default:
0.7
- Default:
- optionalfloat
rtt_threshold_ratio
When comparing the past RTT average to the current measurements, we ignore changes that are less than this ratio higher than the past RTT. Valid values are greater than or equal to 0. Larger values cause the algorithm to ignore larger increases in the RTT.
- Default:
0.05
- Default:
- commonoptionaluint
concurrency
The maximum number of in-flight requests allowed at any given time, or "adaptive" to allow Vector to automatically set the limit based on current network and service conditions.
- Default:
5
(requests)
- Default:
- commonoptionaluint
rate_limit_duration_secs
The time window, in seconds, used for the
rate_limit_num
option.- Default:
1
(seconds)
- Default:
- commonoptionaluint
rate_limit_num
The maximum number of requests allowed within the
rate_limit_duration_secs
time window.- Default:
5
- Default:
- optionaluint
retry_attempts
The maximum number of retries to make for failed requests. The default, for all intents and purposes, represents an infinite number of retries.
- Default:
18446744073709552000
- Default:
- optionaluint
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)
- Default:
- optionaluint
retry_max_duration_secs
The maximum amount of time, in seconds, to wait between retries.
- Default:
10
(seconds)
- Default:
- commonoptionaluint
timeout_secs
The maximum time a request can take before being aborted. It is highly recommended that you do not lower this value below the service's internal timeout, as this could create orphaned requests, pile on retries, and result in duplicate data downstream. See Buffers & batches for more info.
- Default:
60
(seconds)
- Default:
- commonoptionalstring
retention_policy_name
Sets the target retention policy for the write into InfluxDB 1.
- Syntax:
literal
- View examples
- Syntax:
- optional[string]
tags
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. See Mapping Log Fields for more info.
- View examples
- commonrequiredstring
token
Authentication token for InfluxDB 2.
- Syntax:
literal
- View examples
- Syntax:
- commonoptionalstring
username
Sets the username for authentication if you’ve enabled authentication for the write into InfluxDB 1.
- Syntax:
literal
- View examples
- Syntax:
Telemetry
This component provides the following metrics that can be retrieved through
the internal_metrics
source. See the
metrics section in the
monitoring page for more info.
- counter
events_in_total
The total number of events accepted by this component. This metric includes the following tags:
component_kind
- The Vector component kind.component_name
- The Vector component ID.component_type
- The Vector component type.instance
- The Vector instance identified by host and port.job
- The name of the job producing Vector metrics.
- counter
events_out_total
The total number of events emitted by this component. This metric includes the following tags:
component_kind
- The Vector component kind.component_name
- The Vector component ID.component_type
- The Vector component type.instance
- The Vector instance identified by host and port.job
- The name of the job producing Vector metrics.
How It Works
Buffers & batches
This component buffers & batches data as shown in the diagram above. You'll notice that Vector treats these concepts differently, instead of treating them as global concepts, Vector treats them as sink specific concepts. This isolates sinks, ensuring services disruptions are contained and delivery guarantees are honored.
Batches are flushed when 1 of 2 conditions are met:
- The batch age meets or exceeds the configured
timeout_secs
. - The batch size meets or exceeds the configured <% if component.options.batch.children.respond_to?(:max_size) %>
max_size
<% else %>max_events
<% end %>.
Buffers are controlled via the buffer.*
options.
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
.
Mapping Log Fields
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.
A Log Event
event contains an arbitrary set of fields (key/value pairs) that describe the event.
The following matrix outlines how Log Event fields are mapped into InfluxDB Line Protocol:
Field | Line Protocol |
---|---|
host | tag |
message | field |
source_type | tag |
timestamp | timestamp |
[custom-key] | field |
The default behavior can be overridden by a tags
configuration.
Mapping Example
The following event:
{"host": "my.host.com","message": "<13>Feb 13 20:07:26 74794bfb6795 root[8539]: i am foobar","timestamp": "2019-11-01T21:15:47+00:00","custom_field": "custom_value"}
Will be mapped to Influx's line protocol:
ns.vector,host=my.host.com,metric_type=logs custom_field="custom_value",message="<13>Feb 13 20:07:26 74794bfb6795 root[8539]: i am foobar" 1572642947000000000
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
Adaptive Request Concurrency (ARC)
Adaptive Requst Concurrency is a feature of Vector that does away with static rate limits and automatically optimizes HTTP concurrency limits based on downstream service responses. The underlying mechanism is a feedback loop inspired by TCP congestion control algorithms. Checkout the announcement blog post,
We highly recommend enabling this feature as it improves performance and reliability of Vector and the systems it communicates with.
To enable, set the request.concurrency
option to adaptive
:
[sinks.my-sink]request.concurrency = "adaptive"
Static rate limits
If Adaptive Request Concurrency is not for you, you can manually
set static rate limits with the request.rate_limit_duration_secs
,
request.rate_limit_num
, and request.concurrency
options:
[sinks.my-sink]request.rate_limit_duration_secs = 1request.rate_limit_num = 10request.concurrency = 10
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.
State
This component is stateless, meaning its behavior is consistent across each input.