CheckEventLog

Check eventlog has many "versions" this page reflects the brand new (still Experimental) version. For the previous version see [this page].

CheckEventLog is part of the wiki:CheckEventLog module.

This check enumerates all event in the event log and filters out (or in) events and then the resulting list is used to determine state.

Option	Values	Description
file	An event log file name(application, security, system, etc.)	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.
filter	filter expression	The filter expression
descriptions	None	Flag to specify if you want to include string representation of the error messages.
truncate	length of the returned set	This will truncate the output after the specified length. As NRPE can only handle 1024 chars you need to truncate the output.
MaxWarn	number of records	The maximum records to allow before reporting a warning state.
MaxCrit	number of records	The maximum records to allow before reporting a critical state.
syntax	String	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.
unique		Flag to indicate unique filtering is used.

Filter Keywords

Keyword	Values	Description
type	event type expression	An event type to filter out: error, warning, info, auditSuccess or auditFailure.
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
message	string-expression	Filter strings in the message. Can be a substring or regularexpression
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' )
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

Strings

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%)"