[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf-pm-04 notes

Steve> So we've made it easy to poll but haven't achieved sub-second
Steve> notification (only possible with a notification). And it's here
Steve> that I'm a bit reluctant to say that a notification is a
Steve> requirement. To be honest, I really don't have a sense of this
Steve> yet. One more notification isn't that big a deal but I'm most
Steve> worried about getting into ratholes about how we can make sure
Steve> that floods of notifications don't occur.

Steve> All we would absolutely need would be to have a notification
Steve> that is sent whenever the abnormalTerminations gauge goes from
Steve> zero to non-zero and no more than 1 notification per 60 seconds
Steve> (or some similar non-configurable constant). If we could keep
Steve> it simple like this it might be worth it.

Throttling is a very very good thing, you're right.  They should be
throttled.  I wouldn't, however, base my notifications on the value 0
for the pmPolicyAbnormalTerminations object.  It implies that it won't
fire another notification till it wraps around to 0 again or until the
object is destroyed and recreated.  I'd say fire if it changes at all,
and don't fire another one till after the throttle factor.

And I disagree that it shouldn't be a configurable throttle value.  A
global notification throttle object (defaulting to, say, 60) should be
defined to deal with this.

(side note: I'd also really like to see multiple actions be available
per policy rule, and ideally fall back actions as well.  Or can a code
table call another code object in the same table? (hence making it
possible to write a function X that calls Y and Z, which could also be
called independently by another action).

Wes Hardaker
NAI Labs
Network Associates