RE: Traps and frequency
"Mike Ayers" <[email protected]>
| Newsgroups | gmane.network.net-snmp.user |
|---|---|
| Message-ID | <83E753BE7B6A324ABB336245BAF1DAAC08E258CD@mailserver.metatv-ds.metatv.com> |
> From: [email protected] > [mailto:[email protected]] On > Behalf Of José Eduardo Martins > Sent: Monday, July 14, 2008 7:46 AM > monitor [OPTIONS] NAME EXPRESSION > (bla, bla, bla). This monitor entry will not fire again > until the monitored condition first becomes false, and then > matches again. (bla, bla, bla). > > Is there any way to overcome this behaviour? I.e., always > fire the monitor, forgeting the previous state? No, and that's a good thing. There is no reason to do what you want, other than to glue to misengineered monitoring systems, in which case you should write an application that receives the disman events to track the state and sends the nagifications. If you are not stuck with a receiving application that requires this, then you should do a little more study of management principles to learn why state-change-only is the correct thing to do. If you are concerned about loss of state synchronization, SNMPv3 informs and/or the disman notifications MIB can achieve better synchronization than trap-spamming with much less resource use. HTH, Mike ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users