Hi,
I have this issue too.
I have all the events are being forwarded to TEC from
NetView but the recently added Trap definition is not being forwarded to TEC. I
enabled NVServerd Trace but no luck (No event seen inside the log).
My problem here is the same. I mean I can see the event
sent by the device in trapd.log, but not been seen in nververd.log and TEC.
If I manually send a test trap with the help of snmptrap
command, I am receiving this event on TEC. What other thing could raise this
kind of issue?
Need help!
Thank
Senny
From: nv-l-bounces@lists.ca.ibm.com
[mailto:nv-l-bounces@lists.ca.ibm.com] On Behalf Of JaneTaylor@HBOSplc.com
Sent: Thursday, February 19, 2009 9:22 PM
To: nv-l@lists.ca.ibm.com
Subject: RE: [NV-L] trapd forwarding to tec
Thanks. The traps appear in trapd.log so I'm assuming it's a
rulesest issue. I'll give nvcdebug a try and may raise this with support. We
have fix pack 5 in plan for second half of the year so maybe I can push to get
this brought forward.
Thanks for you help.
Jane
From: nv-l-bounces@lists.ca.ibm.com
[mailto:nv-l-bounces@lists.ca.ibm.com] On Behalf Of James Shanks
Sent: 19 February 2009 15:37
To: Tivoli NetView Discussions
Subject: Re: [NV-L] trapd forwarding to tec
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>
|
|
|
To
|
nv-l@lists.ca.ibm.com
|
|
cc
|
|
|
Subject
|
[NV-L] trapd forwarding to tec
|
|
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.
==============================================================================