Describe the bug
We are using LogMonitor inside a Windows container to capture a directory of C:\Logs. The application rotates log files up to a configurable integer and file size, and upon reaching the maximum number of files, replaces and overwrites content from the first log file.
Note - the logging library in use is cx_Logging
For example, with a MAX_FILES parameter of 4, the expected log file naming is:
Applog_<processId>.1.logApplog_<processId>.2.logApplog_<processId>.3.logApplog_<processId>.4.log
Upon populating Applog_<processId>.4.log to the maximum file size, the file Applog_<processId>.1.log is overwritten and begins being written to again. This behaviour persists as long as the original process ID is running.
LogMonitor operates successfully, identifying and outputting log lines up to this "overwrite" action. Afterwards, no more output from LogMonitor is detected.
It certainly sounds like the NextReadOffset per file is stored and not able to be reset under the conditions that this application uses to overwrite the original files.
To Reproduce
Steps to reproduce the behavior:
- Utilize an application with characteristics of file rotation as described, or using cx_Logging
- Upon configuring a maximum files to keep and file size, input log entries until the log rotation occurs
- Observe that Log Monitor does not read log lines from the first file following rotation
Expected behavior
It would be advantageous for LogMonitor to be able to detect and know that a file being replaced or overwritten and starting from Line 1 would reset NextReadOffset and continue to be read and output.
Configuration
-Tool: Log Monitor
-Version: 2.1.1
-Tool: cx_Logging
-Version: 2.1.0
Additional context
It is apparent to me that this could be resolved in the upstream application here, by producing log files with a unique file name on rotation. Unfortunately I have no modification capability of the upstream application at this time.
It may be debatable whether this should be considered a bug, or a Feature, related to #26
Describe the bug
We are using LogMonitor inside a Windows container to capture a directory of C:\Logs. The application rotates log files up to a configurable integer and file size, and upon reaching the maximum number of files, replaces and overwrites content from the first log file.
Note - the logging library in use is cx_Logging
For example, with a
MAX_FILESparameter of4, the expected log file naming is:Applog_<processId>.1.logApplog_<processId>.2.logApplog_<processId>.3.logApplog_<processId>.4.logUpon populating
Applog_<processId>.4.logto the maximum file size, the fileApplog_<processId>.1.logis overwritten and begins being written to again. This behaviour persists as long as the original process ID is running.LogMonitor operates successfully, identifying and outputting log lines up to this "overwrite" action. Afterwards, no more output from LogMonitor is detected.
It certainly sounds like the
NextReadOffsetper file is stored and not able to be reset under the conditions that this application uses to overwrite the original files.To Reproduce
Steps to reproduce the behavior:
Expected behavior
It would be advantageous for LogMonitor to be able to detect and know that a file being replaced or overwritten and starting from Line 1 would reset
NextReadOffsetand continue to be read and output.Configuration
-Tool: Log Monitor
-Version:
2.1.1-Tool: cx_Logging
-Version:
2.1.0Additional context
It is apparent to me that this could be resolved in the upstream application here, by producing log files with a unique file name on rotation. Unfortunately I have no modification capability of the upstream application at this time.
It may be debatable whether this should be considered a bug, or a Feature, related to #26