You've got me. I don't quite follow all this. But the way EH works is
that once you do a query, your display is fixed until you do another one.
So if you look at everything in the workspace at a particular time, and
repeat the same query an hour later, you probably won't get the same
results because, while the display doesn't change, the ovevent.log is being
written to, all the time, behind the scenes. If your network is very
active with events, then the old ones are going away rapidly. In some
environments, they don't stay for even 15 minutes.
Dynamic workspaces in current events are a different story. There are two
limitations. First, when a new one is opened, it will only be primed with
the last 100 events that nvserverd knows about, and those that display will
be those that match the ruleset criteria for that window. So how far back
the window goes in time in a function of the number of events arriving in
your network. You cannot count on it always being the same time because
you could have a trap burst which would throw the calculation off. The
design here s that current events really are current, the priming is just
so that we do not usually have a blank window when one is opened. I 'm
afraid none of this is configurable, so what you see is what you get. The
only thing you can configure is the maximum number of events which the
window will hold, ad we limit that to between 500 (the default) and 1000.
You can change this in /usr/OV/app-defaults/Nvevents.
For what it is worth, there has been considerable discussion in development
about eliminating EH as it is not as useful as it was before NetView
Version 3. With the advent of rulesets in Version 4, the ovevent.log is no
longer used to prime the window display, as I just explained. So it is
just a hold-over from an earlier time.
The bottom line here is that you cannot guarantee that you can always go
back to a certain point in time in the events GUIs, whether Current or
History. And with History you have to periodically refresh the screen with
a new query to see what has come in since the last time. Your best bet
is to create your filters and go forward with only current events. But
you will have to have a current events window up all the time if you want
to search both forward and backward with your filters.
Hope this helps.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
Stephen Elliott <selliott@epicrealm.com> on 10/09/2000 02:09:11 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
To: "'IBM NetView Discussion'" <nv-l@tkg.com>
cc: (bcc: James Shanks/Tivoli Systems)
Subject: RE: [NV-L] Event History
Thanks for your reply, James. I can match only parts of what you are saying
to what I am seeing. Your suggested starting point is pretty much where I
began. I created a dynamic workspace for Critical and Major events with no
time interval spec'd and to include all nodes. In the Current window there
were 7 Critical events generated within the last hour, but only the 2 most
recent showed up in the new dynamic workspace. Since ovevent.log is a
binary
file, I can't compare the two to see what really should there. The current
size of ovevent.log is only 68K, the .BAK only 132K. Creating a dynamic
workspace based on severity should have shown me all 7 criticals and any
other matcheing events that were in the Current workspace. New events are
coming in to the new workspace, so at least that much is working.
We're looking to build dynamic WS's for specific things that go back X
time/events in history and keep updating with new events that pass the
filter. This seems to be the sticking point with dynamic workspaces, they
can't go back in time past some very recent point (< 1 hr.?). It doesn't
make sense for my operators to have to create two different workspaces to
accomplish one task. Is this even possible in NetView? I am probably
missing
something in building WS's, but that's the way it's shaping up.
Beyond that, I still can't find the reason that creating a Historical WS
with no filters active displays 20-odd events from Sept. 21. Trapd.log is
full of current events.
Regards,
Steve Elliott
Sr. Network Mgmt. Engineer
epicRealm, Inc.
214-570-4560
-----Original Message-----
From: James_Shanks@TIVOLI.COM [mailto:James_Shanks@TIVOLI.COM]
Sent: Monday, October 09, 2000 11:24 AM
To: IBM NetView Discussion
Subject: Re: [NV-L] Event History
Event History has nothing to do with trapd.log. It reads what is in
/usr/OV/log/ovevent.log. The biggest size this can be is 2MB, ad when this
is reached, old events are replaced with newer ones.
I would try it by starting it without any filters and then apply them.
I'll bet the evens you want are not in ovevent.log any longer. Events
History should have been called "Recent Events History" because in most
busy shops it will not hold even a day's worth of old events. The
purpose was just to show an operator what he might hav missed from the
previous shift. It was not designed to go back any farther. Historical
analysis has to be done on trapd.log, which you can archive and browse as
you see fit.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
Stephen Elliott <selliott@epicrealm.com> on 10/09/2000 12:08:22 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
To: "'nv-l@tkg.com'" <nv-l@tkg.com>
cc: (bcc: James Shanks/Tivoli Systems)
Subject: [NV-L] Event History
All,
I'm having a great time trying to get Event History to work with a filter
specific to certain address ranges. When activated and a query made,
nothing
shows up in the workspace. If I change the Object Identification field to
pass events from all objects, I still get nothing. I've specified a period
of the last 2 days and I've confirmed that there are valid target events in
trapd.log for this timeframe. I've included the filter rules below. If
anyone can spot an error, please let me know.
For all events:
PRESENT=SNMP_TRAP && (LOGGED_TIME>=07:10:00:00:00:00) &&
(LOGGED_TIME<=09:10:00:15:37:00)
For events from specific nodes in 2 address ranges:
PRESENT=SNMP_TRAP && ((IP_ADDR=10.24.0.*) || (IP_ADDR=63.*.*.*)) &&
(LOGGED_TIME>=07:10:00:00:00:00)
&& (LOGGED_TIME<=09:10:00:15:37:00)
Are there known bugs regarding Event History that might account for this
problem?
Regards,
Steve Elliott
Sr. Network Mgmt. Engineer
epicRealm, Inc.
214-570-4560
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|