John -
Steve's right about this, I think.
And basically, nothing has changed in the fundamentals since NetView Version 3
-- those traps you see are generated by netmon. All that has changed is that
you can do more (a lot more) with the traps than before. But if you never,
ever want to see them, don't want them logged, and don't want to waste cpu and
memory processing them, then you want to exclude them, by not having those
objects in your database at all. Read up on seed files and determine how best
to exclude what you don't want in the database. And post your questions here
for help.
But my question to you is -- How were you handling this in V3? That method
should still work in 5.1
Other than that the answers to your events questions are fairly straightforward.
All events go through some ruleset or other before showing up in the event
window. You can use the Create pull-down to create a new window and use a
different ruleset in each one. You can control what ruleset is the default and
which workspaces (windows) are started by editing /usr/OV/app-defaults/Nvevents.
Each user can have his own defaults by copying this file to his or her $HOME
directory and editing that.
ESE.automation has no connection with the event windows you see. That file is a
mechanism to have the actionsvr start some rulesets running in the background
for things like paging and other notifications independently of whether the
event windows are open. Rulesets used there should not have any reference to
the display (no Forward, no Resolve, no Override function) as this will only
cause performance problems.
A filter is the last thing that happens before the window displays the events.
You cannot filter the input to a ruleset, only the output. If you don't want to
see events from DHCP addresses and you can create a filter to do that, then do
it.
You won't see them, but they will still be generated and logged in trapd.log.
What we have been talking about here is the event window display. Nothing you
do for this lightens NetView's load (hence Steve's response). netmon still
monitors (pings and issues snmpget) all nodes, ovwdb and ovtopmd put them in the
database, ipmap draws them and updates their colors on the map, and traps still
gets all the traps, logs them, and passes them on to the correlation daemon,
nvcorrd, for ruleset processing. So there is still all this overhead, no matter
what you display in the window. That's not a bad thing. It is just important
that you know what you are doing so you can make wise choices.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Steve Francis <steve.francis AT COMMSERV.UCSB DOT EDU> on 12/06/99 05:54:32 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L AT UCSBVM.UCSB DOT EDU>
To: NV-L AT UCSBVM.UCSB DOT EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: Filters / Rulesets
Usually the best way to handle this is to:
- only discover things that you want managed (put in a discovery filter so
that only SNMP devices are discovered, assuimng your end user PCs are not
SNMP capable, or filter discovery by the SNMP OID if they are)
- or discover PCs as unmanaged (based on lack of SNMP support or OID).
Then they will not be polled by Netview, and it will not generate events
for them.
Saves you lots in Netview CPU, memory, etc.
John Mayeur wrote:
> AIX 4.3.2
> Netview 5.1
> Framework 3.6.1
>
> I am replacing a Netview 3.x server with a new one ases described above.
> My company basically uses the product for up/down status notification
> only. It monitors routers, RS/6000's, AS/400's, file/print servers,
> hubs and switches. None of these hosts are configured to send traps to
> the new installation. I have all the components installed and working
> and I have a map built with all the submaps needed.
>
> My questions are concerning filters and rulesets. When Netview is
> started the Events app is running in the Control Desk. It is constantly
> scrolling messages for Node Up/Down, Interface Up/Down for hosts I don't
> need to monitor (end user PCs). Since there are no hosts configured
> (yet) to send traps, I assume these are being generated by the polling
> process? My goal is to show only events/traps for the nodes needed. I
> have noticed that the Events app starts with the forwardall.rs ruleset.
> Should I modify this ruleset or create a new one? How do you start the
> Events app with a different ruleset by default? Can you have multiple
> rulesets active for the Events app (ESE.automation)? Or should a filter
> block all of the unwanted events first. Which comes first the filter or
> the ruleset? I would like to start by filtering (exclude) all events
> that come from hosts that have an IP address issued from DHCP if
> possible (because I know the ranges). Would there be a better selection
> criteria? I have read the docs on this but it is still unclear to me.
> Could someone please explain the "flow" of events and traps as well as
> tips to efficiently handle them.
>
> John Mayeur
> Network Engineer
|
