Loki
Configuration Options
Required Options
endpoint(required)
The base URL of the Loki instance.
| Type | Syntax | Default | Example |
|---|---|---|---|
| string | literal | ["http://localhost:3100"] |
labels(required)
A set of labels that are attached to each batch of events. Both keys and values are templatable, which enables you to attach dynamic labels to events. Note: If the set of labels has high cardinality, this can cause drastic performance issues with Loki. To prevent this from happening, reduce the number of unique label keys and values.
| Type | Syntax | Default | Example |
|---|---|---|---|
| hash | template | [{"forwarder":"vector","event":"{{ event_field }}","key":"value","\"{{ event_field }}\"":"{{ another_event_field }}"}] |
inputs(required)
A list of upstream source or transform
IDs. Wildcards (*) are supported.
See configuration for more info.
| Type | Syntax | Default | Example |
|---|---|---|---|
| array | literal | ["my-source-or-transform-id","prefix-*"] |
encoding(required)
Configures the encoding specific sink behavior.
| Type | Syntax | Default | Example |
|---|---|---|---|
| hash | literal | [] |
type(required)
The component type. This is a required field for all components and tells Vector which component to use.
| Type | Syntax | Default | Example |
|---|---|---|---|
| string | literal | ["loki"] |
Advanced Options
auth(optional)
Configures the authentication strategy.
| Type | Syntax | Default | Example |
|---|---|---|---|
| hash | literal | [] |
out_of_order_action(optional)
Some sources may generate events with timestamps that aren't in strictly chronological order. The Loki service can't accept a stream of such events. Vector sorts events before sending them to Loki, however some late events might arrive after a batch has been sent. This option specifies what Vector should do with those events.
| Type | Syntax | Default | Example |
|---|---|---|---|
| string | literal | drop |
remove_label_fields(optional)
If this is set to true then when labels are collected from events those fields will also get removed from the event.
| Type | Syntax | Default | Example |
|---|---|---|---|
| bool |
remove_timestamp(optional)
If this is set to true then the timestamp will be removed from the event payload. Note the event timestamp will still be sent as metadata to Loki for indexing.
| Type | Syntax | Default | Example |
|---|---|---|---|
| bool |
buffer(optional)
Configures the sink specific buffer behavior.
| Type | Syntax | Default | Example |
|---|---|---|---|
| hash | literal | [] |
batch(optional)
Configures the sink batching behavior.
| Type | Syntax | Default | Example |
|---|---|---|---|
| hash | [] |
healthcheck(optional)
Health check options for the sink.
| Type | Syntax | Default | Example |
|---|---|---|---|
| hash | [] |
request(optional)
Configures the sink request behavior.
| Type | Syntax | Default | Example |
|---|---|---|---|
| hash | [] |
tls(optional)
Configures the TLS options for incoming connections.
| Type | Syntax | Default | Example |
|---|---|---|---|
| hash | literal | [] |
proxy(optional)
Configures an HTTP(S) proxy for Vector to use. By default, the globally configured proxy is used.
| Type | Syntax | Default | Example |
|---|---|---|---|
| hash | literal | [] |
tenant_id(optional)
The tenant id that's sent with every request, by default this is not required since a proxy should set this header. When running Loki locally a tenant id is not required either.
You can read more about tenant id's here.
| Type | Syntax | Default | Example |
|---|---|---|---|
| string | template | ["some_tenant_id","{{ event_field }}"] |
How it Works
Decentralized Deployments
Loki currently does not support out-of-order inserts. If Vector is deployed in a decentralized setup then there is the possibility that logs might get rejected due to data races between Vector instances. To avoid this we suggest either assigning each Vector instance with a unique label or deploying a centralized Vector which will ensure no logs will get sent out-of-order.
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
Transport Layer Security (TLS)
Buffers and 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
max_sizeormax_events.
Buffers are controlled via the buffer.* options.
Event Ordering
The loki sink will ensure that all logs are sorted via
their timestamp. This is to ensure that logs will be
accepted by Loki. If no timestamp is supplied with events
then the Loki sink will supply its own monotonically
increasing timestamp.
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.