John -
Most people want their paging and emails to be independent of whether or not the
GUI is up. So they tend to have those things done either by rulesets designed
just for that purpose and run in the background, or else have them run in
scripts kicked off from automatic actions in trapd.conf. Either way, what the
operators are doing with the GUI does not matter. As long as the proper daemons
are up, the actions happen.
To run a ruleset in the background you put its name in the
/usr/OV/conf/ESE.automation file, which is then read by actionsvr on start up.
He registers them with nvcorrd, just as users register rulesets when they open
a dynamic workspace. The only thing to be careful of that the rulesets need to
be designed to be run by a daemon, which does not have a console. Since he
cannot display events, the ruleset should not contain elements which require a
display such as the Forward, Resolve, or Override nodes, and the Initial Event
Stream node should be set to "Block" the sending of events to the display,
otherwise the event subsystem will slow and eventually hang.
Any filters used in V3 (and that was the only way to keep things off the display
in V3 unless the trap were configured to be "Log Only") will still work in V5.1
and later. And any scripts run as automatic actions should still work too if
you have some of those. Did you migrate your trapd.conf or start with a fresh
one?
James Shanks
Tivoli (NetView for UNIX) L3 Support
John Mayeur <jmayeur@FRUIT.COM> on 12/07/99 03:37:42 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: Filters / Rulesets
James -
The Netview V3 that is in production here was installed and maintained by
persons no
longer with the company. The hardware and the O/S are not Y2K compliant, hence
the
need for the install. I inherited this system and its replacement. I have
little
knowledge on how it was setup and that is why I am trying to understand rulesets
and
filters.
I did use a seedfile to discover the network (loopbacks for routers) and NetView
did
a good job of discovering. As I said earlier we use this only for UP/DOWN
notification (currently). So at the ethernet and token-ring segment level I have
changed the symbol type so their status does not propagate. I don't mind having
all
the objects (2000 nodes/250 networks/75 gateways) in the database because the
box
running NetView has plenty of resources and NetView is all that runs on it.
This
box sits in our data center and the computer operators monitor the networks for
failure. I was trying to configure the Events app so that all the operators see
is
the events for the nodes we care about. Additionally I would like to add the
features such as the pop-up window, email, paging etc.
So if I understand your explanation:
netmon polls
sends updates to ovwdb & ovtopmd
ipmap updates maps and color of the icons
forwards trap (from netmon poll or trap sent from host) to trapd
trapd logs and then sends to event correlation daemon
In my case since I have the Events app open at start-up, it is the only dynamic
workspace open:
correlation then processes it through the ruleset used for Events
filter would pass or block events to the display
Question:
Is it ok to use the ruleset for Events to page, pop-up window, email or what
ever
you need?
It seems this would keep things simple if it is ok to channel everything through
this one ruleset.
James Shanks wrote:
> 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@COMMSERV.UCSB.EDU> on 12/06/99 05:54:32 PM
>
> Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
> <NV-L@UCSBVM.UCSB.EDU>
>
> To: NV-L@UCSBVM.UCSB.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
|