|
Ah, didn't read that properly. I still need to trace
nvserverd. Yes it's something of a long winded exercise isn't it. I'll
definitely speak to support on this.
Thanks again.
Jane
Tracking down missing events is not something I recommend customers do on
their own without help from Support, but I will explain how to do it.
The
first thing I would do is start running the nvserverd trace. nvserverd is the
daemon who send events to TEC. You can trace his activities by editing
/usr/OV/conf/tecint.conf and uncommenting the line
#NvserverdTraceTecEvents=YES
Then you can get
nvserverd to reload the file with the command
nvtecia
-reload
This will cause nvserverd to write every event he processes
to a new file, /usr/OV/log/nvserverd.log. When you think you have missed an
event in TEC, look in this file and see whether it was logged. If you see it
logged then nvserverd gave it to the TEC library code for forwarding but the
adapter suppressed it for some reason. In that case, you'll have to open a
problem to the TEC folks to get them to help you trace the adapter code. After
nvserverd write the event to his log, he is blind to what happens to it after
that. You will need to monitor the growth of the nvserverd.log. There is no size
limit and no code to restart it after it grows to a certain size. If you delete
or rename it while nvserverd is running, he will simply start writing to a new
copy.
If you are missing the event in TEC, and it's in the trapd.log but
you don't see it in the nvserverd.log, then I would suspect a ruleset problem.
To diagnose that you can start running the nvcorrd trace. nvcorrd is the daemon
who gets events from trapd and correlates them before passing them on to
nvserverd for display or forward. To do that you would issue
nvcdebug -d
all
This will cause nvcorrd to start writing what he is doing to the
nvcorrd.alog. After he has written a 1000 lines, he switches to the
nvcorrd.blog. After a another 1000 lines there, he switches back to the alog
again and so it goes, alternating between the logs so that they don't get too
big. But on a busy system they fill up fast, so as soon as you notice a problem
you might want to shut him down or copy the logs so they don't get overwritten.
Alternatively you could edit the /usr OV/conf/ovsuf file and edit
it
0:nvcorrd:/usr/OV/bin/nvcorrd:OVs_YES_START:nvsecd,trapd::OVs_WELL_BEHAVED::/usr/OV/conf/FFDC/scripts/nvcorrd_FFDC:5:
to
add a log file parameter to nvserverd's definition, like this
0:nvserverd:/usr/OV/bin/nvserverd:OVs_YES_START:nvsecd,nvcorrd:-l/usr/OV/log/mynvcorrd.log:OVs_WELL_BEHAVED:30:/usr/OV/conf/FFDC/scripts/nvserverd_FFDC:5:
If
you do this nvcorrd will only write to that log rather than switch. But you will
have to manage it, just as you do with nvserverd.log.
That's about all I
can tell you except that when nvcorrd gets an event you will see a "received an
event" eyecatcher in the log. Immediately thereafter you will see him try to
match it to one of the rulesets he is running. If the match is successful he'll
write out all the parameters of that event. Then you will see him process any
actions for that event and finally forward it on. He'll do this for each ruleset
in turn and when he's down with each of them you will see another eyecatcher in
the log which reads "finished with the event".
Now having said all that,
I would urge you to get help from Support with this. And I would also urge you
to get current first. FixPack5 has been available since December 2006 and there
have been fixes made to TEC forwarding. You are so far behind on maintenance
that it is difficult to guess where the problem lies. Do your missing Compaq
traps have null data in them? Long strings of hex zeros? We fixed a problem like
that some time ago. And that's why you should get current before trying to
figure this out. Your problem might already be solved.
James
Shanks
Tivoli Network Availability Management Level Three
Network
Availability Management
Tivoli Software, IBM Corp
1-919-224-1642 | T/L
687-1642 | ITN 26871642
 JaneTaylor@HBOSplc.com
JaneTaylor@HBOSplc.com
Sent by:
nv-l-bounces@lists.ca.ibm.com
02/19/2009 07:20 AM
|
Please respond to
Tivoli
NetView Discussions
<nv-l@lists.ca.ibm.com> | |
|
Hi
In my
forwarding rule set I have the compaq enterprise selected and then a number of
specific traps selected to forward to tec. Some of these get forwarded and other
don't. As far as I can see the traps are all set up in the same way with the
event category set to Status Event.
If I generate one using serversetup, that gets straight through to
tec so I'm assuming this doesn't go through the ruleset. Is this correct and can
anyone offer any suggestions as to how I can track down the problem? I'm running
on AIX, with Netview 7.14 FP4
Thanks
Jane
-----------------------------------------------------------------------------------------------------
HBOS
plc, Registered in Scotland No. SC218813. Registered Office: The Mound,
Edinburgh EH1 1YZ. HBOS plc is a holding company, subsidiaries of which are
authorised and regulated by the Financial Services
Authority.
==============================================================================
_______________________________________________
NV-L
mailing
list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser
access limited to internal IBM'ers only)
-----------------------------------------------------------------------------------------------------
HBOS plc, Registered in Scotland No. SC218813. Registered Office: The Mound, Edinburgh EH1 1YZ. HBOS plc is a holding company, subsidiaries of which are authorised and regulated by the Financial Services Authority.
==============================================================================
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
|
