"James Shanks" <SHANKS@us.tivoli.com> writes:
> Help me out here, Todd.
> You keep complaining bitterly about the ruleset editor and rulesets in
> general, and yet the GUI feature is one which most users prefer.
Choices are good things. If you're a single netview administrator
only having to worry about your one netview server, that's one thing.
If you're a development organization supporting multiple locations,
each of which are service providers for multiple customers, having
users merge new rules graphically often over an X11 connection going
over a WAN, and dealing with large rulesets, it can make you bitter.
> We won awards for it,
When?
> and it is the most often requested enhancement to the NT product,
> which doesn't have one.
I'm not saying the ruleset editor is a bad thing...but please accept
that it's not the Only Thing. Documenting the .rs file format and/or
allowing users to merge rulesets from the command line would be very
useful for our environment. Some folks prefer a GUI, but we're not
among them. The ability to script and do things from the command line
is very important to us in supporting servers that live on the other
side of the country.
> Why does it matter how long it takes for the ruleset editor to load
> your TEC rule? Once you have it working, why would they want to
> load it?
That one time can cause you heaaches when it takes 10 minutes (no
exaggeration) for the ruleset to come up on the screen and begin
working. Throw in a blip of packet loss that freezes your X server
and you're ready to go ballistic. If you're supporting multiple
environments and have to do that 3 times within an hour just to add a
trap to a ruleset...
> Why is your TEC rule so complicated?
Our TEC supports a large number of alerts, and opens tickets
automatically. False alerts can be a problem as can TEC performance
and TEC cache size. We only want to send specific traps--not all.
> Are you thresholding or something? If all you are trying to is
> maintain a list of specific traps, and what you really want is a
> file of them, why not just write a script and use a user exit?
That is essentially what is desired. If NetView can't handle the
notion of a per-trap action definition, then writing a script as you
propose would make things much easier.
How would you specify that this script be run in the ruleset editor?
An Action node coming straight off the event stream? or are you
proposing running this script as an action command in the Event
Settings for each trap we'd want to forward?
What about performance with Netview forking a brand new process for
every inbound trap to check it against the list? And, in such a
situation, am I really leveraging much value from NetView?
> For example, the enterprise id of the trap will be accessible as
> $NVE and the specific trap number as $NVS. So you could just build
> a nice big list of the ones you want in some file and then in your
> script grep for those.
If that is considered best practice for sending specific traps to TEC,
then I'd be all for it. My only concern with such an approach is the
number of processes that you might have to be forking to run this
script when a lot of traps are coming in.
--
|