Re: [nv-l] Ruleset Editing question

Hi James:

Thanks for the prompt response. We are running in a AIX 5.1 Unix environment and are currently at Netview 7.1.3. Thanks for your different ideas and since I just learning I would like to try a couple of them in our development environment. Sounds like I probably exceeded the size limit you spoke of.

Reading through your note I should first plan on moving to Netview 7.1.4 fixpack 3 before doing anything else.

Thanks again.

Joe Piette
Unix Services
Canadian Tire Corp.
905.790.4684

James Shanks <jshanks AT us.ibm DOT com>
Sent by: owner-nv-l AT lists.us.ibm DOT com

08/23/2005 04:11 PM
Please respond to nv-l

To: nv-l AT lists.us.ibm DOT com
cc:
Subject: Re: [nv-l] Ruleset Editing question

I'm not sure that I understand just exactly what occurred, so I'm just
going to answer your questions as best as I can.
You may prefer to open a problem to Support so that you can get
personalized assistance, send them your samples, and so on.
I take it you are on some flavor of UNIX, and I am presuming that you are
using 7.1.4 (hopefully FixPack 3). Just as a hint for next time, it's
always good to state your release and platform when you ask a question.

When you create your own ruleset the first thing you want to do is make
sure that the initial node, called Event Stream, which looks like a purple
pizza, be set to BLOCK for the initial action. Then only those traps which
pass the next elements of the ruleset, or "nodes" as they are called,
will be selected for eventual forwarding, provided the ruleset ends with a
Forward node. Finally, if you want to use an alternate ruleset to send to
TEC, then you must use that ruleset name in the tecint.conf file. But you
can easily test a TEC ruleset in an Event Window. It will work the same
way. Whatever you see in the Window will be forwarded to TEC.

Now with regard to Trap Settings, yes, there is a limit to how many you can
have in a single node. There has to be. This is a programming tool after
all. Rulesets are just a way to insert user programming into the real-time
event flow on your box. But the limitation in the Trap Settings is not a
hard and fast one, but a size one, due to buffer sizes. In practical terms
this turns out to be about a hundred specific traps, at least as measured
under the NetView enterprise. Your results could be greater or fewer
depending on the length of the trap names, which are saved for display in
the ruleset .rs file. However, the ruleset editor will try to make sure
that the size is not exceeded when you are editing and pop up a message if
it is. Failing that, if an error occurs, there should also be an error
message written to the nvrsEdit.alog/blog (the logs alternate during the
edit session as first one and then the other fills up.) So if you didn't
see any messages then I'm not certain what might have happened.

Now if you have to create a ruleset which singles out hundreds of traps
what can you do? There are several alternatives.

One is to use several Trap Settings nodes, in parallel rather than in
series. Each Trap Settings would have it's own arrow coming from the Event
Stream (or the previous node) so that the ruleset would appear to fan out
at that point, and then they would all point to the next node, where it
would seem to fan back in. I hope that metaphor is clear. The TEC_ITS.rs
we ship is a good example of the fan-out, using Event Attribute nodes, We
could have written it to fan back in with just one Forward Node instead of
dozens, but that would have made it look much more complex than it is, so
we chose not to for clarity.

Another alternative if maintaining many Trap Settings nodes is too
cumbersome would be to use an In-line Action instead. Create a file
containing just the specific trap numbers you want to be selected, and
write a little script to grep it for the one that was passed in ($NVS),
exiting with a zero if found and a nonzero if not. Then plug that script
into your in-line action. Set your wait time very low, say two second, to
make sure you don't delay trap processing if the grep should hang for some
reason.

Another alternative is to use an Event Attributes node and select some
other attribute of the trap, but this too can get tiresome, as the
TEC_ITS.rs ruleset shows, unless your vendors' traps have some unique
identifier somewhere.

A final alternative might be to use a different approach altogether. Even
if your Compaq boxes (or is it Insight Manager?) are capable of thousands
of traps, how many in practice are they going to send? If they aren't
too verbose, then you might want to let through any trap they send, but
only for your most important nodes, your Compaq servers, for example. In
that case, you could group all those Important Nodes into a smartset and
then your ruleset would just check first, for the Compaq enterprise id in
the Trap Settings, followed by a QuerySmartset for the Important Nodes, and
only those which pass both are sent on. Note that it is important that
you limit the smartset query in some way with a Trap Settings or Event
Attributes, because otherwise, you'll be querying smartsets for every trap
in the system, and that will drive the entire event flow to its knees
rather quickly.

Hope this helps,

James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group

[email protected]
om
Sent by: To
owner-nv-l@lists. nv-l AT lists.tivoli DOT com
us.ibm.com cc

Subject
08/23/2005 03:05 [nv-l] Ruleset Editing question
PM

Please respond to
nv-l

Hello:

This is my first time submitting a question. I just subscribed to the list
yesterday.

Netview is a new product to me and I'm learning as I go, so please bare
with me. First let me apologize if I use incorrect terminology when talking
about Netview.

We use Netview strictly as a SNMP manager and to forward alerts onto TEC.

I was trying to edit a ruleset and add some filters to limit the traps
being forwarded to TEC. I was going through the archives and found an email
about editing rulesets and suggesting exploring IBM Redbooks. I found a
redbook that showed a step by step example how to prevent certain traps
from being forwarded to TEC ( exactly what I want to do ). I have a COMPAQ
mib that was used to generate over 1,000 trap definitions. I am only
interested in a couple of hundred.

So following the example in the redbook I invoked the ruleset editor and
added a TRAP SETTINGS node to my ruleset. At first I used the EQUAL TO
comparison to only have 2 traps forwarded. I saved the ruleset, recycled
Netview and ran a successful test. I then invoked the ruleset editor and
used the NOT EQUAL TO comparison, hi-lighting all the traps that I did not
want forwarded. Again I saved the ruleset, recycled Netview and ran a test.
This time no traps were forwarded to TEC, not even the ones I wanted to be
forwarded. So back into the ruleset editor I went and when I opened the
ruleset file the TRAP SETTINGS node and the FORWARD node were not
displayed. I had place the TRAP SETTINGS node right before my FORWARD node.

Question:

Is there a limit as to the number of traps that can be identified when
using the TRAP SETTINGS node?

If I start a session on the Unix Server and perform a simple view of the
test1.rs file that I was working with I can see all the trap numbers that I
indicated when using the GUI.

I did a search through the archives but did not find anything that might
indicate what is happening.

Any help/suggestion/advice you can offer would be most appreciated. Thanks.

Joe Piette
Unix Services
Canadian Tire Corp.
905.790.4684