Fluentd
Search…
1.0
Introduction
Overview
Installation
Configuration
Deployment
System Configuration
Logging
Signals
RPC
High Availability Config
Performance Tuning
Multi Process Workers
Failure Scenarios
Plugin Management
Trouble Shooting
Fluentd UI
Linux Capability
Command Line Option
Container Deployment
Monitoring Fluentd
Input Plugins
Output Plugins
Filter Plugins
Parser Plugins
Formatter Plugins
Buffer Plugins
Storage Plugins
Service Discovery Plugins
Metrics Plugins
How-to Guides
Language Bindings
Plugin Development
Plugin Helper API
Troubleshooting Guide
Powered By GitBook
Failure Scenarios
This article describes various Fluentd failure scenarios. We will assume that you have configured Fluentd for High Availability, so that each app node has its local forwarders and all logs are aggregated into multiple aggregators.

Apps Cannot Post Records to Forwarder

The application sometimes fails to post records to its local Fluentd instance when using logger libraries of various languages. Depending on the maturity of each logger library, some clever mechanisms have been implemented to prevent data loss.

1. Memory Buffering (available for Ruby, Java, Python, Perl)

If the destination Fluentd instance dies, certain logger implementations will use extra memory to hold the incoming logs. When Fluentd comes back alive, these loggers will automatically retry to send the buffered logs to Fluentd again. Once the maximum buffer memory size is reached, most current implementations will write the data onto the disk or throw away the logs.

2. Exponential Backoff (available for Ruby, Java)

When trying to resend logs to the local forwarder, some implementations will use exponential backoff to prevent excessive re-connect requests.

Forwarder or Aggregator Fluentd Goes Down

What happens when a Fluentd process dies for any reason? It depends on your buffer configuration.

buf_memory

If you are using buf_memory, the buffered data is completely lost. This is a tradeoff for higher performance. Lowering the flush_interval will reduce the probability of data loss, but will increase the number of transfers between forwarders and aggregators.

buf_file

If you are using buf_file, the buffered data is stored on the disk. After Fluentd recovers, it will try to send the buffered data to the destination again.
Please note that the data will be lost if the buffer file is broken due to I/O errors. The data will also be lost if the disk is full.

Storage Destination Goes Down

If the storage destination (e.g. Amazon S3, MongoDB, HDFS, etc.) goes down, Fluentd will keep trying to resend the buffered data. The retry logic depends on the plugin implementation.
If you're using buf_memory, the aggregators will stop accepting new logs once they reach their buffer limits. If you are using buf_file, the aggregators will continue accepting logs until they run out of disk space.
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.
Previous
Multi Process Workers
Next
Plugin Management
Last modified 4mo ago
Copy link
Contents
Apps Cannot Post Records to Forwarder
1. Memory Buffering (available for Ruby, Java, Python, Perl)
2. Exponential Backoff (available for Ruby, Java)
Forwarder or Aggregator Fluentd Goes Down
buf_memory
buf_file
Storage Destination Goes Down