There are some situations where the log file is accessed by an application without anything being written to the log, thus the mtime is changed without any changes to the file size. In cases with larger log files, this causes massive re-reads and potential performance issues on the Zabbix server.

Whenever re-reads are about to happen, the following entries are written to the log file:

1904:20190321:141018.323 the modification time of log file "C:\whatever.log" has been updated without changing its size, try checking again later

1904:20190321:141019.354 after changing modification time the size of log file "C:\whatever.log" still has not been updated, consider it to be a new file

From what we've seen, rarely, even though the lines are printed, the log files are NOT being re-read from the beginning, thus making such log entries not 100% reliable.

Adding the information about the lastlogsize in the agent log would help with reacting to potential large file re-reads thus, at least partially remedying such scenario.

Another workaround for such scenarios would be an option to select a different behavior when it comes to triggering log re-reads, but the correct implementation of such logic is up for discussion.