|
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
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@us.ibm.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.
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
_______________________________________________ NV-L mailing list NV-L@lists.ca.ibm.com Unsubscribe:NV-L-leave@lists.ca.ibm.com http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to internal IBM'ers only) |
"Van
Order, Drew \(US - Hermitage\)" <dvanorder@deloitte.com>
