My understanding is that filebeat will look at the modification timestamp provided by the OS to determine if the file has been modified and then the harvester will try and read from where it left off, correct?
There is a bug in the Windows 2008 R2 that manifests itself in not updating the modification time.
Wouldn't it be a better strategy to compare the offset from the last read to the filesize and see if it has grown, instead of only relying on the OS mod time? This could be an option like:
modification_detection_strategy => [ "filesize", "modtime" ]
this would indicate trying both strategies in the order listed.
Since I am using filebeat to monitor log files that simply grow until they roll over, a filesize greater than the filesize of the last time it harvested should signify more new data to harvest.
I don't know JRuby, so if someone can create a patch and explain how to install it using simple OS commands - that would be very helpful.