We have a cronjob to reduce log size in case disk full. the command used is truncate. like:
truncate -s 15G /path/to/file
We found that filebeat will quickly eat up all memory in the system (16GB in our case) when log file got truncated. Restart filebeat wouldn't help (filebeat process RSS memory would reach 15GB in a few seconds), unless removed the registry file to make filebeat read log file from the beginning again.
Not sure if this is a bug, or is there any configure to suppress this issue
I didn't open the debug, and now i can't reproduce the issue.
I had tried to truncate a file to simulate the case. but as you mentioned, Filebeat would reset the offset to 0. I suspect that my log file might somehow damaged.
BTW, looks like Filebeat can't handle the truncate command well. As I was truncated the file to a smaller size but not wipe it to 0, it shouldn't read from the beginning again.
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.