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
>
|