MonitorWare Knowledge Base

[erik]

Hello,
I downloaded 30-day evaluation versions of Monilog, EventReporter and WinSyslog. I have set it up according to the instructions found at your web site:
[url]http://www.monitorware.com/Common/en/Articles/monitoring-Win-setup-ER5WS4ML1.asp
[/url]

The logs are being sent by the EventReporter to the SysLog server, but my Monilog report summary is all zeros.

Looking into the debug.log I found this error message multiple times:

Code: Select all

Analyzing log file = D:\Syslog\WinSyslog-2003-10-21.log
Log time parsing error: Month '-1' out of range 0..11 at MoniLog.ctrl line 728
Log time parsing error: Month '-1' out of range 0..11 at MoniLog.ctrl line 728
Log time parsing error: Month '-1' out of range 0..11 at MoniLog.ctrl line 728
Log time parsing error: Month '-1' out of range 0..11 at MoniLog.ctrl line 728
Log time parsing error: Month '-1' out of range 0..11 at MoniLog.ctrl line 728
Log time parsing error: Month '-1' out of range 0..11 at MoniLog.ctrl line 728


It looks like it's reading the date field one character too early. The date is 2003-10-22 and my guess is that Monilog is seeing the month

10

as

-1

I checked Format for Monilog in the settings. Anything else I can try?
Thank you,
Erik

[agrigorof]

Can you email us few sample lines from your log? Please send them to support@monilog.com as an attachment in order to preserve the format of the log. My suspicion is that there is an extra field in the log that Monilog doesn't expect.

[Erik]

Adrian,
Thank you for the quick response. I forwarded a section of the log file as requested to support@monilog.com. There were some log entries that wrapped because there was so much text in the event log. Below is one of the lines that appears to wrap in the log file and looked suspicious.

2003-10-22,00:29:06,172.16.1.103,16,4,EvntSLog: RealSource:"SERVER3" [WRN] Wed Oct 22 00:28:45 2003: SERVER3/DNS (7062) - "The DNS server encountered a packet addressed to itself -- IP address 172.16.1.103. The DNS server should never be sending a packet to itself. This situation usually indicates a configuration error. Check the following areas for possible self-send configuration errors: 1) Forwarders list. (DNS servers should not forward to themselves). 2) Master lists of secondary zones. 3) Notify lists of primary zones. 4) Delegations of subzones. Must not contain NS record for this DNS server unless subzone is also on this server. Example of self-delegation: -> This DNS server dns1.foo.com is the primary for the zone foo.com. -> The foo.com zone contains a delegation of bar.foo.com to dns1.foo.com, (bar.foo.com NS dns1.foo.com) -> BUT the bar.foo.com zone is NOT on this server. Note, you should make this delegation check (with nslookup or DNS manager) both on this DNS server and on the server(s) you del

egated the subzone to. It is possible that the delegation was done correctly, but that the primary DNS for the subzone, has any incorrect NS record pointing back at this server. If this incorrect NS record is cached at this server, then the self-send could result. If found, the subzone DNS server admin should remove the offending NS record."

Maybe that's the problem?
Thank you,
Erik

[Erik]

Adrian,
The changes have been made to all servers and the reports are coming through. Now for the fun part of reading all the information.
Thank you,
Erik

Hello Erik,

As I expected, there are some extra entries in the log lines that creates problems for Monilog.

<snip>

The "RealSource:"SERVER3"" shouldn't be there and I think is added when you configure EventReporter default rule set / ForwardSyslog/Actions/ForwardSyslog/Add Syslog Source when forwarding to other Syslog servers. So please make sure that this option is not checked. Once you check it off (for all the servers), stop WinSyslog, move the existing logs (as they are in the "old" format) and then restart WinSyslog.

Verify that the log entries do not contain the "RealSource:<....>" tag.

I have attached the report that I got once I removed those entries from the log sample you sent me.

Regards,

Adrian Grigorof
Altair Technologies
www.altairtech.ca
_