Fluentd
Search…
1.0
Buffer Plugins
Fluentd has nine (9) types of plugins:
This article gives an overview of Buffer Plugin.
Overview
Buffer plugins are used by output plugins. For example,
out_s3 uses buf_file by default to store incoming stream temporally before transmitting to S3.Buffer plugins are, as you can tell by the name, pluggable. So you can choose a suitable backend based on your system requirements.
How Buffer Works
A buffer is essentially a set of "chunks". A chunk is a collection of events concatenated into a single blob. Each chunk is managed one by one in the form of files (
buf_file) or continuous memory blocks (buf_memory).The Lifecycle of Chunks
You can think of a chunk as a cargo box. A buffer plugin uses a chunk as a lightweight container, and fills it with events incoming from input sources. If a chunk becomes full, then it gets "shipped" to the destination.
Internally, a buffer plugin has two separated places to store its chunks: "stage" where chunks get filled with events, and "queue" where chunks wait before the transportation. Every newly-created chunk starts from stage, then proceeds to queue in time (and subsequently gets transferred to the destination).
Fluentd-v0.14 Plugin API Overview
Control Retry Behavior
A chunk can fail to be written out to the destination for a number of reasons. The network can go down, or the traffic volumes can exceed the capacity of the destination node. To handle such common failures gracefully, buffer plugins are equipped with a built-in retry mechanism.
How Exponential Backoff Works
By default, Fluentd increases the wait interval exponentially for each retry attempt. For example, assuming that the initial wait interval is set to 1 second and the exponential factor is 2, each attempt occurs at the following time points:
1
0 1 3 7 15
2
x-x---x-------x---------------x-------------------------
3
│ │ │ │ └─ 4th retry (wait = 8s)
4
│ │ │ └───────────────── 3th retry (wait = 4s)
5
│ │ └───────────────────────── 2th retry (wait = 2s)
6
│ └───────────────────────────── 1th retry (wait = 1s)
7
└─────────────────────────────── FAIL
Copied!
Note that, in practice, Fluentd tweaks this algorithm in a few aspects:
- Wait intervals are randomized by default. That is, Fluentddiversifies the wait interval by multiplying by a randomly-chosennumber between 0.875 and 1.125. You can turn off this behavior bysetting
retry_randomizetofalse. - Wait intervals can be capped to a certain limit. For example,if you set
retry_max_intervalto 5 seconds in the example above,the 4th retry will wait for 5 seconds, instead of 8 seconds.
If you want to disable the exponential backoff, set the
retry_type option to periodic.Handling Successive Failures
Fluentd will abort the attempt to transfer the failing chunks on the following conditions:
- 1.The number of retries exceeds
retry_max_times(default:none) - 2.The seconds elapsed since the first retry exceeds
retry_timeout(default:72h)
In these events, all chunks in the queue are discarded. If you want to avoid this, you can enable
retry_forever to make Fluentd retry indefinitely.Handling Unrecoverable Errors
Not all errors are recoverable in nature. For example, if the content of a chunk file gets corrupted, you obviously cannot fix anything just by redoing the write operation. Rather, a blind retry attempt will just make the situation worse.
Since v1.2.0, Fluentd can detect these non-recoverable failures. If these kinds of fatal errors occur, Fluentd will abort the chunk immediately and move it into
secondary or the backup directory. The exact location of the backup directory is determined by the parameter root_dir in <system>:1
${root_dir}/backup/worker${worker_id}/${plugin_id}/{chunk_id}.log
Copied!
If you do not need to back up chunks, you can enable
disable_chunk_backup (available since v1.2.6) in the <buffer> section.The following is the current list of exceptions considered unrecoverable:
Exception
The typical cause of this error
Fluent::UnrecoverableErrorOutput plugin can use this exception to suppress further retry attempts for plugin-specific unrecoverable error.
TypeErrorOccurs when an event has an unexpected type in its target field.
ArgumentErrorOccurs when the plugin uses the library wrongly.
NoMethodErrorOccurs when events and configuration are mismatched.
Here are the patterns when an unrecoverable error happens:
- If the plugin does not have a
secondary, the chunk is moved to the backupdirectory. - If the plugin has a
secondarywhich is of different type from primary,the chunk is moved tosecondary. - If the unrecoverable error happens inside
secondary, the chunk ismoved to the backup directory.
Configuration Example
Following is a complete configuration that covers all the parameters controlling the retry behaviors:
1
<system>
2
root_dir /var/log/fluentd # For handling unrecoverable chunks
3
</system>
4
​
5
<buffer>
6
retry_wait 1 # The wait interval for the first retry.
7
retry_exponential_backoff_base 2 # Increase the wait time by a factor of N.
8
retry_type exponential_backoff # Set 'periodic' for constant intervals.
9
​
10
# retry_max_interval 1h # Cap the wait interval. (see above)
11
retry_randomize true # Apply randomization. (see above)
12
retry_timeout 72h # Maximum duration before giving up.
13
​
14
# retry_max_times 17 # Maximum retry count before giving up.
15
retry_forever false # Set 'true' for infinite retry loops.
16
retry_secondary_threshold 0.8 # See the "Secondary Output" section in
17
</buffer> # 'Output Plugins' > 'Overview'.
Copied!
Normally, you do not need to specify every option as in this example, because these options are, in fact, optional. As for the detail of each option, please read this article.
Parameters
FAQ
Buffer's chunk size and output's payload size are sometimes different, why?
Because the format of buffer chunk is different from output's payload. Let's use elasticsearch output plugin,
out_elasticsearch, for the detailed explanation.out_elasticsearch uses MessagePack for buffer's serialization (NOTE that this depends on the plugin). On the other hand, Elasticsearch's Bulk API requires JSON-based payload. It means that one MessagePack-ed record is converted into 2 JSON lines. So, the payload size is larger than the buffer's chunk size.This sometimes causes a problem when the output destination has a payload size limitation. If you have a problem with the payload size issue, check chunk size configuration, and API spec.
List of Buffer Plugins
If this article is incorrect or outdated, or omits critical information, please let us know. Fluentd is an open-source project under Cloud Native Computing Foundation (CNCF). All components are available under the Apache 2 License.
Last modified 2mo ago
Copy link