check_eventlog

Check for errors in the event log.

Provided by: the [CheckEventLog] module

Samples and usage: This page provides reference information for samples and usage please see the samples page CheckEventLog/check_eventlog/samples.

Option	Default value	Description
help	N/A	Show help screen (this screen)
help-csv	N/A	Show help screen as a comma separated list.
truncate		Truncate the resulting message (mainly useful in older version of nsclient++)
filter		Filter which marks interesting items.
file		The name of an eventlog file the default ones are Application, Security and System. If the specified eventlog was not found due to some idiotic reason windows opens the \application\" log instead."
syntax		A string to use to represent each matched eventlog entry the following keywords will be replaced with corresponding values: %source%, %generated%, %written%, %type%, %severity%, %strings%, %id% and %message% (%message% requires you to set the description flag) %count% (requires the unique flag) can be used to display a count of the records returned.
date-syntax	%#c	Detail level syntax.
debug	N/A	Enable debug information.
descriptions	N/A	Allow searching and scanning and rendering descriptions field (will be much slower).
unique	N/A	Only return one of each message (based on message id and source).
MaxWarn		Maximum number of matches before a warning is returned.
MaxCrit		Maximum number of matches before a critical is returned.
MinWarn		Minimum number of matches before a warning is returned.
MinCrit		Minimum number of matches before a critical is returned.
warn		Expression which raises a warning status.
crit		Expression which raises a critical status.
ignore-perf-data	N/A	Do not return performance data.
ShowAll	short	Show all values not just problems.
ShowFail		Show all values not just problems.

Options

help_

The _ is due to trac bugs, real name is help

Show help screen (this screen)

Syntax: help

Sample:

check_eventlog ... help ...

help-csv

Show help screen as a comma separated list.

Description: This is useful for parsing the output in scripts and generate documentation etc

Syntax: help-csv

Sample:

check_eventlog ... help-csv ...

truncate

Truncate the resulting message (mainly useful in older version of nsclient++)

Syntax: truncate=ARGUMENT

Sample:

check_eventlog ... truncate=ARGUMENT ...

filter

Filter which marks interesting items.

Description: Interesting items are items which will be included in the check. They do not denote warning or critical state but they are checked use this to filter out unwanted items.

Syntax: filter=ARGUMENT

Sample:

check_eventlog ... filter=ARGUMENT ...

file

The name of an eventlog file the default ones are Application, Security and System. If the specified eventlog was not found due to some idiotic reason windows opens the \application\" log instead."

Syntax: file=ARGUMENT

Sample:

check_eventlog ... file=ARGUMENT ...

syntax

A string to use to represent each matched eventlog entry the following keywords will be replaced with corresponding values: %source%, %generated%, %written%, %type%, %severity%, %strings%, %id% and %message% (%message% requires you to set the description flag) %count% (requires the unique flag) can be used to display a count of the records returned.

Syntax: syntax=ARGUMENT

Sample:

check_eventlog ... syntax=ARGUMENT ...

date-syntax

Detail level syntax.

Default value: date-syntax=%#c

Sample:

check_eventlog ... date-syntax=%#c ...

debug

Enable debug information.

Syntax: debug

Sample:

check_eventlog ... debug ...

descriptions

Allow searching and scanning and rendering descriptions field (will be much slower).

Syntax: descriptions

Sample:

check_eventlog ... descriptions ...

unique

Only return one of each message (based on message id and source).

Syntax: unique

Sample:

check_eventlog ... unique ...

MaxWarn

Maximum number of matches before a warning is returned.

Syntax: MaxWarn=ARGUMENT

Sample:

check_eventlog ... MaxWarn=ARGUMENT ...

MaxCrit

Maximum number of matches before a critical is returned.

Syntax: MaxCrit=ARGUMENT

Sample:

check_eventlog ... MaxCrit=ARGUMENT ...

MinWarn

Minimum number of matches before a warning is returned.

Syntax: MinWarn=ARGUMENT

Sample:

check_eventlog ... MinWarn=ARGUMENT ...

MinCrit

Minimum number of matches before a critical is returned.

Syntax: MinCrit=ARGUMENT

Sample:

check_eventlog ... MinCrit=ARGUMENT ...

warn

Expression which raises a warning status.

Syntax: warn=ARGUMENT

Sample:

check_eventlog ... warn=ARGUMENT ...

crit

Expression which raises a critical status.

Syntax: crit=ARGUMENT

Sample:

check_eventlog ... crit=ARGUMENT ...

ignore-perf-data

Do not return performance data.

Syntax: ignore-perf-data

Sample:

check_eventlog ... ignore-perf-data ...

ShowAll

Show all values not just problems.

Description: Some commands support setting this option to long or short to define how much information you want.

Default value: ShowAll=short

Sample:

check_eventlog ... ShowAll=short ...

ShowFail?

Show all values not just problems.

Description: Some commands support setting this option to long or short to define how much information you want.

Syntax: ShowFail?=ARGUMENT

Sample:

check_eventlog ... ShowFail=ARGUMENT ...

Sample commands

Notice this section is included so please go here if you want to edit this section.

CheckEventLog

Filter Keywords

Keyword	Values	Description
type	event type expression	An event type to filter out: error, warning, info, auditSuccess or auditFailure. See discussion
source	string-expression	The name of the source of the event.
generated	time-expression	Time ago the message was generated
written	time-expression	Time ago the message was written to the log
strings	string-expression	Filter string content of message (this is fast as it does not requires us to render the message).
message	string-expression	Filter messages (this is slow as it requires us to render the message).
id	numeric-expression	Filter based on the event id of the log message.
severity	event severity expression	Filter based on event severity: error, warning, informational

Operators

Operator	Safe	Description
	eq	Equality ( a = b ) or ( a eq b )
=||ne	Not equal ( a <= b ) or ( a le b )
>	gt	Greater then ( a > b ) or ( a gt b )
<	lt	Less then ( a < b ) or ( a lt b )
>	ge	Greater then or equal ( a >= b ) or ( a ge b )
<	le	Less then or equal ( a <= b ) or ( a le b )
like	Compare to strings using substring matching ( 'a' like 'apple' )
not like	Compare to strings using substring matching ( 'a' like 'apple' )
regexp	Compare to strings using regular expression matching ( 'apple' regexp 'a.*' ) This requires 0.3.9
AND	Both statements has to be true ( a AND b )
OR	Either statement has to be true ( a OR b )
IN	See if a value matches a given list ( 'a' IN (123, 456, 789) )
NOT IN	See if a value does not matches a given list ( 'a' IN (123, 456, 789) )

Writing Filters

Filters are based upon SQL Where clauses. For instance the following is a valid filter:

severity = 'error'

This is interpreted as "severity" has to be an "error".

Apart from the various keywords (and their valid values) there is a set of operators which can be used to construct expressions. Thus you can extend the previous to

severity = 'error' OR severity = 'informational' OR severity = 'warning'

You can also use parenthesis to group the order

severity = 'error' AND (severity = 'informational' OR severity = 'warning')

Using Keywords

Since they keywords are handled a bit differently I will write up a short section on each one of them.

id (event id)

The event id is a unique identifier identifying a message "Number" inside an application. Thus it is uniq together with an event source. Event id is a number which means it unsurprisingly can be compared with other numbers like 1 or 2 or even 3 or perhaps even 4 (not sure about 5 though) and lets not forget the ohh so hyped 42. Comparing numbers are done using the equality or no equality operators (= and !=) you can also use the in and not in grouping operators.

The simplest usage is: id = 1008

CheckEventLog file=application debug=true MaxWarn=1 MaxCrit=1 "filter=id = 1008" truncate=800 unique descriptions "syntax=%id%: (%count%)"
CRITICAL:1008: (94), 1008: (1), eventlog: 95 > critical|'eventlog'=95;1;1;

The reason we get "More then one" 1008 result back is because different sources have generated the same error number (remember id AND source) is unique not by them selves. So adding source to the syntax shows us this: id = 1008

CheckEventLog file=application debug=true MaxWarn=1 MaxCrit=1 "filter=id = 1008" truncate=800 unique descriptions "syntax=%source% %id%: (%count%)"
CRITICAL:Customer Experience Improvement Program 1008: (94), Windows Search Service 1008: (1), eventlog: 95 > critical|'eventlog'=95;1;1;

The next thing we can do to extend this is to make a slightly more complicated filter: id = 1008 OR id = 1005 OR id = 123 OR id = 8224

CheckEventLog file=application debug=true MaxWarn=1 MaxCrit=1 "filter=id = 1008 OR id = 1005 OR id = 123 OR id = 8224" truncate=800 unique descriptions "syntax=%id%: (%count%)"
CRITICAL:1005: (2), 1005: (118), 1008: (94), 1008: (1), 8224: (164), eventlog: 379 > critical|'eventlog'=379;1;1;

This can of cource be simplified (in this case) using the IN operator: id IN (1008, 1005, 123, 8224)

CheckEventLog file=application debug=true MaxWarn=1 MaxCrit=1 "filter=id IN (1008, 1005, 123, 8224)" truncate=800 unique descriptions "syntax=%id%: (%count%)"
CRITICAL:1005: (2), 1005: (118), 1008: (94), 1008: (1), 8224: (164), eventlog: 379 > critical|'eventlog'=379;1;1;

The opposite can also be used like so: id NOT IN (1008, 1005, 123, 8224)

CheckEventLog file=application debug=true MaxWarn=1 MaxCrit=1 "filter=id NOT IN (1008, 1005, 123, 8224)" truncate=800 unique descriptions "syntax=%id%: (%count%)"
CRITICAL:... (12), 3407: (12), 3408...|'eventlog'=5435;1;1;

source (program generating the event)

Next up is the event source it is set to a string value representing the program generating the event. A string can be compared to other strings and in addition to the equality and non equality (= and !=) like makes a lot of sense to match sub strings. You can also use the IN and NOT IN if you want to specify more then one application but this, I guess, will make less sense. Notice that there is NO regular expression yet this will be added in the next version.

The simplest example here is: source = 'MsiInstaller?'

CheckEventLog file=application debug=true MaxWarn=1 MaxCrit=1 "filter=source = 'MsiInstaller'" truncate=800 unique descriptions "syntax=%source%: (%count%)"
CRITICAL:MsiInstaller: (78), MsiInstaller: (2), MsiInstaller: (178), ... MsiInstaller: (1), eventlog: 1347 > critical|'eventlog'=1347;1;1;

Then we can try using the like sub string matching like so: source like 's'

CheckEventLog file=application debug=true MaxWarn=1 MaxCrit=1 "filter=source like 's'" truncate=800 unique descriptions "syntax=%source%: (%count%)"
CRITICAL:idsvc: (51), Microsoft-Windows-ApplicationExperienceInfrastructure: (4), SQLBrowser: (26),... MsiInstaller: (254), Mic...|'eventlog'=3174;1;1;

An important not about the like operator is that it is the same from both sides ie: 'hello' like 'h' and 'h' like 'hello' are both true.

Using the in list operator like so: source IN ('idsvc', 'MsiInstaller?')

CheckEventLog file=application debug=true MaxWarn=1 MaxCrit=1 "filter=source IN ('idsvc', 'MsiInstaller')" truncate=800 unique descriptions "syntax=%source%: (%count%)"
CRITICAL:idsvc: (1), MsiInstaller: (78), MsiInstaller: (2), ... MsiInstaller: (1), eventlog: 1348 > critical|'eventlog'=1348;1;1;

generated (when the event was generated)

This is the "hardest" in terms of using I guess. Dates are treated as number internally and thus works much like a number. The added value that numbers expose are the ability to translate numbers to dates. This happends by adding a suffix ti a number. For instance 2d is read as 2 days. And 5h is read as 5 hours. The other important aspect of using dates are how negative numbers are used. Normal dates 5d will be interpreted as "<now> + 5 days". But when you add a negation sign (-) before it will be negated (ish). And this is the crux. What actually happens is that -5d is treated as neg(5 days from now) and neg negates the date around "now" so in effect it becomes 5 days ago. This might sound complicated but it not really and you probably don't need to understand it but I think explains why < and > will work.

Thus the effect of this is that you can do: generated > -5d'

CheckEventLog file=application debug=true MaxWarn=1 MaxCrit=1 "filter=generated > -5d" truncate=800 unique descriptions "syntax=%generated%: (%count%)"
CRITICAL:Thursday, May 13, 2010 03:18:46: (11), ...|'eventlog'=276;1;1;

Written

For details see generated as they work the same. This is the date when the event was written to the log.

Severity

Type

Message

Using filter+message=substr:"[member of syntax=%string%]" will work. Keep in mind that syntax=%string% returns only strings found in the event, which excludes statements:

For example in the following event:

Event Type:	Failure Audit
Event Source:	Security
Event Category:	Logon/Logoff 
Event ID:	534
Date:		8/29/2011
Time:		12:44:30 PM
User:		NT AUTHORITY\SYSTEM
Computer:	SERVER
Description:
Logon Failure:
 	Reason:	The user has not been granted the requested
 		logon type at this machine
 	User Name:	theuser
 	Domain:		LOCAL.CORP
 	Logon Type:	10
 	Logon Process:	User32  
 	Authentication Package:	Negotiate
 	Workstation Name:	SERVER
 	Caller User Name:	SERVER$
 	Caller Domain:	LOCAL.CORP
 	Caller Logon ID:	(0x0,0x3E7)
 	Caller Process ID:	5036
 	Transited Services:	-
 	Source Network Address:	192.168.100.20
 	Source Port:	6650

%strings% include literals: theuser, LOCAL.CORP, 10, User32, Negotiate, SERVER, SERVER$, LOCAL.CORP, (0x0,0x3E7), 5036, -, 192.168.100.20, and 6650 %strings% does NOT include any of the built-in strings, like "Reason:" (or it's reason :D ), "User Name:", etc.

Note: Currently there seems to be no practical way of using the message filter since neither the substr or regexp matchers appear to operate, and using LIKE on a message results in a 'Parsing Failed' error.

Strings

This example will look for an event showing completion of a specific SQL Server backup (in this case for the SalesDB database) and if it is found in the last 28 hours will display and return OK, but if it is not found will return CRITICAL. This is a fairly crude approach in that it looks for the database name anywhere in the event strings, but for most purposes should work acceptably well.

CheckEventLog file=application MinWarn=0 MinCrit=0 "filter=generated gt -28h AND source = 'MSSQLSERVER' AND id IN ('18264') AND strings like 'SalesDB'" truncate=800 unique descriptions "syntax=%severity%: %source%: %id%: %message% (%count%)"
eventlog: 0 < critical|'eventlog'=0;0;0;

Examples

CheckEventLog file=application file=system MaxWarn=1 MaxCrit=1 "filter=generated gt -2d AND severity NOT IN ('success', 'informational')" truncate=800 unique descriptions "syntax=%severity%: %source%: %message% (%count%)"

Workarounds

DCOM on Windows 2008

Some issues reported on filtering DCOM events on Windows 2008 which can (presumably) be solved according to the following page: ​http://support.microsoft.com/kb/2008047