Igor -
trapd.log is maintained by trapd, the daemon who gets the traps. Every
time he gets a new trap, he writes the old one to the log. To get the
event in the window, it must first be passed to nvcorrd, who runs it
against all active rulesets, and if it passes one with a Forward, it is
given to nvserverd, who passes it to all connected event displays. So if
your ruleset is causing a performance problem in nvcorrd, it will show up
as events being slow to appear in the event windows. Fixing your ruleset
may eliminate your problem.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Igor Podlivalchev <podlivalchev@mail.kbimpuls.msk.ru> on 04/07/99 06:20:46
AM
Please respond to podlivalchev@mail.kbimpuls.msk.ru
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks)
Subject: Event records in Trapd.log and Event Display window are out of
sync (has different timestamps)
Hi James,
thank you for you message. I will certainly follow your advise.
But, ruleset problem figured out one very "funny" feature. Event timestamps
in the trapd.log and in the Event window are very often different. Today I
made a little investigation and found, that time difference may come up to
10 min (depending on circumstances)! Typical value is 5 sec - 60 sec.
(Sometimes a real disaster may happen: event displays in Event window after
15 min it was registered in the trapd.log.)
It looks, like Event window sometimes slows down and loses correct
timestamp. Then, Event window speeds up and goes back into sync with
trapd.log.
Is this mis-synchronization usual for NetView, or something is wrong with
my
system?
Such behavior of Event window (when watching current events) is independent
to how many rulesets are active. I saw this, even with the only NetView
session with Event window running (ruleset: forwardall.rs).
Could you give me some clue on what should I do to solve the problem.
Sincerely yours,
Igor Podlivalchev
PS. In a meantime I had a look trough NV Manuals. There is nothing about
this problem.
-----Original Message-----
From: Discussion of IBM NetView and POLYCENTER Manager on NetView
[mailto:NV-L@UCSBVM.UCSB.EDU] On Behalf Of James Shanks
Sent: Tuesday, April 06, 1999 7:22 PM
To: NV-L@UCSBVM.UCSB.EDU
Subject: Re: Ruleset problem: Delay in forwarding events to Event
window
Well, your ruleset is very inefficient. The first thing you apparently do
for ALL traps, of whatever origin, is check the ovwdb database to see if
the sending host is in collection "Routers" and then in collection
"Switches". Most likely they are not. But nvcorrd, which processes the
ruleset, must wait while the ovwdb processing to check collection
membership completes, twice for each trap. That means that this is done
for even "Log Only" traps and everything else. I'll bet that nvcorrd gets
bogged down when a bunch of traps comes in, or when ovwdb is being heavily
used by another process (such as netmon).
What you should do, in my opinion, is check some traps settings before you
call the collection check and only process traps you know will be
significant for those routers or switches, like link down, node down, and
so on. By pre-selecting the types of significant traps, which nvcorrd has
immediate access to, you cut down his processing tremendously.
By the way, you can see what nvcorrd is doing by issuing the command
nvcdebug -d all
and then browsing the nvcorrd.alog and .blog. You turn the trace off
again by issuing
nvcdebug -r
or stopping and restarting nvcorrd.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Igor Podlivalchev <podlivalchev@mail.kbimpuls.msk.ru> on 04/06/99 09:30:47
AM
Please respond to podlivalchev@mail.kbimpuls.msk.ru
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks)
Subject: Ruleset problem: Delay in forwarding events to Event window
Hi all,
I'd like to feed our on-duty staff with only critical network information.
I've created a ruleset, which forwards out network events from critical
nodes (routers, switches, RMON agents), other events are discarded.
Critical
nodes are part of corresponding collection.
Structure of the ruleset are quit simple:
Event ----- (is contained in collection "Router") -------------> forward
+-------------(is contained in collection "Switches") -----> (is RMON
trap) -------> forward
+-------------------> (is not RMON trap) -----> (severity >3) --->forward
But, after activation of this ruleset, I saw considerable delay in
processing events. Sometimes event time shift (delay between when event
really arise in the network and displayed in either Event window) may reach
10 min.
Does anybody can give me any idea on how fight this problem out?
Sincerely yours,
Igor Podlivalchev
|