|
Well
we here at Waste Management are still hanging issues getting events to flow to
TEC.
We are
at 7.1.4 FP 01 with IY60528 patch installed.
I have
no tracing and no signs that the nvtecia process (or subprocess) is even
working. Our rules (forwardall.rs) is set on pass. We have stopped and restarted
the nvserverd process several times.
The
tecint.conf file reads as follows
ServerLocation=@EventServer
TecRuleName=forwardall.rs
ServerPort=0
DefaultEventClass=TEC_ITS_BASE
Type=LCF
BufferEvents=YES
UseStateCorrelation=YES
StateCorrelationConfigURL=file:///usr/OV/conf/nvsbcrule.xml
##
The following four lines are for debugging the state correlation
engine
LogLevel=ALL
TraceLevel=ALL
LogFileName=/usr/OV/log/adptlog.out
TraceFileName=/usr/OV/log/adpttrc.out
##
The following three lines alter nvserverd default
behavior
NvserverdTraceTecEvents=YES
NvserverdPrimeTecEvents=NO
NvserverdSendSeverityTecEvents=YES
LCFINSTANCE=1
The
two logfiles are not being created.
ummmm
HELP?!
JT
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@deloitte.com>
Sent by: owner-nv-l@lists.us.ibm.com
09/14/2004 10:22 AM
|
|
To
| <nv-l@lists.us.ibm.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.
|