You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/sources/reference/components/loki/loki.write.md
+9-7Lines changed: 9 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -46,7 +46,7 @@ You can use the following blocks with `loki.write`:
46
46
|`endpoint` > [`basic_auth`][basic_auth]| Configure `basic_auth` for authenticating to the endpoint. | no |
47
47
|`endpoint` > [`oauth2`][oauth2]| Configure OAuth 2.0 for authenticating to the endpoint. | no |
48
48
|`endpoint` > `oauth2` > [`tls_config`][tls_config]| Configure TLS settings for connecting to the endpoint. | no |
49
-
|`endpoint` > [`queue_config`][queue_config]|When WAL is enabled, configures the queue client.| no |
49
+
|`endpoint` > [`queue_config`][queue_config]|Configure the queue used for endpoint. | no |
50
50
|`endpoint` > [`tls_config`][tls_config]| Configure TLS settings for connecting to the endpoint. | no |
51
51
|[`wal`][wal]| Write-ahead log configuration. | no |
52
52
@@ -104,8 +104,9 @@ The following arguments are supported:
104
104
If no `tenant_id` is provided, the component assumes that the Loki instance at `endpoint` is running in single-tenant mode and no X-Scope-OrgID header is sent.
105
105
106
106
When multiple `endpoint` blocks are provided, the `loki.write` component creates a client for each.
107
-
Received log entries are fanned-out to these clients in succession.
108
-
That means that if one client is bottlenecked, it may impact the rest.
107
+
Received log entries are fanned-out to these endpoints in succession. That means that if one endpint is bottlenecked, it may impact the rest.
108
+
109
+
Each endpoint has a _queue_ of batches to be sent. The `queue_config` block can be used to customize the behavior of this queue.
109
110
110
111
Endpoints can be named for easier identification in debug metrics by using the `name` argument. If the `name` argument isn't provided, a name is generated based on a hash of the endpoint settings.
111
112
@@ -127,17 +128,18 @@ When `retry_on_http_429` is enabled, the retry mechanism is governed by the back
|`capacity`|`string`| Controls the size of the underlying send queue buffer. This setting should be considered a worst-case scenario of memory consumption, in which all enqueued batches are full. |`10MiB`| no |
140
138
|`drain_timeout`|`duration`| Configures the maximum time the client can take to drain the send queue upon shutdown. During that time, it enqueues pending batches and drains the send queue sending each. |`"1m"`| no |
139
+
|`min_shards`|`number`| Minimum amount of concurrent shards sending samples to the endpoint. |`1`| no |
140
+
141
+
Each endpoint manages a number of concurrent _shards_ which is responsible for sending a fraction of batches, number of shards are controlled with `min_shards` argument.
142
+
Each shard has a queue of batches it keeps in memory, controlled with the `capacity` argument.
0 commit comments