I have successfully setup File Content sensors in the past and have used the same method in this case. However, I was not getting a consistent result and now I am getting an incorrect result all of the time. The problem does not seem to be with getting a current refreshed version of the log file I am scanning as the Sensor Debug result file always shows what I am expecting (ie. the current version of the log file). The problem is that the Sensor is now never finding the Search String.
Sensor Details...
Windows Environment
As the file is small and gets regenerated by a system script I have set the sensor to read the entire file each time.
The logfile actually lives on the same machine as the PRTG probe. So the Sensor file name is "c:\bat\summary.log" (but I have also tried to use "C$\bat\summary.log").
I have deliberately set the Windows Credentials to a special AD service account we use for this purpose.
The PRTG Probe Service is running as "Local System"
The Search String is "Failed"
"c:\bat\summary.log" content is...
11:33 Thursday, February 18, 2016 Active Directory password changed for blah blah
More... Failed to get Active Directory EmailAddress for blah blah
Result of Sensor Debug File is ...
11:33 Thursday, February 18, 2016 Active Directory password changed for blah blah
More... Failed to get Active Directory EmailAddress for blah blah
I really don;t understand why the sensor is not noticing the "Failed" in the text. I have also changed the sensor to use a regular expression and it also does not detect it.
Have also tried using UNIX formatting for EOL.
Any insight or assistance would be appreciated. Thanks
Article Comments
Thank-You for your reply. When preparing for your request I have subsequently discovered that the text file being scanned had every second byte of its contents set as NULLl. Hence when viewed in a text mode it "looked" ok but obviously the sensor was not able to match the text required. I am not sure how but the encoding of the file was set to UCS-2 LE BOM and every time I changed the text in the file during the tests - it "looked" ok but was saved with the nulls to honour the encoding scheme. More research is required as to why the encoding was different. But other wise it now works.
ff fe 46 00 61 00 69 00 6c 00 65 00 64 00 0a 00
Shows as
Failed
Feb, 2016 - Permalink
Good to hear it's working now. In case you need further assistance, please send us those details as mentioned before.
Kind regards.
Feb, 2016 - Permalink
I'd say we need to take a deeper look at the details. Please send us the following to tickets@paessler.com:
Make sure to reference this ticket in your email.
Thank you & Kind regards.
Feb, 2016 - Permalink