There has been some discussions about monitoring log files and how Ops Mgr handle them. I did some tests in my sandbox regarding this. I created a monitor to check log files with pattern “*.log*” in C:\AppLogs\. Ops Mgr is looking for “warning” in all .log files. As soon as I input “warning” in my log file applog.log I get an alert in the console. You can use the variables below to add information to the alert description, for example the filename.

Logfile Directory : $Data/EventData/DataItem/LogFileDirectory$
Logfile name: $Data/EventData/DataItem/LogFileName$
String:  $Data/EventData/DataItem/Params/Param[1]$

If I clear the logfile and then input “warning”, I don´t get an alert. Ops Mgr remember where it read last time and will not read the hole file again, and as I am back on line one now, Ops Mgr consider that line as read. But if I add a couple of more lines Ops Mgr will generate an alert as I am beyond that line where Ops Mgr read last time.

If I add a second log file to the same directory, for example applog2.log, and input “warning” in it I get an alert instant.

Summary: If you want to limit the space that your log file needs, configure your application to use multiple log files, instead of clear the log file. For example configure your application to start a new log file every hour or day. Make sure the application are not updating the old files after a new is created. As long as the log file name patter is the same Ops Mgr will find it and monitor it, without any extra configuration. You can then configure another rule to delete old log files to clear up space.

I have note that sometimes, if you are monitoring a number of files that all are all active, the monitor health state will change after the first new “warning”, if you then get a new “warning” in a log file before the monitor is back to health you will not see that second “warning” in the console. Also note that log file monitors are not case sensitive, so if you configure it to look for Warning it will also trigger on warning.