loki: Grafana Loki

Available in AxoSyslog version 4.4 and later.

The loki() destination sends your log data to Grafana Loki. Note that:

  • AxoSyslog sends data using gRPC, HTTP transport is currently not supported.
  • The message format is the same as documented for the Grafana Loki HTTP endpoint.

Sample configuration:

loki(
    url("localhost:9096")
    labels(
        "app" => "$PROGRAM",
        "host" => "$HOST",
    )

    workers(16)
    batch-timeout(10000)
    batch-lines(1000)
);

Options

The loki() destination has the following options.

auth()

You can set authentication in the auth() option of the driver. By default, authentication is disabled (auth(insecure())).

The following authentication methods are available in the auth() block:

adc()

Application Default Credentials (ADC). This authentication method is only available for destinations.

alts()

Application Layer Transport Security (ALTS) is a simple to use authentication, only available within Google’s infrastructure. It accepts the target-service-account() option, where you can list service accounts to match against when authenticating the server.

source {
    opentelemetry(
      port(4317)
      auth(alts())
    );
  };
destination {
    loki(
      port(12345)
      auth(alts())
    );
  };
source {
    syslog-ng-otlp(
      port(4317)
      auth(alts())
    );
  };

insecure()

This is the default method, authentication is disabled (auth(insecure())).

tls()

tls() accepts the key-file(), cert-file(), ca-file() and peer-verify() (possible values: required-trusted, required-untrusted, optional-trusted and optional-untrusted) options.

destination {
    opentelemetry(
      url("your-otel-server:12346")
      auth(
        tls(
          ca-file("/path/to/ca.pem")
          key-file("/path/to/key.pem")
          cert-file("/path/to/cert.pem")
        )
      )
    );
  };
destination {
    loki(
      url("your-loki-server:12346")
      auth(
        tls(
          ca-file("/path/to/ca.pem")
          key-file("/path/to/key.pem")
          cert-file("/path/to/cert.pem")
        )
      )
    );
  };
destination {
    syslog-ng-otlp(
      url("your-otel-server:12346")
      auth(
        tls(
          ca-file("/path/to/ca.pem")
          key-file("/path/to/key.pem")
          cert-file("/path/to/cert.pem")
        )
      )
    );
  };

Note:

  • tls(peer-verify()) is not available for the opentelemetry() and loki() destination.
  • The gRPC-based drivers (opentelemetry() and loki()) have a different tls() block implementation from the network() or http() drivers. Most features are the same.

batch-bytes()

Accepted values: number [bytes]
Default: none

Description: Sets the maximum size of payload in a batch. If the size of the messages reaches this value, AxoSyslog sends the batch to the destination even if the number of messages is less than the value of the batch-lines() option.

Note that if the batch-timeout() option is enabled and the queue becomes empty, AxoSyslog flushes the messages only if batch-timeout() expires, or the batch reaches the limit set in batch-bytes().

Available in AxoSyslog version 3.19 and later.

batch-lines()

Type: number
Default: 0

Description: Specifies how many lines are flushed to a destination in one batch. The AxoSyslog application waits for this number of lines to accumulate and sends them off in a single batch. Increasing this number increases throughput as more messages are sent in a single batch, but also increases message latency.

For example, if you set batch-lines() to 100, AxoSyslog waits for 100 messages.

If the batch-timeout() option is disabled, the AxoSyslog application flushes the messages if it has sent batch-lines() number of messages, or the queue became empty. If you stop or reload AxoSyslog or in case of network sources, the connection with the client is closed, AxoSyslog automatically sends the unsent messages to the destination.

Note that if the batch-timeout() option is enabled and the queue becomes empty, AxoSyslog flushes the messages only if batch-timeout() expires, or the batch reaches the limit set in batch-lines().

For optimal performance, make sure that the AxoSyslog source that feeds messages to this destination is configured properly: the value of the log-iw-size() option of the source must be higher than the batch-lines()*workers() of the destination. Otherwise, the size of the batches cannot reach the batch-lines() limit.

batch-timeout()

Type: time in milliseconds
Default: -1 (disabled)

Description: Specifies the time AxoSyslog waits for lines to accumulate in the output buffer. The AxoSyslog application sends batches to the destinations evenly. The timer starts when the first message arrives to the buffer, so if only few messages arrive, AxoSyslog sends messages to the destination at most once every batch-timeout() milliseconds.

channel-args()

Type: arrow list
Default: -

Description: The channel-args() option is available in gRPC-based drivers. It accepts name-value pairs and sets channel arguments defined in the GRPC Core library documentation. For example:

channel-args(
    "grpc.loadreporting" => 1
    "grpc.minimal_stack" => 0
)

compression()

Type: boolean
Default: no

Available in AxoSyslog version 4.5.0 and later.

Description: Enables compression in gRPC requests. Although gRPC supports various compression methods, currently only deflate is supported (which is basically the same as gzip).

headers()

Type: arrow list
Default: empty

Available in AxoSyslog 4.8 and later.

Description: Adds custom gRPC headers to each RPC call. Version 4.8 supported only static header names and values. For example:

headers(
    "organization" => "Axoflow"
    "stream-name" => "axo-stream"
  )

Starting with version 4.9, you can use templates and macros in the header values.

headers(
    "organization" => "Axoflow"
    "stream-name" => "${HOST}"
  )

keep-alive()

Configures how AxoSyslog sends gRPC keepalive pings.

max-pings-without-data()

Type: integer
Default:

Description: The maximum number of gRPC pings that can be sent when there is no data/header frame to be sent. AxoSyslog won’t send any pings after this limit. Set it to 0 disable this restriction and keep sending pings.

time()

Type: number [milliseconds]
Default:

Description: The period (in milliseconds) after which AxoSyslog sends a gRPC keepalive ping.

timeout()

Type: number [milliseconds]
Default: 10

Description: The time (in milliseconds) AxoSyslog waits for an acknowledgement.

labels()

Type: arrow list
Default: See the description

The labels applied to the message as they are sent to the destination. Use the following format:

labels(
    "name-of-the-label-in-the-output" => "field-of-the-message"
)

Default value:

template()

Type: template or template-function
Default: $ISODATE $HOST $MSGHDR$MSG

Description: Specifies a template defining the logformat to be used in the destination. Macros are described in Macros of AxoSyslog. For details on template functions, see Template functions of AxoSyslog.

tenant-id()

Type: string
Default: -

Description: Available in version 4.7 and newer. Sets the tenant ID for multi-tenant scenarios. For example:

loki(
    url("localhost:9096")
    labels(
        "app" => "$PROGRAM",
        "host" => "$HOST",
    )

    tenant-id("testTenant")
);

timestamp()

Type: current, received, or msg
Default: current

Description: Sets the timestamp to use for the messages sent to Loki. This is important because Loki accepts data only if their timestamp is monotonously increasing, out of order messages are rejected. The possible values for this option are:

  • current: Use the timestamp when AxoSyslog processes the message in the output. This guarantees that the timestamp is monotonously increasing, but in some cases can significantly differ from the time when the message was generated.
  • msg: Use the original timestamp of the message.
  • received: Use the timestamp when AxoSyslog has received the message.

url()

Type: string
Default: localhost:9095

Description: The URL of the Loki endpoint, including the gRPC listen port of your Loki deployment.

workers()

Type: integer
Default: 1

Description: Specifies the number of worker threads (at least 1) that AxoSyslog uses to send messages to the server. Increasing the number of worker threads can drastically improve the performance of the destination.