Misbehaving Custom Timed Script 3-State Monitor

I am stumped for an action plan to resolve this issue and would gladly appreciate any possible help!!!

Issue:

Monitor has generated an alert with Resolution State=New when Healthy Expression is true and then later (without any configuration changes) another alert with Resolution State=New is generated when Unhealthy Expression is true.

Last night/this morning, I saw both of the following generated as notifications:

Last modified time: 2/10/2014 10:11:37 PM Alert description: Queue has a length of 4175 and has exceeded a threshold value of 3,500

Last modified time: 2/11/2014 9:11:37 AM Alert description: Queue has a length of 770 and has exceeded a threshold value of 3,500

Similarly created monitors which target other databases using different SQL scripts seem to behave properly.

Assessment:

Monitor targets SQL database object with Performance parent monitor, runs every 15 min and runs a SQL query to generate an integer value which is assigned to "PerfValue".

Unhealthy expression is Property[@Name='PerfValue'] greater than or equal to 3500

Degraded expression is Property[@Name='PerfValue'] equals 'unknown'

Healthy expression is Property[@Name='PerfValue'] less than 3500

Alert description is

Queue has a length of $Data/Context/Property[@Name='PerfValue']$ and has exceeded a threshold value of 3,500

Health is configured as follows:

Health condition:Healthy = Operational State:Healthy = Health State:Healthy

Health condition:Degarded = Operational State:Degraded = Health State:Warning

Health condition:Unhealthy = Operational State:Unhealthy = Health State:Critical

Generates alerts is enabled and Auto resolve is also enabled.

Ideas? Thanks in advance!!

February 11th, 2014 6:11pm

Hi!
I dont think you can mix types like that (integers and string) in your expression filter (someone correct me if Im wrong).

Try putting the logic in the script instead and just return strings or integers for your filter.

Free Windows Admin Tool Kit Click here and download it now
February 12th, 2014 1:50pm

Thanks for the response Markus.

The string was provided by my predecessor as a type of placeholder value in case the client determined a threshold value for a Warning state.  You are correct that it doesn't make sense to mix type.

Root cause has been identified and I am in the process of implementing it.

The reference article that identified root cause is here:

http://blogs.technet.com/b/jimmyharper/archive/2009/10/01/using-integers-and-other-non-string-data-types-in-rules-and-monitors.aspx

For some unknown reason, this issue impacted only 2 of the ~10 new monitors that I setup within the same MP.  It would be great to know what particular action or detail caused this.  It seems I may need to regularly inspect the exported xml after any monitor changes.

It is too bad the new monitor wizard does not provide a warning during monitor setup of unexpected results if a numerical operator is selected for a value type that it knows is a string.  This is especially true when using the Script-based monitor which I understand to always expect a returned integer value. Or it should show in the GUI what the actual data type it has assigned is.

Thanks again for your interest and taking time to respond!

February 12th, 2014 2:20pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics