Loki Sink

The Vector loki sink sends logs to Loki.

Configuration

[sinks.my_sink_id]
# General
type = "loki" # required
inputs = ["my-source-or-transform-id"] # required
healthcheck = true # optional, default
# Encoding
encoding.codec = "json" # required
# Labels
labels.forwarder = "vector" # example
labels.event = "{{ event_field }}" # example
labels.key = "value" # example
  • optionaltable

    auth

    Configures the authentication strategy.

    • commonrequiredstring

      password

      The basic authentication password.

      • View examples
    • enumcommonrequiredstring

      strategy

      The authentication strategy to use.

      • Enum, must be one of: "basic" "bearer"
      • View examples
    • commonrequiredstring

      token

      The token to use for bearer authentication

      • View examples
    • commonrequiredstring

      user

      The basic authentication user name.

      • View examples
  • optionaltable

    batch

    Configures the sink batching behavior.

    • commonoptionaluint

      max_events

      The maximum size of a batch, in events, before it is flushed. See Buffers & batches for more info.

      • Default: 100000 (events)
    • commonoptionaluint

      timeout_secs

      The maximum age of a batch before it is flushed. See Buffers & batches for more info.

      • Default: 1 (seconds)
  • 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.

      • Default: "memory"
      • Enum, must be one of: "memory" "disk"
      • View examples
    • enumoptionalstring

      when_full

      The behavior when the buffer becomes full.

      • Default: "block"
      • Enum, must be one of: "block" "drop_newest"
      • View examples
  • commonrequiredtable

    encoding

    Configures the encoding specific sink behavior.

    • commonrequiredstring

      codec

      The encoding codec used to serialize the events before outputting.

      • View examples
    • 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.

      • Default: "rfc3339"
      • Enum, must be one of: "rfc3339" "unix"
      • View examples
  • commonoptionalbool

    healthcheck

    Enables/disables the sink healthcheck upon Vector boot. See Health checks for more info.

    • Default: true
    • View examples
  • commonrequiredtable

    labels

    A set of labels that will be attached to each batch of events. These values are also templateable to allow events to provide dynamic label values.Note: If the set of label values has high cardinality this can cause drastic performance issues with Loki. To ensure this does not happen one should try to reduce the amount of unique label values.

    • templateableoptionalstring

      *

      Any Loki label

      • View examples
  • optionalbool

    remove_label_fields

    If this is set to true then when labels are collected from events those fields will also get removed from the event.

    • Default: false
    • View examples
  • optionalbool

    remove_timestamp

    If this is set to true then the timestamp will be removed from the event. This is useful because Loki uses the timestamp to index the event.

    • Default: true
    • View examples
  • 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
      • 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
      • 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
    • commonoptionaluint

      concurrency

      The maximum number of in-flight requests allowed at any given time, or "auto" to allow Vector to automatically set the limit based on current network and service conditions.

      • Default: 5 (requests)
    • commonoptionaluint

      rate_limit_duration_secs

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

      • Default: 1 (seconds)
    • commonoptionaluint

      rate_limit_num

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

      • Default: 5
    • 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
    • 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)
    • optionaluint

      retry_max_duration_secs

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

      • Default: 10 (seconds)
    • 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)
  • optionalstring

    tenant_id

    The tenant id that will be 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

    • View examples
  • optionaltable

    tls

    Configures the TLS options for incoming connections.

    • optionalstring

      ca_file

      Absolute path to an additional CA certificate file, in DER or PEM format (X.509), or an inline CA certificate in PEM format.

      • View examples
    • commonoptionalstring

      crt_file

      Absolute path to a certificate file used to identify this connection, in DER or PEM format (X.509) or PKCS#12, or an inline certificate in PEM format. If this is set and is not a PKCS#12 archive, key_file must also be set.

      • View examples
    • commonoptionalstring

      key_file

      Absolute path to a private key file used to identify this connection, in DER or PEM format (PKCS#8), or an inline private key in PEM format. If this is set, crt_file must also be set.

      • View examples
    • optionalstring

      key_pass

      Pass phrase used to unlock the encrypted key file. This has no effect unless key_file is set.

      • View examples
    • optionalbool

      verify_hostname

      If true (the default), Vector will validate the configured remote host name against the remote host's TLS certificate. Do NOT set this to false unless you understand the risks of not verifying the remote hostname.

      • Default: true
      • View examples

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

    processed_events_total

    The total number of events processed 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.

    • file - The file that produced the error

    • instance - The Vector instance identified by host and port.

    • job - The name of the job producing Vector metrics.

  • counter

    processed_bytes_total

    The total number of bytes processed by the 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:

  1. The batch age meets or exceeds the configured timeout_secs.
  2. 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.

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.

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.

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.

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:

vector.toml
[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:

vector.toml
[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:

vector.toml
[sinks.my-sink]
request.rate_limit_duration_secs = 1
request.rate_limit_num = 10
request.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.

Transport Layer Security (TLS)

Vector uses Openssl for TLS protocols for it's maturity. You can enable and adjust TLS behavior via the tls.* options.