Larry,
Is it a TEC rule that is holding the event?. In my shop we run a script
against the trap on the netview server whenever an interface down event
comes in - the script polls the device 3 times with a 20 second sleep
between each poll - if the interface is still down after the 3rd poll we
then send an alert. When we started out we saw a very large number of
interface down alerts (essentially whenever a router hiccuped - which
happens regularly) hence the delays and polls.
The timeouts were agreed with our network team (not sure whether its
industry standard or not) and they seem to be happy that the alerts they
get are proper.
Regarding the 10 minute hold in TEC - have a look at your rulebase,
there is probably a rule there which is holding the event in cache
waiting for a clearing (interface_up) event for 10 minutes - it should
be easy enough to reduce the wait time.
Regs
Colin M.
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]
On Behalf Of Larry Fagan
Sent: 04 October 2005 15:20
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] Polling Intervals Info!
Paul,
Thanks for looking into this.. My situation is this..
I have inherited this environment.. Netview poll
settings is as below but in TEC these interface down
events are held for 10 minutes.. If no Up is received
from same hostname, then an down alert goes out to
team.. Now the issue is why is this 10 minutes hold in
TEC. Can't i lower this to lesser value.. Is there any
issues or false events generated if i lower 10 minute
hold since we have about 17,000 interfaces to poll..
What is the industry standard in polling the nodes? My customers are
saying "It's really NOT good to know that the server is down ONLY after
about (10+3)13 minutes".. Again many thanks as usual.. Larry
--- Paul Stroud <nvladmin@gmail.com> wrote:
> Larry,
> This is actually pretty simple;-)
>
> With the polling set as you have it:
>
> netmon will poll each device once every three
> minutes, it will
> wait 5 seconds for a reply and will try a total of 4
> times per
> device if there are any failures.
>
> For the question about how netmon polls(sequential
> vs simultaneous),
> the answer is yes. Netmon has a fixed(but
> configurable) number of
> threads available for polling, for each ICMP and
> SNMP. So netmon will
> poll X number of devices at the same time and then
> all devices as it gets
> around to them.
>
> To see the list of devices being polled you can run:
>
> netmon -a 12 (to see what netmon is polling via
> ICMP)
> netmon -a 16 (to see what netmon is polling via
> SNMP)
>
> This information will be stored in the /usr/OV/log/netmon.trace file.
> That being said, you might find looking through
> 17,000 IP addresses
> a bit tedious;-)
>
> Paul
>
>
> Larry Fagan wrote:
>
> >Gentlemen,
> >I have gone through tons of info in list on this
> >topic. But i just need a simple answer for my
> >configuration. I have set timeout=5 retries=3
> >polling=3m. Now can some one tell how the polling
> >works in this case? how does netmon poll fo rup and
> >down's?
> >My second question is, I have about 17,000
> interfaces
> >to be polled in my DB. Does the polling to all
> these
> >interfaces happens sequentially or simulataneously?
> >How can i check if all my nodes are being polled?
> Is
> >there a way to see all of my nodes are polled?
> >I'm really exhausted looking into this.
> >Please could someone help me?
> >Many Thanks as usual.
> >Larry
> >
> >
> >
> >
> >__________________________________
> >Yahoo! Mail - PC Magazine Editors' Choice 2005
> >http://mail.yahoo.com
> >
> >
> >
>
>
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
*********************************************************************************
This e-mail and its attachments, is confidential and is intended for the
addressee(s) only. If you are not the intended recipient, disclosure,
distribution or any action taken in reliance on it is prohibited and may be
unlawful. Please note that any information expressed in this message or its
attachments is not given or endorsed by An Post unless otherwise indicated by
an authorised representative independently of this message. An Post does not
accept responsibility for the contents of this message and although it has been
scanned for viruses An Post will not accept responsibility for any damage
caused as a result of a virus being passed on.
*********************************************************************************
|