New status modification request

genasea · Joined: 25 Sep 2002 Posts: 27

Thank you for including the new statuses of 'warning' and 'normal', as it will make the product much more viable for performance based testing.

We are running several thousand tests, and are getting a LOT of alarms (between 5,000 to 10,000 a day). So, this will help to process them.

One way it would help organizations even more would be for the status not even to change to normal or warning, but to allow the feature of just keeping the test status as 'ok' or 'host is alive', etc. - whatever it would normally be if it is in an acceptable state (based upon the macros).

As an example - if we decide that we do not want to have a cpu go into alarm until it has passed the alarm threshold (i.e. 95%) for more than 5 complete test cycles - using something like 'Use 'Normal' status if - (%FailureIteration% >= 1) and (%FailureIteration% <=5) - it will show up as being 'Normal', but will still be logged as a change of state into the advanced log (which we dump to a database to use with another front-end program to view alarms). If we were allowed to not have any change in the status (by not going into normal, just leaving it as original) then the there would be no state change for the test as long as it is meeting the macro criteria - if there was a feature similar to- 'Use 'Original' status if' checkbox.

I believe other users in the forums have asked for this type of function (I have seen multiple posts on this), where the test does not alarm at all (or change states) until the test has been in a certain state for more than x test iterations (i.e. high CPU for 10 minutes). The new statuses help in this area, but do not fully solve this problem.

Thank you

KS-Soft · Joined: 03 Apr 2002 Posts: 12793 Location: USA

Does anobody else need such option?

Regards
Alex

JuergenF · Posted: Wed Jan 03, 2007 12:41 pm Post subject:

It could definitly help avoiding lots of log entries.

I think for SLAs it is not necessary, because "Normal" is counted as "GOOD" ?!

thomasschmeidl · Joined: 15 Apr 2006 Posts: 166 Location: Germany, Bavaria

I agree with genasea

The brief log should be kept brief.

Thomas

genasea · Joined: 25 Sep 2002 Posts: 27

JuergenF

I just used the 'Use 'Original' Status if' as an example. I am more concerned with just leaving the status alone until is passes a threshold that we select, without having the status change to anything other than the original status, and no additional processing in the alarm logging.

Most of the several thousand tests we have are performance based tests, and should not go into a state change just due to a CPU was high for a one or two minutes (which it still does even with the new feature). Many other testing applications work this way, and we would like to have HM perform this way as well. The new feature(s) of allowing the 'normal' or 'warning' statuses work well for more advanced processing of individual testing information, but I believe it skips right over the basic functionality of just leaving the status alone until it meets the criterion I select for the test.

To be honest, we dump all the data from HM into SQL server, and use three different front end applications to access this data due to our being able to obtain a lot more information from this, rather than the HTML front-end for HM. The 30+ users in our department do not even see the HTML front-end, they access the data through these other programs. So, we do a great deal of data processing from HM and use a few other programs for processing syslog events, snmp traps, generating availability reports, processing alarms, etc.