/var/log/apache2/*.log {
daily
rotate 7
compress
notifempty
create 644 root adm
sharedscripts
postrotate
if [ -f '/var/run/apache2.pid' ]; then
/etc/init.d/apache2 reload > /dev/null
fi
endscript
}
Sometimes (pretty rarely : about once on ten), filebeat keeps old files opened forever. lsof shows us that filebeat is at EOF, but for some unknown reasons it doesn't close the file.
Documentation says about force_close_files :
By default, Filebeat keeps the files that it’s reading open until the timespan specified by ignore_older has elapsed. This behaviour can cause issues when a file is removed.
is there a known issue about that ? What kinds of issue can happen ?
If filebeat reaches EOF on a deleted file, why it keeps it opened ?
I am worry about using force_close_files because I could lose some logs.
Filebeat should latest close a file after ignore_older, in your case 5 minutes. With the next major release we will introduce close_older as ignore_older was having to different purposes which could have conflicted: https://github.com/elastic/beats/pull/718
The file is kept open as filebeat doesn't know, if the file only was renamed and it will continue reading, if the file was actually deleted or it just disappeared for a moment.
About force_close_files: The important part is in the second part of the documentation. If you use force_close_files rotated files are only picked up again after scan_frequency. If the file was removed in the meantime and not all log lines were read before rotating, these log lines are lost.
files are rotated at 06:00am :
xxx.log is rename to xxx.log.1
xxx.log.1 is compressed to xxx.log.1.gz
xxx.log.1 is deleted
apache writes now logs to xxx.log
Filebeat has still the previous log file open xxx.log.1 ???
why, it should be closed, because force_close_file is enabled ?
I must wait 24H (default value for ignore_older) before filebeat closes the deleted file ?
in the syslog, we see these errors :
Jan 27 08:13:29 /usr/bin/filebeat[27131]: log.go:94: File reading error. Stopping harvester. Error: Force closing file: /var/log/apache2/xxx.log
After playing with ignore_older and force_close_files, we notice some issues caused by file rotation :
filebeat lets files open forever. With the time, these files eat free space on the filesystem.
when ignore_older timer has elapsed without modifications, filebeat ignores definitively the file . When this happen, we must restart filebeat.
It seems these different timers management to poll file/directory modifications are subject to race condition issues.
have you considered to use the inotify API to improve filebeat reliability ?
At now, we are going to try increase scan_frequency timer and see if it fixes our issues.
So until v2.0, the workaround is to restart filebeat at regular time to free deleted files.
I don't see other solution.
How can I test close_older feature, is there a v2.0 snapshot preview somewhere ?
thank you
It will be for sure in 2.0. We are probably not going to backport it to 2.0. In case you run with the master build, please let us know in case you have any issues.
My paths conf is /home/work/IP/*/log/ModuleCall.log.*. This 11 module create log very fast. Write file in current hour log, example ModuleCall.log.2016032913. And every hour del before day log example ModuleCall.log.2016032813, But filebeat still open this file: lr-x------ 1 work work 64 3月 29 12:58 96 -> /home/work/IP/adapter/log/ModuleCall.log.2016032813 (deleted)
Disk space seemingly don't freed. Disk used fast grow to 100%.
All the files (we did not keep it for a long time (we kept it for 15 min), but it opened all the log files, did not close any of them though only one file was active, and deleted files were remained opened.
We restarted the daemon several times
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.