Re: [nv-l] nvtecia still hanging or falling behind processing TEC_ITS.rs
2004-09-14 11:33:03
I'm not aware of anyone else reporting
a similar problem. Historically, however, the adapter has
always been load sensitive.
But let's clarify the issue a bit, shall
we? Are you saying that the adapter slows down or that it hangs?
Does the heartbeat event get there eventually? How slow is
it? Do things ever recover without your taking everything down or
not? How long does that take? How big is this trap surge you
are talking about?
There is no simple way to diagnose this
issue because there is the ZCE engine in the middle, as well as the fact
that nvserverd has no idea what's going on after he does tec_put_event.
As far as NetView is concerned, once that occurs, the event has been
sent. Whether it gets to the server or not is the responsibility
of the code in the TEC EEIF library. You can use the conf file entry NvserverdTraceTecEvents=YES,
or the corresponding environment variable, to get an nvserverd.log, to
see whether nvserverd has given the event to the adapter in a timely fashion.
Then you would have to check the adapter's cache file, by default
/etc/Tivoli/tec/cache, and see whether it is caching events. It will
do that if communications with the server hiccup. But it should
recover from that automatically. When communication is lost, it tries
again on every subsequent event. If the cache isn't growing, and
nvserverd has logged the event, then the problem is internal to the TEC
code. To go deeper, you'd have to get the TEC folks involved.
They might want you to get the java
adapter traces mentioned in the conf file, or they might want a trace of
the internals of the adapter library. For that you'd have to obtain
a special diagnosis file from them, called ".ed_diag_conf"
to hook that in by a special entry in the conf file. But then
they'd have to read the traces. And all that would require that
you open a call to Support.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
"Van Order, Drew \(US
- Hermitage\)" <dvanorder AT deloitte DOT com>
Sent by: owner-nv-l AT lists.us.ibm DOT com
09/14/2004 10:22 AM
|
To
| <nv-l AT lists.us.ibm DOT com>
|
cc
|
|
Subject
| [nv-l] nvtecia still hanging
or falling behind processing TEC_ITS.rs |
|
Hi all,
After patching 7.1.4 FP01 with
the latest efix to fix nvcorrd/nvtecia hanging or stalling, we find it's
still happening. It mainly starts when we get a surge of Cisco syslog traps
from devices. The only piece not keeping up is the NV to TEC integration;
demandpolls are fine and events are moving in the Event Browser. TEC_ITS
only passes traps on, we do no other processing in the ruleset. TEC events
from sources outside NV are not impacted. We send an hourly Interface Down
trap via cron to serve as a heartbeat. When it misses the second one in
a row (as seen at TEC), we cycle NV and it's OK again. MLM is not an option
for our environment. Is anyone else struggling with this?
Thanks--Drew
*Disclaimer:*
This message (including any attachments)
contains confidential information intended for a specific individual and
purpose, and is protected by law. If you are not the intended recipient,
you should delete this message. Any disclosure, copying, or distribution
of this message, or the taking of any action based on it, is strictly prohibited.
|
|
|