In the configuration of the snmpCollect daemon, there is
an option that controls how long it should wait before retrying
when it fails to contact a node. By default this is 60 minutes.
I usually change that to 15, figuring most things, if they are
being rebooted, will be back up by then, and a common
polling interval is 15 minutes, so with luck I would only miss
one polling interval. Since you want to poll much more frequently,
you would want to set that interval even smaller. If you look
in /usr/OV/log/snmpCol.trace, you will see reports of these
failures to collect. Of course it would be nice if snmpCollect
did not keep this information to himself, but that's how it works.
Others may be able to advise you on the hows and whys
of tcp port monitoring.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
"Barry R. Hammen" <bhammen@accmail.umd.edu>@tkg.com on 05/31/2001 02:25:30
PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: IBM NetView Discussion <nv-l@tkg.com>
cc:
Subject: Re: [NV-L] Netview Data Collection and Thresholds
I'm using Data Collection and Thresholds to monitor the TCP ports used by
the
netscape servers on my AIX machines (I don't like the mib-trap that
netscape
supplies to monitor the server).
Every 5 minutes, the TCP port is polled to see if it's up. If the port is
up,
a trap is sent that sets tells the GUI that the server is up, if no trap is
sent, the server is considered to be down.
My problem is whenever the server goes down, and netview polls the port and
it
is down, Netview won't try to poll the port again for another 40-60 minutes
(it
varies everytime). I have the threshold set to 0 and the rearm set to
10000
(so that if the port is active the threshold will be exceeded everytime and
the
event will be rearmed.) I'm pretty new to Netview and I cannot figure out
why
there is a variable length delay in the polling when I have the polling
interval set to 5 minutes.
If someone could either help me out with this problem or let me in on a
better
way to monitor a TCP port, I'd greatly appreciate it.
Barry
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|