# loki: Grafana Loki

Available in AxoSyslog version 4.4 and later.

The `loki()` destination sends your log data to [Grafana Loki](<https://grafana.com/docs/loki/>). Note that:

  * AxoSyslog sends data using **gRPC** , HTTP transport is currently not supported. Since currently the Loki deployment in the free Grafana Cloud doesn’t have gRPC enabled, you must use a self-deployed Grafana Loki instance.
  * The message format is the same as documented for the [Grafana Loki HTTP endpoint](<https://grafana.com/docs/loki/latest/reference/api/#push-log-entries-to-loki>).



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)](<https://cloud.google.com/docs/authentication/application-default-credentials>). This authentication method is only available for destinations.

#### service-account-key()

Available in AxoSyslog version 4.15 and later.

Use the specified service account key for ADC authentication. File path must be the absolute path. For example:
```
 
    auth(adc(service-account-key("absolute-path-to-key-file")))
    
```

### alts()

[Application Layer Transport Security (ALTS)](<https://grpc.io/docs/languages/cpp/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.
```
 
    destination d_loki {
        loki(
          port(12345)
          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 d_loki {
        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")
            )
          )
        );
      };
    
```

> 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. To disable `batch-lines()`, set it to `0`.

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() / max-connections()` 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](<https://grpc.github.io/grpc/core/group__grpc__arg__keys.html>). 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}"
      )
    
```

## hook-commands()

_Description:_ This option makes it possible to execute external programs when the relevant driver is initialized or torn down. The `hook-commands()` can be used with all source and destination drivers with the exception of the `usertty()` and `internal()` drivers.

Note The AxoSyslog application must be able to start and restart the external program, and have the necessary permissions to do so. For example, if your host is running AppArmor or SELinux, you might have to modify your AppArmor or SELinux configuration to enable AxoSyslog to execute external applications. 

### Using `hook-commands()` when AxoSyslog starts or stops

To execute an external program when AxoSyslog starts or stops, use the following options:

#### `startup()`

Type: | string  
---|---  
Default: | N/A  
  
_Description:_ Defines the external program that is executed as AxoSyslog starts.

#### `shutdown()`

Type: | string  
---|---  
Default: | N/A  
  
_Description:_ Defines the external program that is executed as AxoSyslog stops.

### Using the hook-commands() when AxoSyslog reloads

To execute an external program when the AxoSyslog configuration is initiated or torn down, for example, on startup/shutdown or during a AxoSyslog reload, use the following options:

#### `setup()`

Type: | string  
---|---  
Default: | N/A  
  
_Description:_ Defines an external program that is executed when the AxoSyslog configuration is initiated, for example, on startup or during a AxoSyslog reload.

#### `teardown()`

Type: | string  
---|---  
Default: | N/A  
  
_Description:_ Defines an external program that is executed when the AxoSyslog configuration is stopped or torn down, for example, on shutdown or during a AxoSyslog reload.

### Example: Using hook-commands() with a network source

In the following example, the `hook-commands()` is used with the `network()` driver and it opens an [iptables](<https://en.wikipedia.org/wiki/Iptables> "https://en.wikipedia.org/wiki/Iptables") port automatically as AxoSyslog is started/stopped.

The assumption in this example is that the `LOGCHAIN` chain is part of a larger ruleset that routes traffic to it. Whenever the AxoSyslog created rule is there, packets can flow, otherwise the port is closed.
```
 
    source {
        network(transport(udp)
        hook-commands(
              startup("iptables -I LOGCHAIN 1 -p udp --dport 514 -j ACCEPT")
              shutdown("iptables -D LOGCHAIN 1")
            )
         );
    };
    
```

## keep-alive()

Configures how AxoSyslog sends [gRPC keepalive pings](<https://grpc.io/docs/guides/keepalive/>).

### 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: |   
  
The labels applied to the message as they are sent to the destination. They must match the `[a-zA-Z_:][a-zA-Z0-9_:]*` regular expression, so labels can contain:

  * ASCII letters,
  * numbers, (but cannot begin with numbers)
  * underscores (`_`), and
  * colons (`:`).



Use the following format:
```
 
    labels(
        "name_of_the_label_in_the_output" => "field-of-the-message",
    )
    
```

For example:
```
 
        labels(
            "app" => "$PROGRAM",
            "host" => "$HOST",
        )
    
```

For details on using labels, see the [Grafana Loki documentation](<https://grafana.com/docs/loki/latest/get-started/labels/>).

## local-time-zone()

|   
---|---  
Type: | name of the timezone, or the timezone offset  
Default: | The local timezone.  
  
_Description:_ Sets the timezone used when expanding filename and tablename templates.

The timezone can be specified by using the name, for example, `time-zone("Europe/Budapest")`), or as the timezone offset in +/-HH:MM format, for example, `+01:00`). On Linux and UNIX platforms, the valid timezone names are listed under the `/usr/share/zoneinfo` directory.

## log-fifo-size()

|   
---|---  
Type: | number  
Default: | Use global setting.  
  
_Description:_ The number of messages that the output queue can store.

## on-error()

Type: | One of: `drop-message`, `drop-property`, `fallback-to-string`, `silently-drop-message`, `silently-drop-property`, `silently-fallback-to-string`  
---|---  
Default: | Use the global setting (which defaults to `drop-message`)  
  
_Description:_ Controls what happens when type-casting fails and AxoSyslog cannot convert some data to the specified type. By default, AxoSyslog drops the entire message and logs the error. Currently the `value-pairs()` option uses the settings of `on-error()`.

  * `drop-message`: Drop the entire message and log an error message to the `internal()` source. This is the default behavior of AxoSyslog.
  * `drop-property`: Omit the affected property (macro, template, or message-field) from the log message and log an error message to the `internal()` source.
  * `fallback-to-string`: Convert the property to string and log an error message to the `internal()` source.
  * `silently-drop-message`: Drop the entire message silently, without logging the error.
  * `silently-drop-property`: Omit the affected property (macro, template, or message-field) silently, without logging the error.
  * `silently-fallback-to-string`: Convert the property to string silently, without logging the error.



## persist-name()

|   
---|---  
Type: | string  
Default: | N/A  
  
_Description:_ If you receive the following error message during AxoSyslog startup, set the `persist-name()` option of the duplicate drivers:
```
 
    Error checking the uniqueness of the persist names, please override it with persist-name option. Shutting down.
    
```

This error happens if you use identical drivers in multiple sources, for example, if you configure two file sources to read from the same file. In this case, set the `persist-name()` of the drivers to a custom string, for example, `persist-name("example-persist-name1")`.

## response-action()

|   
---|---  
Type: | arrow list  
Default: | Depends on the driver  
  
Available in AxoSyslog version 4.11.0 and later.

_Description:_ Fine-tunes how AxoSyslog behaves in case of different gRPC results. You can assign specific actions to the different gRPC results, for example:
```
 
    response-action(
      not-found => disconnect
      unavailable => drop
    )
    
```

The following gRPC results are supported:

  * `aborted`
  * `already-exists`
  * `cancelled`
  * `data-loss`
  * `deadline-exceeded`
  * `failed-precondition`
  * `internal`
  * `invalid-argument`
  * `not-found`
  * `ok`
  * `out-of-range`
  * `permission-denied`
  * `resource-exhausted`
  * `unauthenticated`
  * `unavailable`
  * `unknown`
  * `unimplemented`



The following actions are available:

  * `disconnect`
  * `drop`
  * `retry`
  * `success`



## retries()

|   
---|---  
Type: | number (of attempts)  
Default: | 3  
  
_Description:_ If AxoSyslog cannot send a message, it will try again until the number of attempts reaches `retries()`.

If the number of attempts reaches `retries()`, AxoSyslog will wait for `time-reopen()` time, then tries sending the message again.

## send-time-zone()

|   
---|---  
Accepted values: | name of the timezone, or the timezone offset  
Default: | local timezone  
  
_Description:_ Specifies the time zone associated with the messages sent by `syslog-ng`, if not specified otherwise in the message or in the destination driver. For details, see [Timezones and daylight saving](../../docs/axosyslog-core/chapter-concepts/timezone-handling/index.md).

The timezone can be specified by using the name, for example, `time-zone("Europe/Budapest")`), or as the timezone offset in +/-HH:MM format, for example, `+01:00`). On Linux and UNIX platforms, the valid timezone names are listed under the `/usr/share/zoneinfo` directory.

## 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](../../docs/axosyslog-core/chapter-manipulating-messages/customizing-message-format/reference-macros/index.md). For details on template functions, see [Template functions of AxoSyslog](../../docs/axosyslog-core/chapter-manipulating-messages/customizing-message-format/reference-template-functions/index.md).

## 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")
    );
    
```

## template-escape()

|   
---|---  
Type: | yes or no  
Default: | no  
  
_Description:_ Turns on escaping for the `'`, `"`, and backspace characters in templated output files. This is useful for generating SQL statements and quoting string contents so that parts of the log message are not interpreted as commands to the SQL server.

> Note: Starting with AxoSyslog version 4.5, `template-escape(yes)` escapes the top-level template function in case of nested template functions.

## throttle()

|   
---|---  
Type: | number  
Default: | 0  
  
_Description:_ Sets the maximum number of messages sent to the destination per second. Use this output-rate-limiting functionality only when using disk-buffer as well to avoid the risk of losing messages. Specifying `0` or a lower value sets the output limit to unlimited.

## time-reopen()

|   
---|---  
Accepted values: | number [seconds]  
Default: | 60  
  
_Description:_ The time to wait in seconds before a dead connection is reestablished.

## 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.



## time-zone()

|   
---|---  
Type: | name of the timezone, or the timezone offset  
Default: | unspecified  
  
_Description:_ Convert timestamps to the timezone specified by this option. If this option is not set, then the original timezone information in the message is used. Converting the timezone changes the values of all date-related macros derived from the timestamp, for example, `HOUR`. For the complete list of such macros, see [Date-related macros](../../docs/axosyslog-core/chapter-manipulating-messages/customizing-message-format/date-macros/index.md).

The timezone can be specified by using the name, for example, `time-zone("Europe/Budapest")`), or as the timezone offset in +/-HH:MM format, for example, `+01:00`). On Linux and UNIX platforms, the valid timezone names are listed under the `/usr/share/zoneinfo` directory.

## url()

|   
---|---  
Type: | string  
Default: | `localhost:9095`  
  
_Description:_ The URL of the Loki endpoint, including the gRPC listen port of your Loki deployment.

## worker-partition-autoscaling()

|   
---|---  
Type: | `yes`, `no`  
Default: | `no`  
  
Available in version 4.21 and later.

When using `worker-partition-key()` to categorize messages into different batches, the messages are hashed into workers by default. This prevents distributing across workers based on load.

Setting `worker-partition-autoscaling(yes)` uses a 1-minute statistic to distribute high-traffic partitions among multiple workers, allowing each worker to maximize its batch size. When using `worker-partition-autoscaling(yes)`, set the number of `workers()` to higher than the expected number of partitions.

## worker-partition-buckets()

|   
---|---  
Type: | template  
Default: |   
  
_Description:_ The `worker-partition-buckets()` option determines the number of worker threads used for the `worker-partition-key()`. Note that the number set by `worker-partition-buckets()` should be lower than the number of `workers()`.

## worker-partition-key()

|   
---|---  
Type: | template  
Default: |   
  
_Description:_ The `worker-partition-key()` option specifies a template: messages that expand the template to the same value are mapped to the same partition. When batching is enabled and multiple workers are configured, it’s important to add only those messages to a batch which generate identical URLs. To achieve this, set the `worker-partition-key()` option with a template that contains all the templates used in the `url()` option, otherwise messages will be mixed.

For example, you can partition messages based on the destination host:
```
 
    worker-partition-key("$HOST")
    
```

## 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.

Warning `Hazard of data loss.` When you use more than one worker threads together with disk-based buffering, AxoSyslog creates a separate disk buffer for each worker thread. This means that decreasing the number of workers can result in losing data currently stored in the disk buffer files. Do not decrease the number of workers when the disk buffer files are in use. 

Last modified May 8, 2026: [Renames hook-commands snippet (473feff3)](<https://github.com/axoflow/axosyslog-core-docs/commit/473feff317cce35465fb8e527d1c4a7f46486b0a>)