Thanks Leslie!
________________________________
From: Leslie Clark [mailto:lclark AT us.ibm DOT com]
Sent: Wednesday, November 29, 2006 4:13 PM
To: Tivoli NetView Discussions
Subject: RE: [nv-l] Splitting up TEC integration by using TEC_ITSand
anotherruleset for external traps in ESE.automation 7.1.4/7.1.5
Well, about the part you asked about..
I prefer to specify the Enterprise in the Event Attributes cube rather
than select all traps in the Trap Settings cube. This means it only has
to do one comparison (does Enterprise = "1.3.6.1.4.1.9.1.23") instead of
comparing enterprise, and who knows how many specific trapids. If I do
that, I have the added advantage of turning individual traps off and on
(for all nodes) at the xnmtrap interface, with the logonly option,
rather than in the ruleset, which would require a stop/start of event
flow to the tec to put into effect.
Now for the special case where you want a certain trap, but not for node
ABC.com:
Include the enterprise in the TEC_ITS.rs
Enable the trap in xnmtrap by setting the category to 'Status Events' or
whatever it should be - just not Log Only.
In the Ruleset, after the Event Attributes cube for that enterprise:
- Add a Trap Settings for that one trap, NOT equal, and then
Forward
-Add a Trap Settings for that one trap, IS equal, then check for
the one they don't want, if false, then Forward.
That last part gets tricky. You might want to do a hard-coded comparison
using an Event Attribute cube, or you might want to do an Inline Action
doing a grep of the $NVA from a list.
Clearly this is more worthwhile for Enterprises with large numbers of
traps.
Cordially,
Leslie A. Clark
IT Services Specialist, Network Mgmt
Information Technology Services Americas
IBM Global Services
(248) 552-4968 Voicemail, Fax, Pager
"Van Order, Drew \(US - Hermitage\)" <dvanorder AT deloitte DOT com>
Sent by: nv-l-bounces AT lists.ca.ibm DOT com
11/29/2006 03:04 PM
Please respond to
Tivoli NetView Discussions <nv-l AT lists.ca.ibm DOT com>
To
"Tivoli NetView Discussions" <nv-l AT lists.ca.ibm DOT com>
cc
Subject
RE: [nv-l] Splitting up TEC integration by using TEC_ITS and
anotherruleset for external traps in ESE.automation 7.1.4/7.1.5
Looks like this message never made it out Monday afternoon.
________________________________
From: Van Order, Drew (US - Hermitage)
Sent: Monday, November 27, 2006 1:54 PM
To: 'Tivoli NetView Discussions'
Subject: RE: [nv-l] Splitting up TEC integration by using TEC_ITS and
anotherruleset for external traps in ESE.automation 7.1.4/7.1.5
Wow, great responses, everyone. Thank you so much.
James, you asked the right question, and the answer is reassurance.
You're talking to the guy responsible for level 3 support and
customization of NetView, TEC, NetIQ AppManager, and a few other systems
management applications that feed TEC. As such, I have really wide
experience, but am master of nothing, especially clever PROLOG rule
writing. But I digress.
Our database is fairly small, about 16,000 objects. When we have a
network outage, netview.rls can really kill tec_rule, and we're using
settings not far off the defaults. I'm also wary of the potential
bottlenecks NetView can have in trap processing beyond trapd. I would
like nothing better than to keep it all in TEC_ITS, and Leslie, sounds
like I've been on the right track by doing much of what you wrote. So
TEC_ITS it will remain until I see a real breakdown in performance.
Maybe by then we'll spend the $$ on Precision/IP and Omnibus.
If I may, Leslie, could you expound a little on your quote below,
because it is the most common request I'm getting: 'I want all the
Peribit traps forwarded to TEC, except for the Peribit License Exceeded
trap, can you only forward that if it comes from IP addresses X,Y,Z?'
For each MIB with traps, add to TEC_ITS.rs an Event Attribute cube
specifying the Enterprise, with a Forward.
In the odd case where you need to filter one of those traps by device,
add an additional Trap Settings for the specific trap, and do an inline
action that greps a flat file
Right now I would use a trap settings node with all the underlying traps
highlighted except the License Exceeded trap. That connects to a Forward
node. I would then add another trap settings node with just the License
Exceeded trap highlighted, then add processing nodes to that before
forwarding. Is this inefficient?
Thanks again everyone. I wish I could pay you back somehow by sharing
the expertise I have in other applications.
________________________________
From: James Shanks [mailto:jshanks AT us.ibm DOT com]
Sent: Monday, November 27, 2006 12:58 PM
To: Tivoli NetView Discussions
Subject: Re: [nv-l] Splitting up TEC integration by using TEC_ITS and
anotherruleset for external traps in ESE.automation 7.1.4/7.1.5
You certainly can do this, using postemsg in an action node, but it is
definitely a roll-your-own sort of thing Some people have tried this,
with varying degrees of success. If you try it, make certain that you
specify a different BufEvtPath for your postemsg, so the two adapters
don't step on each other. Otherwise they will try to share the same
event cache, with disastrous results. TEC never imagined multiple
adapters on the same host when it was first conceived.
That said, think about what are you after here, Drew. Reassurance? Are
you having a performance problem or just worrying about one? Until you
start having one, and are seeing delayed events in your event windows or
slowdowns in your events going to TEC, I'd say that your NetView ruleset
is working just fine as a TEC adapter. You need not worry about how many
entry points the rule has nor how hard it is to display in the editor,
because it is just a matrix to nvcorrd. If he can load it, he will
process it as written. You'd gain nothing if there were multiple TEC
rules, except that they would be easier to bring up in the editor. And
in fact, multiple rules for TEC would introduce other issues that would
be harder to solve.
Remember that event processing here is cooperative. First it is spread
between nvcorrd and nvserverd. TEC is just another event destination,
another event window if you will. nvserverd registers the rule. He
doesn't know how it works. nvcorrd processes the events and sends back
to nvserverd the events which pass that rule; it's just an elaborate
event filter. What nvserverd does then is format the event according to
the requirements of who it's for, one way for event windows, another for
TEC, but he doe not care what the event is. He simply sends what nvcorrd
tells him too, unless it is marked "Log Only" in trapd.conf. So what
might happen if we had multiple rules going to TEC? Suppose one rule
said "send this event" and the other said "don't send it"? What about
timing issues? At some point we'd still have to say, you'll have to
handle this complexity over in TEC. And that's just where we are now
with one rule.
Which brings us to the second level of cooperation in the event
architecture. In the Tivoli architecture, most it not all, of the match
processing is supposed to occur in TEC, where events can be processed,
and reprocessed, in light of new ones. In TEC architecture initially,
the adapters were simply supposed to whittle down the vast stream of
events and send only likely candidates. In fact, until the advent of the
SCE engine, not much else was possible. But given all the bugs in that
java beast, I'd steer clear of it, though there are other customers
using it to do their own processing. You're on your own with that from
NetView's point-of-view because it is entirely TEC's baby. NetView uses
it, but does not formally support customer modifications to the rules we
ship. If you want to run your own, we suggest you run 'em on a TEC
gateway, and leave the NetView stuff alone.
I guess the point I am trying to make here is that I believe that
allowing multiple TEC rulesets would only make things worse instead of
better. TEC is supposed to be the ultimate correlator of events, because
he can get them from multiple sources, not just SNMP traps. Are you
getting these requests for complex NetView rules because there isn't
anyone with deep enough TEC skills to do the matching they require over
there? I ask that because I'd like to observe that given the correlation
capabilities in nvcorrd, the internal NetView adapter already does more
filtering and matching than what the previous NetView adapter provided
by TEC could do. One need only look at it's twin, the current OpenView
adapter, to see that.
I hope you find a suitable solution to your current problems, because
really, this thing has been optimized as much as it can given the
current design, and that's not about to change given that the last
version of NetView has already shipped.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp
"Van Order, Drew \(US - Hermitage\)" <dvanorder AT deloitte DOT com>
"Van Order, Drew \(US - Hermitage\)" <dvanorder AT deloitte DOT com>
Sent by: nv-l-bounces AT lists.ca.ibm DOT com
11/27/2006 11:44 AM
Please respond to
Tivoli NetView Discussions <nv-l AT lists.ca.ibm DOT com>
To
"Tivoli NetView Discussions" <nv-l AT lists.ca.ibm DOT com>
cc
Subject
[nv-l] Splitting up TEC integration by using TEC_ITS and another ruleset
for external traps in ESE.automation 7.1.4/7.1.5
Anyone doing this successfully? I ask because TEC_ITS.rs is now unwieldy
with both internal and external trap processing. We are also getting
requests to perform additional filtering/processing on external traps
prior to forwarding to TEC. It spooks me to think of doing this all in
TEC_ITS. I thought a solution could be having a ruleset in
ESE.automation that handles all external traps/processing. The
forwarding to TEC would be handled by an Action node that fires a script
invoking postemsg, or running postemsg directly and passing trap
variables.
Alas, it appears that none of the TEC slot mappings are passed as
variables to an action node. Nor are they passed to the environment if
you run an automatic action in trapd.conf. I searched the list archives
before posting this, good chance someone has already asked this same
question. Too bad nvserverd can't work with more than one ruleset; that
would be the ideal situation.
Thanks--
Drew Van Order
Information Technology Services
Deloitte Services LP
Tel: +1 615 882 7836
www.deloitte.com <file://www.deloitte.com/>
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and is
protected by law. If you are not the intended recipient, you should
delete this message.
Any disclosure, copying, or distribution of this message, or the taking
of any action based on it, is strictly prohibited.
[v.E.1]_______________________________________________
NV-L mailing list
NV-L AT lists.ca.ibm DOT com
Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com
http://lists.ca.ibm.com/mailman/listinfo/nv-l
<http://lists.ca.ibm.com/mailman/listinfo/nv-l> (Browser access limited
to internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L AT lists.ca.ibm DOT com
Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L AT lists.ca.ibm DOT com
Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
|
