Subject: Fwd: RE: Detecting cleared alarms

From: Randy Presuhn <[email-masked]>
Date: Mon, 10 Sep 2001 10:47:19 -0700 (PDT)

Hi -

I'm forwarding a posting from Sharon that was blocked by an
over-zealous spam filter.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

> Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA03484;
> 	Mon, 10 Sep 2001 06:31:52 -0700 (PDT)
> Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1])
> 	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f8ADVhJ24706;
> 	Mon, 10 Sep 2001 08:31:43 -0500 (CDT)
> Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
> 	by mx-us-hou-1-int.bmc.com (Postfix) with SMTP
> 	id 7DFD91FF113; Mon, 10 Sep 2001 08:30:04 -0500 (CDT)
> Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
> 	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8ADW7p20287;
> 	Mon, 10 Sep 2001 09:32:07 -0400 (EDT)
> Received: from zcard015.ca.nortel.com (actually zcard015) 
>           by zcars04e.ca.nortel.com; Mon, 10 Sep 2001 09:32:11 -0400
> Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
>           id <R69530BQ>; Mon, 10 Sep 2001 09:32:16 -0400
> Message-ID: <[email-masked]>
> From: "Sharon Chisholm" <[email-masked]>
> To: Dave Shield <[email-masked]>, [email-masked]
> Cc: [email-masked]
> Subject: RE: Detecting cleared alarms
> Date: Mon, 10 Sep 2001 09:32:26 -0400
> X-Mailer: Internet Mail Service (5.5.2653.19)
> X-Orig: <[email-masked]>
> 
> hi
> 
> As I've mentioned before, my experience from a prototype using
> device-optimised data structures on active alarm lists, is that
> polling only algorithms don't scale to large networks. This is
> the reason there has traditionally not been a alarmClearTable 
> in the MIB.  In London, there seemed to be support for adding
> an alarmClear table for supporting small to medium sized networks
> where polling only makes more sense.
> 
> So, if I read this thread's conclusion correctly, there is 
> still support for an alarmClearTable?
> 
> My experience with active alarm lists supports Randy's theory
> that alarms do tend to stay active longer than the typical 
> polling interval.  If they didn't, there would not be much need 
> for an active alarm list.
> 
> Also worth noting is that there are statistics in the MIB which can 
> be queried to determine if it is worth while actually polling 
> the alarmActive (or alarmClear) table each polling cycle:
> 	        alarmActiveStatsCurrentActive  Unsigned32,
>               alarmActiveStatsTotalActive    Unsigned32,
>               alarmActiveStatsLastRaise      TimeTicks,
>               alarmActiveStatsLastClear      TimeTicks
> This greatly reduces the amount of polling that needs to be
> done each polling interval. More often than not, nothing has
> changed and these statistics provide an inexpensive and easy
> to interpret method to determine this.
> 
> Sharon
>