rss
Away for a bit
I'll be in Cologne/Marl? in Germany for a few days so wont be able to reply much...
Michael Medin
First RC for 0.3.8
Hello everyone.
Time for a RC:s for the up-coming 0.3.8 so please try it out and let me know. I will try to post a note later on with the cumulative updates but for now you will see whats new in this version only.
2010-04-21 MickeM - 0.3.8 RC1
+ Added support for strings and int (values) to CheckSingleRegEntry
Use like so (int):
CheckSingleRegEntry path=HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\MaxSize "syntax=%path%: %int%" warn==20971520 crit==20971520 check=int ShowAll=long
CheckSingleRegEntry path=HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\MaxSize "syntax=%path%: %int%" warn==30971520 crit==30971520 check=int ShowAll=long
Use like so (string):
CheckSingleRegEntry path=HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\MaxSize "syntax=%path%: %string%" warn==20971520 crit==20971520 check=string ShowAll=long
CheckSingleRegEntry path=HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\MaxSize "syntax=%path%: %string%" warn==30971520 crit==30971520 check=string ShowAll=long
This can ofcourse be combined and all valid operators (like regexp, substr, lt, gt, ne etc etc are supported.
Michael Medin
New nightly build
New minor build with a new command: CheckSingleRegEntry? Used for checking registry entries (at the moment only existence) Scedule postponed 1 week since the eventlog took a bit more time ten I had anticipated and this weekend will be mountainbike weather!!! :)
SOON It is currently building and hopefully will be posted after that.
2010-04-16 MickeM
+ Added new Check to CheckSystem: CheckSingleRegEntry
Similar to the previous CheckSIngleFile but can be used to check aspects of registry entries.
CheckSingleRegEntry path=HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\MaxSize "syntax=%path%: %exists%" warn==true crit==true check=exists ShowAll=long
CheckSingleRegEntry path=HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\MaxSizeYY "syntax=%path%: %exists%" warn==true crit==true check=exists ShowAll=long
Currently only supports checking existanse of keys but more checks will be added soon.
2010-04-14 MickeM
! Fixed erroneous error message "Failed to peek buffer"
Michael Medin
New nightly with support for dates in new CheckEventLog
Hello.
A new nightly build is out. It features support for date/time in the new CheckEventLog. Dates are handled somewhat differently from before, but more "logical" I hope. Dates are specified like so:
generated gt -2d
This means event record was generated more recently then "2 days ago". In other words 'generated > (now - 2 days)'. You can of course also specify 'generated gt 2d' which means records generated "in the future" (not very sensible really) but for consistency I think this is much better then "having them then other way around".
This can be combined with the usual AND/OR expressions I mentioned earlier.
generated gt -2d AND severity = 'error'
The above means all records from the last 2 days which has severity error.
A sample command for instance would look like this:
CheckEventLog debug=true file=application file=system MaxWarn=1 MaxCrit=1 "filter=generated gt -2d AND severity = 'error'" truncate=800 unique descriptions "syntax=%severity%: %source%: %generated% %strings% (%count%)"
The overall scheduling for the up-coming 0.3.9 release is RC sometimes this week and unless something pops up a release set for next 2 weeks or so.
Michael Medin
New nightly with the "new" event log checker
Hello,
The eventlog checker code is now live in the latest nightly build. You can try it wout using something along the lines of the following:
CheckEventLog debug=true file=application file=system MaxWarn=1 MaxCrit=1 "filter=severity = 'error' AND strings like 'SQLEXPRESS'" truncate=800 unique descriptions "syntax=%severity%: %source%: %strings% (%count%)"
Most things are similar the "new" option is: filter=<where expression> where the <where expression> is similar to a SQL where clause.
Operators supported are:
=, !=, >, <, >=, <=, eq, ne, gt, lt, ge, le, OR, AND, like
Keywords supported:
id, source, type, severity, message, strings, written, generated
Types supported:
string, int, severity
In pother words since date is NOT supported you cant really use the written and generated options since you have no way to specify "time" this will be fixed next week. Same thing goes for type which cant (like severity) parse strings into integers.
But PLEASE try this out despite the limitations as I would like some feedback on what kind of features you would need and also find any bugs.
A few examples:
severity = 'error' OR severity = 'warning' (severity = 'error' OR severity = 'warning') AND strings like 'SQLEXPRESS' (severity = 'error' OR severity = 'warning') AND (strings like 'SQLEXPRESS' OR strings like 'SOMETHING ELSE') (severity = 'error' OR severity = 'warning') AND (strings like 'SQLEXPRESS' OR strings like 'SOMETHING ELSE') OR 1 = 1 OR 1 = 2
Michael Medin
The all-new eventlog checker is working!
Hello everyone (and that is you Google index bot!)
News
Today I can announce the first ever all-new EventLog? check working on my development machine. It was (actually) much much harder to make this then I had initially anticipated and halfway through I almost gave up. The checkin (in a few days or so) will be around 2000 lines of code (thats around 10% of NSClient++) so it was a pretty long haul. Given the complexity I think this will be in beta for a while but I really think the new syntax will be pretty awesome!
How it works
The check I run today looks like so:
CheckEventLog debug=true file=application file=system MaxWarn=1 MaxCrit=1 "filter=severity = 1" truncate=1023 unique descriptions "syntax=%severity%: %source%: %message% (%count%)"
Most of the options are the "same old":
- debug=true Enable debugging (something I always do when I develop things :)
- file=application / system What to check
- MaxWarn/MaxCrit? When it is bad/worse
- truncate Make sure it fits
- unique Keep the result minimal (ie. don't report multiple items)
- descriptions This might be removed as it is sort of superfluous but I am not sure yet.
- syntax Same old same old.
And here it comes
"filter=severity = 1"
- filter Has a new meaning in this case saying report all messages with a severity of 1
Changing this parameter to for instance:
"filter=severity = 1 AND severity = 2"
yields no results as severity cant be BOTH 1 and 2 at the same time where as
"filter=severity = 1 OR severity = 2"
yields more results as we now have both 1 and 2 as allowed values.
As you can see the values are "numeric" at the moment but that will be fixed a bit later on as I get all the conversion code ready.
The nitty gritty details
Another interesting thing is how this works. The expression is parsed into a tree which is "enhanced" in several passes. If we look in the debug log we can see this:
d \CheckEventLog.cpp(648) Using: where
Use the new "where" mode.
Parsing
d \CheckEventLog.cpp(302) Parsing: severity = 1 OR severity = 2 AND 1='1'
d \CheckEventLog.cpp(310) Parsing succeeded: {tbd}op:or({tbd}op:=({tbd}:severity, {tbd}#1), {tbd}op:and({tbd}op:=({tbd}:severity, {tbd}#2), {tbd}op:=({tbd}#1, {tbd}'1')))
Expression was parsed into the tree. All the "tbd" here is the types which at the moment are unknown which the parser will do next.
Type inference
d \CheckEventLog.cpp(318) Type resolution succeeded: {bool}op:or({bool}op:=({int}:severity, {int}#1), {bool}op:and({bool}op:=({int}:severity, {int}#2), {bool}op:=({int}#1, {int}fun:auto_convert({string}'1'))))
Here we have looked up the types.
Automatic conversion
An interesting point here is the
{int}fun:auto_convert({string}'1')
This phase discovered that an "int" was compared to a "string" and "solved" this by converting the string to an int.
Static evaluation
Next up is a static evaluation
d \CheckEventLog.cpp(326) Static evaluation succeeded: {bool}op:or({bool}op:=({int}:severity, {int}#1), {bool}op:and({bool}op:=({int}:severity, {int}#2), {bool}#1))
And as you can see here the function is removed and replaced by an "boolean value" (true). Since the expression does not contain any variables the static evaluation figures out it is pointless to do this over and over and thus removes it.
Variable Binding
d \CheckEventLog.cpp(334) Binding succeeded: {bool}op:or({bool}op:=({int}:severity, {int}#1), {bool}op:and({bool}op:=({int}:severity, {int}#2), {bool}#1))
Here we cant really see a difference since the bindings are not showed but what has happen is that the filter is bound to the variables which will contain the data. This is actually much faster than the old version which did "string" comparisons for every check. Now it already knows what it will do and just executes the code. I have yet to run any tests on this but presumably a well written where clause will be faster then the previous version.
That is all for now good people you can expect nightly builds with this functionality either this week or the next.
Michael Medin
I am not dead! :)
Hello everyone,
Sorry for being "off-line" last few weeks but I have actually been working more diligently then usual.
What I am working on is a parser for defining filter expressions. The first use case for this is the event log check but in the future this might be added to more places.
The syntax is similar to "SQL WHERE" Clauses so the following will for instance be a valid check:
CheckEventLog MaxWarn=1 MaxCrit=1 "filter=(id = 123 OR id = 321) AND (severity='warning' OR severity='error')"
Michael Medin
