Cheshire Cat Computing

Hi,

Very sorry if this has been covered already. If it has, my google-fu has failed me.

The Application Log filter is set to send Criticals on Errors only.

So why am I getting Criticals on things such as this:

Application [CertEnroll #64]: Local system
Certificate enrollment for Local system successfully load policy from policy server

where Level: is "Information"

or this:

Application [vmStatsProvider #256]: root\cimv2
The "vmStatsProvider" is successfully initialized for this Virtual Machine. WMI namespace: "root\cimv2".
where Level: is "Information"

I've ticked Information, reloaded Nagios Eventlog, got heaps of 'stuff', unticked it, reloaded and got the above 'Critical' events again.

Any help would be appreciated.

Cheers,

Lee

You can enable Debug mode in the eventlog agent; this will give detailed logs indicating which of the filters matches and why for every log parsed (can generate a LOT of additional logs).

The reason ahould be that you get a match on another filter with higher priority, and this filter has a Critical status associated with it.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

Hi,

Thanks for the reply. I did as you suggested and turned on debug mode.

The filters are the defaults (Application, Security and System). The following was sent as a Critical to nagios:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="vmStatsProvider" />
<EventID Qualifiers="2">256</EventID>
<Level>0</Level>
<Task>1</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2012-05-31T01:34:40.000000000Z" />
<EventRecordID>56702</EventRecordID>
<Channel>Application</Channel>
<Computer>tville1.streams.northern.tmr.its</Computer>
<Security />
</System>
- <EventData>
<Data>root\cimv2</Data>
</EventData>
</Event>

This is shown as "Level: Information" on the General tab in Event Viewer

The 'debug' shows the following:
------------------------
The description for Event ID 0 from source NagiosEventLog cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

Caught an event and sent it on (Src=vmStatsProvider).
Matching filter was 'Application Log'

The specified resource type cannot be found in the image file
-------------------
and this one as well:
-------------------------
The description for Event ID 0 from source NagiosEventLog cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

NSCA: 1 data packet(s) sent to host successfully.


The specified resource type cannot be found in the image file
------------------

So, still a mystery to me.

Cheers,

Lee

This is telling you that the filter "Application Log" was the first match for the event in question.

The default "Application Log" filter should send a Critical status to the "Application EventLog" Nagios service. However, it should only match "Error" events, not information. For some reason, this is matching.

Can you confirm (a) what version of NagEventLog you are using (I have 1.9.0 here); and also exactly how you have configured your filters -- you can get these from the registry under HKEY_LOCAL_MACHINE/SOFTWARE/Cheshire Cat/Nagios

It may be that you have either a older buggy version, or else you have modified your default filters and this is a true match.

There is also a possibility that you are running a much later version of Windows that is no longer compatible with the binary, but that is less likely.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

Another thought that occurs to me is that it may be getting confused by the eventlog types. This happened in old servers when a new eventlog was added. To fix this, you delete all current filters, then manually recreate them.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

Hello again ,

Nagios EventLog: Versions: Agent: (1,9,2,0) Control App: (1,9,2,0)

Windows Server 2008 R2 Enterprise, SP1, 64-bit

Deleted all log filters (the 3 default ones) and recreated them.

I'm getting the same results as before.

The registry entry for the Application Log:

Class Name: <NO CLASS>
Last Write Time: 31/05/2012 - 12:16 PM
Value 0
Name: filterDesc
Type: REG_SZ
Data: Application Log

Value 1
Name: eventLog
Type: REG_DWORD
Data: 0x2

Value 2
Name: eventLogName
Type: REG_SZ
Data: Application

Value 3
Name: serviceName
Type: REG_SZ
Data: Application EventLog

Value 4
Name: ID
Type: REG_SZ
Data:

Value 5
Name: matchString
Type: REG_SZ
Data:

Value 6
Name: source
Type: REG_SZ
Data:

Value 7
Name: Information
Type: REG_DWORD
Data: 0

Value 8
Name: status
Type: REG_DWORD
Data: 0x2

Value 9
Name: Warning
Type: REG_DWORD
Data: 0

Value 10
Name: Error
Type: REG_DWORD
Data: 0x1

Value 11
Name: Audit Success
Type: REG_DWORD
Data: 0

Value 12
Name: Audit Failure
Type: REG_DWORD
Data: 0

Value 13
Name: notID
Type: REG_DWORD
Data: 0

Value 14
Name: notMatch
Type: REG_DWORD
Data: 0

Value 15
Name: notSource
Type: REG_DWORD
Data: 0

Unfortunately, the problem continues and I cannot find a solution to it, other than adding a lot of filters to cater to the false positives.

My guess is that this is something to do with the way Win2k8 handles the parsing and string matching; I know it has preferences for multibyte chars and this can muck things up.
Until I have a development environment for 64bit Win2k8 there's not much I can do (currently I develop in XP, 32bit).
There is also a lot of work required to get the wide character support working.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11