|
View previous topic :: View next topic |
Author |
Message |
genasea
Joined: 25 Sep 2002 Posts: 27
|
Posted: Wed Jan 03, 2007 11:54 am Post subject: New status modification request |
|
|
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 |
|
Back to top |
|
|
KS-Soft
Joined: 03 Apr 2002 Posts: 12793 Location: USA
|
Posted: Wed Jan 03, 2007 12:16 pm Post subject: |
|
|
Does anobody else need such option?
Regards
Alex |
|
Back to top |
|
|
JuergenF
Joined: 26 Jan 2003 Posts: 331 Location: Germany, North Rhine-Westphalia
|
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" ?!
Quote: | if there was a feature similar to- 'Use 'Original' status if' checkbox.
|
Does that mean, when Status is BAD and expression is TRUE Status will keep BAD ?
I would define that as: Use "GOOD" Status if ...
or
Could be a ComboBox: Use "GOOD"/"Normal" Status if ...
Regards
Juergen |
|
Back to top |
|
|
thomasschmeidl
Joined: 15 Apr 2006 Posts: 166 Location: Germany, Bavaria
|
Posted: Wed Jan 03, 2007 1:46 pm Post subject: |
|
|
I agree with genasea
The brief log should be kept brief.
Thomas |
|
Back to top |
|
|
genasea
Joined: 25 Sep 2002 Posts: 27
|
Posted: Wed Jan 03, 2007 2:15 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|