Hi Paul,
Yes, the nodes in question (around 50 of them) are all green in the
smart set. I've created another ruleset that is simpler to test with
and it works. It looks like this:
EVENT STREAM -> NODE DOWN TRAP -> QUERY SMARTSET -> ACTION(EMAIL SCRIPT)
If I use the same smartset in this ruleset it works fine. Only when I
introduce the RESET ON MATCH complexity does it seem to break.
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 Paul
Sent: Friday, April 22, 2005 3:25 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
Glen,
Since you are using a NetView trap, yes, the 2nd attribute should
contain the failing node name. Are you sure these are members of your
smartset and that the smartset is NOT blue on the map?
Paul
Glen Warn wrote:
>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
>>
>>
>>
>
>
>
>
>
>
>
>
>
>
>
>
|