-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add queue settings to docs #4884
Changes from 5 commits
677a952
387376a
92c457f
756ca3f
6128f32
9662217
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,74 @@ | ||
[[configuring-internal-queue]] | ||
== Configure the internal queue | ||
|
||
{beatname_uc} uses an internal queue to store events before publishing them. The | ||
queue is responsible for buffering and combining events into batches that can | ||
be consumed by the outputs. The outputs will use bulk operations to send a | ||
batch of events in one transaction. | ||
|
||
You can configure the type and behavior of the internal queue by setting options in the `queue` section of the +{beatname_lc}.yml+ config file. | ||
|
||
|
||
Example configuration: | ||
|
||
[source,yaml] | ||
------------------------------------------------------------------------------ | ||
queue.mem: | ||
events: 4096 | ||
------------------------------------------------------------------------------ | ||
|
||
[float] | ||
[[configuration-internal-queue-memory]] | ||
=== Configure the memory qeueue | ||
|
||
The memory queue keeps all events in memory. It is the only queue type | ||
supported right now. By default no flush interval is configured. All events | ||
published to this queue will be directly consumed by the outputs. | ||
The output's `bulk_max_size` setting limits the number of events being processed at once. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this works! |
||
|
||
The memory queue is waiting for the output to acknowledge or drop an events. If | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This sentence has a typo "an events". The verb tense also seems a little off. Should probably say: The memory queue waits for the output to acknowledge or drop events. |
||
the queue is full, no new events can be inserted into the memeory queue. Only | ||
after the signal from the output will the queue free up space for more events to be accepted. | ||
|
||
To enforce spooling in the queue, set the `flush.min_events` and `flush.timeout` options. | ||
|
||
This sample configuration forwards events to the output if 512 events are | ||
available or the oldest available event is already waiting for 5s in the queue: | ||
|
||
[source,yaml] | ||
------------------------------------------------------------------------------ | ||
queue.mem: | ||
events: 4096 | ||
flush.min_events: 512 | ||
flush.timeout: 5s | ||
------------------------------------------------------------------------------ | ||
|
||
[float] | ||
==== Configuration options | ||
|
||
You can specify the following options in the `queue.mem` section of the +{beatname_lc}.yml+ config file: | ||
|
||
[float] | ||
===== `events` | ||
|
||
Number of events the queue can store. | ||
|
||
The default value is 4096 events. | ||
|
||
[float] | ||
===== `flush.min_events` | ||
|
||
Minimum number of events required for publishing. If this value is set to 0, the | ||
output can start publishing events without additional waiting times. Otherwise | ||
the output has to wait for more events to become available. | ||
|
||
The default value is 0. | ||
|
||
[float] | ||
===== `flush.timeout` | ||
|
||
Maximum wait time for `flush.min_events` to be fulfilled. If set to 0s, events | ||
will be immediately available for consumption. | ||
|
||
The default values is 0s. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd add a [float] tag here to keep the info about the memory queue from becoming a separate topic. If you don't use the [float] tag, you get this:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. Change did require me to add
[float]
about everywhere for the doc build not to fail.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yah, I really dislike [float] tags. We use them all over the library. They seem like such a hack, but are impossible to avoid without re-architecting all the content...and even so, you would still end up having to use them in some places.