nv-l
[Top] [All Lists]

Re: Filters / Rulesets

To: nv-l@lists.tivoli.com
Subject: Re: Filters / Rulesets
From: John Mayeur <jmayeur@FRUIT.COM>
Date: Wed, 8 Dec 1999 10:36:36 -0600
James -

I did not migrate the existing trapd.conf.  The new install was on a separate 
box,
so nothing was actually "migrated".  I am trying to build a duplicate of the old
one.  Is there a way to use the old (V3) trapd.conf or manually convert it for 
the
new (V5) install?

James Shanks wrote:

> 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


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

Archive operated by Skills 1st Ltd

See also: The NetView Web