Thanks James. I have a much better feel for the "why" portion of the
location in the process flow now. I have rewritten the rule, moving the
query smartset to AFTER the reset on match. I have a 4 CPU box w/ 4GB -
so I'm not overly concerned w/ performance (yet anyway!) and am a
scripting newbie (mostly DOS batch files) so the query smartset is very
attractive to me still. If the flow has been corrected but the ruleset
still fails to process - what do you recommend trying to ID the problem?
Was I correct to use Attrib #2 in the query smartset?
Glen Warn
PEMCO Corporation Computer Services (PCCS)
glen.warn@pemcocorp.com
206-628-5770
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]
On Behalf Of James Shanks
Sent: Thursday, April 21, 2005 12:33 PM
To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] Ruleset problem with Netview 7.1.4 running RedHat
Linu x AS 2.1
Glen --
Let me jump in here even before Bill answers.
The issue about smartsets versus other db calls, or even lists you grep
yourself, depends on how volatile things are and how often you reference
them.
When nvcorrd queries a smartset he doesn't do it by himself. He first
has to query ovwdb for the object id of the suspected member. Then he
has to ask nvcold whether than object id is a member of the target
smartset.
While those daemons formulate a response, nvcorrd waits, and so does
your ruleset. If you don't limit what traps nvcorrd should use as a
base, you end up getting a lot more failures than successes and in the
process your performance goes to pot.
Since these calls to other daemons are expensive, you should limit them
if you can.
That was Paul's point about using a trap filter first.
You are going to have to tell nvcorrd what variable binding of the trap
he should look at to determine the object id. So your first ruleset
item should always be a Trap Setting, or at worst, an Event Attribute
node, to pick out just those traps to be considered before you query
your smartset,
or the database, or even your own list of hostnames. If you put the
query
first, then it will be driven by absolutely every trap in the system,
including those marked "log only", such as "netmon connected to trapd"
or "format file changed."
If you structure your ruleset in that way, so that you are only having
to query the smartset for membership when you have a pretty good idea
that what you are asking to be resolved really is an object in the
database, then it works much better, and you really reduce the overhead.
But I am not certain whether once that is done, you would be better off
querying the database for Selection Name or querying a smartset. It's
true that the first one is only one NetView "system" call, while the
smartset query is two, and if your system is very busy, then that may
make a difference. If you filter the initial traps however, you may not
be able to see a difference, since the nvcorrd log only resolves to
second, and not to hundredth or thousands of a second.
What I am saying boils down to this. Start your ruleset with a trap
setting or an event attribute. Then do your query. You have three
choices.
(1) Query smartset
(2) Query database
(3) Build a file of hostnames and write a script to query it using grep
that you launch as an in-line action with a wait time of a second.
However you choose to do it, and for whatever reason you make your
choice, don't start your ruleset with that. Filter the traps you want
to examine first.
HTH,
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows Tivoli Software
/ IBM Software Group
"Glen Warn"
<Glen.Warn@pemcoc
orp.com>
To
Sent by: <nv-l@lists.us.ibm.com>
owner-nv-l@lists.
cc
us.ibm.com
Subject
RE: [nv-l] Ruleset problem with
04/21/2005 02:42 Netview 7.1.4 running RedHat Linu
x
PM AS 2.1
Please respond to
nv-l
Hi Bill,
Thanks for your reply. I was hoping to use the smartset because we
manage networks for several companies and I was looking forward to
highlighting the nodes I wanted to apply these rules to from a handful
of submaps and adding them to the smartset. Since the only criteria (I
think) that I want to distiniquish on is the hostname - should I stay
the course of the smartset?
Glen Warn
PEMCO Corporation Computer Services (PCCS) glen.warn@pemcocorp.com
206-628-5770
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]
On Behalf Of Evans, Bill
Sent: Thursday, April 21, 2005 10:35 AM
To: 'nv-l@lists.us.ibm.com'
Subject: RE: [nv-l] Ruleset problem with Netview 7.1.4 running RedHat
Linu x AS 2.1
Another suggestion even stronger than Paul's; If your SmartSet is fairly
simple and there's an alternative don't use it but use the alternative.
For example, you can query the database directly more cheaply than by
using the SmartSet in cases like "isRouter=True and
isSNMPSupported=False".
I've found a couple database calls or even offloading the check to a
shell script can be faster than SmartSet access.
Bill Evans
Tivoli NetView Support for DOE
301-903-0057
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]
On Behalf Of Paul
Sent: Thursday, April 21, 2005 7:12 AM
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] Ruleset problem with Netview 7.1.4 running RedHat
Linux AS 2.1
Glen,
As a general rule you do NOT want to make a query smartset your first
entry in any ruleset.
Query smartset is expensive, so you want to be sure you do it only on
the events you really need to check.
Filter by the event first, then go to a smartset and actions or
whatever:
-> Action - Send email
|
-> Node Down > Query Smartset \(slot 1)
EventStream- |->
Reset on Match > Pager > Action send email
-> Node Up > Query Smartset /(slot 2)
Also, make sure your smartset has the nodes in the there that you are
concerned about.
Running "nvUtil l <smartsetname>" should show you the members of that
smartset. Make sure the smartset is not blue on the map.
Paul
Glen Warn wrote:
Hi,
I'm trying to build a ruleset that looks something like this (see
below) I am not a seasoned ruleset builder so please keep that in
mind if you reply!
->
Action - Email (historical log of node Down trap)
->
->Node Down Trap ->
-> ->
Event Stream -> -> Reset on Match
-> Pager -> Action - Email (historical log of paged event)
-> ->
->Node Up Trap ->
This works just fine but has not event attribute filtering (like
source host). If I insert an Event Attribute #2 right after the Event
Stream or before the Pager - it works perfectly. Problem is, I want
to query a smartset because I have so many different hosts that need
this rule. When I do insert the Query Smartset (in either of the 2
positions described above) - the rule stops functioning. I am using
Object ID Source = 2 and using a smartset that includes the servers I
want to monitor.
Any thoughts?
Glen Warn
PEMCO Corporation Computer Services (PCCS) glen.warn@pemcocorp.com
<mailto:glen.warn@pemcocorp.com> 206-628-5770