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

["Van Order, Drew \(US - Hermitage\)" <dvanorder@deloitte.com>]

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.

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@deloitte.com>

"Van Order, Drew \(US - Hermitage\)" <dvanorder@deloitte.com>
Sent by: nv-l-bounces@lists.ca.ibm.com

11/27/2006 11:44 AM

Please respond to
Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>

To	"Tivoli NetView Discussions" <nv-l@lists.ca.ibm.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

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

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