Thanks for your contribution to the Tivoli User Group website,
Wolfgang! Hopefully you will encourage others.
I know it's a bit more overhead, but if we all copy contributions to the
TUG site as well as to nv-l (especially when it is something a bit
bigger than is easily handled by nv-l), then we all win.
Here's the TUG TWiki home URL:
http://www.nv-l.org/twiki/bin/view/Netview/WebHome
Cheers,
Jane
wolfgang.bergbauer@attglobal.net wrote:
Hi James,
Awesome, this is the first time I think I understand this nvcorrd
behaviour, hopefully that stays like this, and thanks for the phrase
that I am still thinking like a human being - after all these long
hours with these stupid machines :-)
In regards to the rule, I have extended your suggestion and added a 6
minutes reset on match, which gives any nodes time to come up again
without sending any events to TEC.
I oultined this in a small slide and posted it on the Netview Web
page. Any comments for improvements are welcome. But what I can see
from my lab testing, it works like expected.
Link:
http://www.nv-l.org/twiki/bin/view/Netview/NetViewRule
Kind regards and thanks again to James,
Wolfgang
------------------------------------------------------------------
Wolfgang Bergbauer
Network and System Management Consultant
Cell phone: +49 172 534 9131
E-mail: wolfgang.bergbauer@attglobal.net
*James Shanks <jshanks@us.ibm.com>*
Sent by: owner-nv-l@lists.us.ibm.com
10/21/2004 12:06 AM
Please respond to
nv-l@lists.us.ibm.com
To
nv-l@lists.us.ibm.com
cc
Subject
Re: [nv-l] Netview Rule - corrected
When you have a ruleset problem, the thing to do is to turn on the
nvcorrd trace and see why what you expected to happen is not
happening. You do that with "nvcdebug -d all" and the results are
written to the nvcorrd.alog and blog. When a trap is received, you'll
see the eye-catcher "Received a trap" and when nvcorrd is finished
with it, you'll see "Finished with the trap", Everything that happens
in between is the processing nvcorrd did on it.
That said, I think I already know what you are going to find. You are
looking at the ruleset as a human being would, as a purely logical
construct, not as a computer algorithm which executes in real time.
The problem is that when the Reset-on-Match releases the held Node
Down, nvcorrd immediately proceeds to the next node for it, the
Pass-on-Match. But there is nothing for it to match because the Node
Up event, which triggered the Reset, has not yet been stored in the
cache for the Pass-on-Match. That processing will come after the Node
Down is released. In short, this is a timing issue.
So what can you do? You have to insert another step between the Reset
and the Pass, one that gives nvcorrd time to finish processing the
Node Down, for now, so that he can go back and store the Node Up. I'm
indebted to my colleague, Paul Stroud, for one workable solution,
which he was the first to think of. Insert another Reset-on-Match
after the first one and connect the Node Down as Input One. Set the
interval for anywhere from 30 seconds to a minute. And connect the
output to the Pass-on-Match as Input One for it. The trick is to have
nothing connected to that second Reset-On-Match as Input Two. That way
the Node Down event will just be held for the interval and then
released. Once the Node Down is stored in the cache for the second
Reset, processing for it ceases, and nvcorrd can then go back to the
Node Up and store it in the Pass.
The only catch to this is that the triggering Node Up is sent to TEC
about a minute later than the Node Down, but that should not matter
much to your TEC rules, since they can evaluate what's already in the
reception store as well as the current event.
Incidentally, that's why the IBM direction was to do this kind of
correlation in TEC, where timing issues were not as relevant.
Hope this helps
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
--
Tivoli Certified Consultant & Instructor
Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
Tel: +44 (0)1628 782565
Copyright (c) 2004 Jane Curry <jane.curry@skills-1st.co.uk>. All rights
reserved.
|