Igor -
>From what you describe, this situation is entirely normal and expected.
As I said before, there are two times in each trap. The LOGGED time is set
by each application. So in the events window, the LOGGED time may be a
couple of seconds behind the trapd time. (But this should be true only in
a very busy system. I do not see a difference on my 5.1.1 system for
example.) The use of two time stamps is by design. In the past, customer
wanted to know when the event was posted to their viewing window. The
ovevent.log, however, uses the time stamp set by trapd, so they should
always match. The reasoning here was that Events History uses were really
after a graphical display of trapd.log.
In any case, that's how it works and no, there is no user configuration to
change it.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Igor Podlivalchev <podlivalchev@mail.kbimpuls.msk.ru> on 04/12/99 08:54:28
AM
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)
Today I've made small experiment and now can specify the problem more
accurately.
I've compared how the same event is logged in the trapd.log, in the
"Events"
window and in the "Event History" window.
Please have a look:
trapd.log:
923907898 10 Mon Apr 12 13:04:58 1999 nvs_ibm.beeline.ru S Trap: generic 6
specific 2 args(9): .....
Event window
Mon Apr 12 13:05:03 1999 nvs_ibm.beeline.ru S Trap: generic 6 specific 2
args(9): .....
LOGGEDTIME: 04/12/99 13:05:03
Event History window
Mon Apr 12 13:04:58 1999 nvs_ibm.beeline.ru S Trap: generic 6 specific 2
args(9): .....
LOGGEDTIME: 04/12/99 13:04:58
So, it looks, like ovevent.log and trapd.log have the same timestamps (and
correct timestamps!). The problem arises with the Event-viewer. It seems,
it
uses their own "LOGGED TIME", which depends on how quick ruleset is being
processed by nvcorrd/nvserver. Is my understanding correct? Or, may be,
something is wrong in my installation, or, may be, this is just a bug in
NetView? Is it possible to force NetView to synchronize timestamps in
either
window.
I'm using TME 10 NetView 5.1, TME Framework 3.6, AIX 4.3.2
Bye,
Igor Podlivalchev
-----Original Message-----
From: Discussion of IBM NetView and POLYCENTER Manager on NetView
[mailto:NV-L@UCSBVM.UCSB.EDU]On Behalf Of Leslie Clark
Sent: Thursday, April 08, 1999 4:51 AM
To: NV-L@UCSBVM.UCSB.EDU
Subject: Re: Event records in Trapd.log and Event Display window are out
of sync (has different timestamps)
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
|