-
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 file spool to queue docs #6902
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,10 +6,12 @@ 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. | ||
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. Only one | ||
queue type can be configured. | ||
|
||
|
||
Example configuration: | ||
This sample configuration sets the memory queue to buffer up to 4096 events: | ||
|
||
[source,yaml] | ||
------------------------------------------------------------------------------ | ||
|
@@ -21,8 +23,7 @@ queue.mem: | |
[[configuration-internal-queue-memory]] | ||
=== Configure the memory queue | ||
|
||
The memory queue keeps all events in memory. It is the only queue type | ||
supported right now. | ||
The memory queue keeps all events in memory. | ||
|
||
If no flush interval and no number of events to flush is configured, | ||
all events published to this queue will be directly consumed by the outputs. | ||
|
@@ -33,11 +34,11 @@ By default `flush.min.events` is set to 2048 and `flush.timeout` is set to 1s. | |
The output's `bulk_max_size` setting limits the number of events being processed at once. | ||
|
||
The memory queue waits for the output to acknowledge or drop events. If | ||
the queue is full, no new events can be inserted into the memeory queue. Only | ||
the queue is full, no new events can be inserted into the memory queue. Only | ||
after the signal from the output will the queue free up space for more events to be accepted. | ||
|
||
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: | ||
available or the oldest available event has been waiting for 5s in the queue: | ||
|
||
[source,yaml] | ||
------------------------------------------------------------------------------ | ||
|
@@ -76,3 +77,160 @@ will be immediately available for consumption. | |
|
||
The default values is 0s. | ||
|
||
[float] | ||
[[configuration-internal-queue-spool]] | ||
=== Configure the file spool queue | ||
|
||
The file spool queue stores all events in an on disk ring buffer. The spool | ||
has a write buffer, which new events are written to. Events written to the | ||
spool are forwarded to the outputs, only after the write buffer has been | ||
flushed successfully. | ||
|
||
The spool waits for the output to acknowledge or drop events. If the spool is | ||
full, no new events can be inserted. The spool will block. Space is freed only | ||
after a signal from the output has been received. | ||
|
||
On disk, the spool divides a file into pages. The `file.page_size` setting | ||
configures the file's page size at file creation time. The optimal page size depends | ||
on the effective block size, used by the underlying file system. | ||
|
||
This sample configuration enables the spool with all default settings (See | ||
<<configuration-internal-queue-spool-reference>> for defaults) and the | ||
default file path: | ||
|
||
[source,yaml] | ||
------------------------------------------------------------------------------ | ||
queue.spool: ~ | ||
------------------------------------------------------------------------------ | ||
|
||
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. Might be worth pointing the user to the Configuration options section for the defaults. 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. Added a link to text before sample |
||
This sample configuration creates a spool of 512MiB, with 16KiB pages. The | ||
write buffer is flushed if 10MiB of contents, or 1024 events have been | ||
written. If the oldest available event has been waiting for 5s in the write | ||
buffer, the buffer will be flushed as well: | ||
|
||
[source,yaml] | ||
------------------------------------------------------------------------------ | ||
queue.spool: | ||
file: | ||
path: "${path.data}/spool.dat" | ||
size: 512MiB | ||
page_size: 16KiB | ||
write: | ||
buffer_size: 10MiB | ||
flush.timeout: 5s | ||
flush.events: 1024 | ||
------------------------------------------------------------------------------ | ||
|
||
[float] | ||
[[configuration-internal-queue-spool-reference]] | ||
==== Configuration options | ||
|
||
You can specify the following options in the `queue.spool` section of the | ||
+{beatname_lc}.yml+ config file: | ||
|
||
[float] | ||
===== `file.path` | ||
|
||
The spool file path. The file is created on startup, if it does not exist. | ||
|
||
The default value is "${path.data}/spool.dat". | ||
|
||
[float] | ||
===== `file.permissions` | ||
|
||
The file permissions. The permissions are applied when the file is | ||
created. In case the file already exists, the file permissions are compared | ||
with `file.permissions`. The spool file is not opened if the actual file | ||
permissions are more permissive then configured. | ||
|
||
The default value is 0600. | ||
|
||
|
||
[float] | ||
===== `file.size` | ||
|
||
Spool file size. | ||
|
||
The default value is 100 MiB. | ||
|
||
NOTE: The size should be much larger then the expected event sizes | ||
and write buffer size. Otherwise the queue will block, because it has not | ||
enough space. | ||
|
||
NOTE: The file size cannot be changed once the file has been generated. This | ||
limitation will be removed in the future. | ||
|
||
[float] | ||
===== `file.page_size` | ||
|
||
The file's page size. | ||
|
||
The spool file is split into pages of `page_size`. All I/O | ||
operations operate on complete pages. | ||
|
||
The default value is 4096 (4KiB). | ||
|
||
NOTE: This setting should match the file system's minimum block size. If the | ||
`page_size` is not a multiple of the file system's block size, the file system | ||
might create additional read operations on writes. | ||
|
||
NOTE: The page size is only set at file creation time. It cannot be changed | ||
afterwards. | ||
|
||
[float] | ||
===== `file.prealloc` | ||
|
||
If `prealloc` is set to `true`, truncate is used to reserve the space up to | ||
`file.size`. This setting is only used when the file is created. | ||
|
||
The file will dynamically grow, if `prealloc` is set to false. The spool | ||
blocks, if `prealloc` is `false` and the system is out of disk space. | ||
|
||
The default value is `true`. | ||
|
||
[float] | ||
===== `write.buffer_size` | ||
|
||
The write buffer size. The write buffer is flushed, once the buffer size is exceeded. | ||
|
||
Very big events are allowed to be bigger then the configured buffer size. But | ||
the write buffer will be flushed right after the event has been serialized. | ||
|
||
The default value is 1MiB. | ||
|
||
[float] | ||
===== `write.codec` | ||
|
||
The event encoding used for serialized events. Valid values are `json` and `cbor`. | ||
|
||
The default value is `cbor`. | ||
|
||
[float] | ||
===== `write.flush.timeout` | ||
|
||
Maximum wait time of the oldest event in the write buffer. If set to 0, the | ||
write buffer will only be flushed once `write.flush.events` or `write.buffer_size` is fulfilled. | ||
|
||
The default value is 1s. | ||
|
||
[float] | ||
===== `write.flush.events` | ||
|
||
Number of buffered events. The write buffer is flushed once the limit is reached. | ||
|
||
The default value is 16384. | ||
|
||
[float] | ||
===== `read.flush.timeout` | ||
|
||
The spool reader tries to read up to the output's `bulk_max_size` events at once. | ||
|
||
If `read.flush.timeout` is set to 0s, all available events are forwarded | ||
immediately to the output. | ||
|
||
If `read.flush.timeout` is set to a value bigger then 0s, the spool will wait | ||
for more events to be flushed. Events are forwarded to the output if | ||
`bulk_max_size` events have been read or the oldest read event has been waiting | ||
for the configured duration. | ||
|
||
The default value is 0s. |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Now that we have a couple of queue types, we should explain why users might choose to use a specific type of queue.
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.
Yeah. The interaction of a configured queue and the actual beat differs per beat. This would call for some beat specific documentation. As this will require some more work, I'd prefer to postpone the per-beats documentation for now.