nv-l
[Top] [All Lists]

Re: Event records in Trapd.log and Event Display window are out

To: nv-l@lists.tivoli.com
Subject: Re: Event records in Trapd.log and Event Display window are out of sync (has different timestamps)
From: Leslie Clark <lclark@US.IBM.COM>
Date: Wed, 7 Apr 1999 20:51:24 -0400
Reply-to: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
Sender: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
I'll confirm Jame's sentiment - this is really wierd. The events display IS
a reliable
mechanism. I've done lots and lots of these, and never seen anything like
what you
are describing. So it has to be something environmental that can be fixed.
Don't
give up on it.

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking



Igor -

I am completely puzzled by your problem description now.

You have a date in trapd.log for each trap and you have an event window.
Look at the events in card format.  There are two date - time stamps.  One
is on the first line of the card, the other shows in a field lower down
called "LOGGED TIME".  Does either of these match what is in trapd?
Usually, and on most systems I have observed, these are all the same.   The
only instances I am aware of where they have been different are when a user
starts an event window with a different locale, or timezone environment
variable, set than the one which trapd had.  But this results is a shift
equal to the user's offset from GMT.  I ahve never heard of a case where
any of these time stamps varies by an odd number of minutes.


To your second question, each open window runs an independent copy of a
ruleset.  5 users, each running his or her own event window with
forwardall.rs (or any rulesets), means nvcorrd runs each trap through
forwardall.rs 5 times.  The same is true for one user with 5 windows. The
reason for this is that rulesets are indepemdently registered by content,
nvcorrd does not check whether the forwardall.rs you register this time is
identical to the one you loaded last time; he just loads it and goes.   So
effcient rulesets are important for the event windows to be current  but in
the absence of a severe performance issue I have not heard nor seen this to
be a problem.

So I don't know what to make of your description

James Shanks
Tivoli (NetView for UNIX) L3 Support



Igor Podlivalchev <podlivalchev@mail.kbimpuls.msk.ru> on 04/07/99 12:31:45
PM

Please respond to podlivalchev@mail.kbimpuls.msk.ru

To:   NV-L@UCSBVM.UCSB.EDU
cc:    (bcc: James Shanks)
Subject:  Re: Event records in Trapd.log and Event Display window are out
      of sync (has different timestamps)





James,

Unfortunately, this problem is not linked to the problem with my ruleset.
The problem arise every time I start NetView (even with the simplest
ruleset
"forwardall.rs" which is configured as a default ruleset for start-up). A
certain time shift between events in trapd.log and in Event window would
not
be a problem for me. But, what is the real problem, that such time shift is
not constant. In some cases (e.g. to reconstruct network disaster) it is
important for me to analyze event sequence and relative event time delays.
So, Event window is a bed tool for this, isnt'it?
Second issue. What's happening in multi-user environment? Suppose, 5 users
are working with NetView (each running X-Window NetView session with the
same ruleset activated). Does it mean, that 5 rulesets will be slowing down
NetView, or, users will share one instance of the ruleset?

Sincerely yours,

Igor Podlivalchev


-----Original Message-----
From:   Discussion of IBM NetView and POLYCENTER Manager on NetView
[mailto:NV-L@UCSBVM.UCSB.EDU] On Behalf Of James Shanks
Sent:   Wednesday, April 07, 1999 5:48 PM
To:     NV-L@UCSBVM.UCSB.EDU
Subject:        Re: Event records in Trapd.log and Event Display window are
out
of sync (has different timestamps)

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

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web