Re: Alarms oddity ...

[Gary Ellis <[e-mail]>]

Robin Iddon writes:
> 
> Doing some testing on our alarms implementation I come across the following
> problem.  The problem only occurs when both rising and falling thresholds are
> equal.  What should be the behaviour when alarmValue stays equal to both
> thresholds.  Ours just started to oscillate (i.e. send alternate
> rising/falling traps on every interval) :-(.
> 
> Solutions (assuming that it shouldn't oscillate :-) 
> 
> 1. While alarmRisingThreshold == alarmFallingThreshold == alarmValue replace
> one or other of the <= and >= conditions implied by the MIB by < or >.  The
> one changed would depend on whether alarmValue approached the thresholds from
> above or below.
> 
> 2. Replace the >= and <= conditions implied by the text to < and > conditions
> for the case where alarmRisingThreshold == alarmFallingThreshold.  This is
> different from 1.  What we're saying is that there are two types of alarms,
> those with two thresholds and those with one.  Those with two use <= and >=.
> Those with one use < and >.
> 
> 3. Don't allow the case where alarmRisingThreshold == alarmFallingThreshold.
> 
> I prefer 2 as I think it's closest to what the user intended.  It has the
> disadvantage of changing the behaviour at the threshold slightly.  I don't
> like 3 because neat user interfaces will calculate the upper and lower
> thresholds as being some % above and below an actual value.  They would have
> to include some quite complex algorithms to adjust the thresholds were the %
> was 0 (or just too small to make a difference to an integer).  1 is a
> reasonable solution but least efficient to implement and not very easy to
> understand (I found it hard to explain anyway).
> 
One of the reasons for the design of the alarm table was to provide a
mechanism that would limit the number of traps emitted by the monitor.
So, there is a requirement that a value cross "the other" threshold
before an event for "this" threshold is crossed.  If we allow 
risingThreshold to equal fallingThreshold, than that built in "hysteresis"
disappears.  Of course its also true that 
	<risingThreshold == fallingThrshold + 1)
doesn't give a whole lot more protection from "trap storms" than the
equality case.  

The other thing that occurs to me is that the meaning of 
(risingThreshold > fallingThreshold) is fairly obvious, while the
meaning (or subsequent behaviour) of (risingThreshold == fallingThreshold) 
in the above context, is not quite so clear.

So I tend to favor Robin's solution #3, in which the equality case is not 
allowed.  Is manager workload that much of an issue?... it seems that all 
it has to do is detect equality and either increment risingThreshold or 
decrement fallingThreshold.

By the way, I think it is incumbent on all vendors to caution their users
about setting up alarm entries with parameters such that normal value
swings would cause lots of traps to be emitted.

---------------------------------------------------------
Gary Ellis                       ([e-mail])
Hewlett-Packard Company -- Intelligent Networks Operation