I backed out of posting a question on this thinking it was just my own wrongdoing...now I'm not so certain. (and it still may be)
I have a log file that is being written out by tomcat, fairly regularly, has intermittent breaks.
Here's a modified version of what I have NOW:
filebeat.prospectors:
- type: log
paths:
- /opt/tomcat/logs/application.log
exclude_lines: []
multiline.pattern: ^\d{4}-\d{2}-\d{2}_
multiline.negate: true
multiline.match: after
ignore_older: 30m
tail_files: true
exclude_files: [".zip$"]
fields: {application: "embeddedportal", index: "v4emb"}
enabled: True
I have deleted the file: /var/lib/filebeat/registry
The logfile is being ingested, but not long after running, I have a series of these...and filebeat keeps adding more.
filebeat 6343 30727 root 68r REG 253,0 10493019 158586 /opt/tomcat/logs/application.log12025895980106140.tmp (deleted)
filebeat 6343 30727 root 69r REG 253,0 10486122 158590 /opt/tomcat/logs/application.log12025954310868597.tmp (deleted)
filebeat 6343 30727 root 70r REG 253,0 10486573 158595 /opt/tomcat/logs/application.log12026055144410584.tmp (deleted)
filebeat 6343 30727 root 71r REG 253,0 10485841 158598 /opt/tomcat/logs/application.log12026100258340372.tmp (deleted)
filebeat 6343 30727 root 72r REG 253,0 10487221 158602 /opt/tomcat/logs/application.log12026141517669076.tmp (deleted)
So with this being said...Where some have told me it's tomcat causing this, I don't believe that to be true. I am at the latest 6.4 filebeat to date. and tomcat doesn't own the files that are in deleted state. But I do have to say, these .tmp files add up quite quickly. I've tried adding the .tmp to the ignore list...not that it should matter as it doesn't match the entry in paths. section.
Why isn't filebeat letting go of the files after 5 minutes or even whatever I set. There are defaults that are supposed to be enabled by default, (close_renamed, closer_removed, etc)