How does Filebeat ensure at-least-once delivery? editįilebeat guarantees that events will be delivered to the configured output at See Registry file is too large for details about configuration options that you can set to resolve this issue.

If your use case involves creating a large number of new files every day, you might find that the registry file grows to be too large. For each file, Filebeat stores unique identifiers to detect whether a file was harvested previously.

Because files can be renamed or moved, the filename and path are not enough to identify a file. When Filebeat is restarted, data from the registry file is used to rebuild the state, and Filebeat continues each harvester at the last known position.įor each input, Filebeat keeps a state of each file it finds. While Filebeat is running, the state information is also kept in memory for each input. If the output, such as Elasticsearch or Logstash, is not reachable, Filebeat keeps track of the last lines sent and will continue reading the files as soon as the output becomes available again. The state is used to remember the last offset a harvester was reading from and to ensure all log lines are sent. How does Filebeat keep the state of files? editįilebeat keeps the state of each file and frequently flushes the state to disk in the registry file. New lines are only picked up if the size of the file has changed since the harvester was closed. The log input checks each file to see whether a harvester needs to be started, whether one is already running, or whether the file can be ignored (see ignore_older). Each input type can be defined multiple times. By default, Filebeat keeps the file open until close_inactive is reached.Ĭlosing a harvester has the following consequences:įilebeat currently supports several input types. This has the side effect that the space on your disk is reserved until the harvester closes. If a file is removed or renamed while it’s being harvested, Filebeat continues to read the file. The harvester is responsible for opening and closing the file, which means that the file descriptor remains open while the harvester is running. The harvester reads each file, line by line, and sends the content to the output. What is a harvester? editĪ harvester is responsible for reading the content of a single file. These components work together to tail files and send event data to the output that you specify. Understanding these concepts will help you make informed decisions about configuring Filebeat for specific use cases.įilebeat consists of two main components: inputs and harvesters. IMHO, 200 should be enough for good performance, as also confirmed by the async version.In this topic, you learn about the key building blocks of Filebeat and how they work together. One possible easy solution would be to have different defaults for the sync and async types, but it seems to me like we need a bit more investigations here to figure out exactly what happens. However, as seen above, it affects the performance of the sync publisher in Filebeat. The change from 10k to 200 didn't affect the performance of the async publisher in Packetbeat. The bulk_max_size option used to have a default of 10000 and was recently reduced to 200 due to memory issues in Packetbeat when Logstash is not available (it can allocate 1000 x 10k events). I did some tests and could get Filebeat up to 16 K/s when running together with Logstash on the same, relatively powerful, machine (8 CPU threads), by increasing the bulk_max_size option of the Logstash output in Filebeat to 3000. For reference, the reported numbers were 3 K/s events by Filebeat, compared to the TCP input doing 39 K/s or the Logstash-Forwarder doing around 13 K/s (in a report from another user). There have been reports that the Filebeat -> Logstash communication doesn't seem to be as efficient as expected.

Logstack list filebeats