RE: [nv-l] Splitting up TEC integration by using TEC_ITSand anotherruleset for external traps in ESE.automation 7.1.4/7.1.5

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

Great info as always. Thank you!

---

From: James Shanks [mailto:jshanks@us.ibm.com]
Sent: Wednesday, November 29, 2006 2:53 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

"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?"

My two cents:

Efficiency, like performance, is relative. The method you outlined will work, and it's what I would call "the standard method" It puts all the trap selection burden on nvcorrd's shoulders, though that's the sort of thing he's supposed to do. Since your basic selection criteria are the enterprise OID and specific trap number, nvcorrd can do that really fast. The further selection by IP address, not so fast, but it should still be fast enough, and unless you go with Bill Evan's suggestion about using custom database fields, or create a list-type smartset, I don't see that you have a choice of how to whittle down the events by origin. Is the grep of a flat file in an in-line action quicker than a database query or a smartset query? We have no benchmarks at that level. Both involve nvcorrd pausing momentarily to wait for a response from another process, so they may be a wash. No one can say for certain, and your results might be unique to your system even then.

The same goes for Leslie's method of just putting an enterprise OID as the selection criteria in her ruleset and then configuring all the traps she doesn't want to be sent to TEC to "Log Only". That increases the overhead of daemon to daemon communication (nvcorrd sends more events than are strictly required to nvserverd) and it also requires nvserverd to format more events than otherwise required, only to toss them away, but it saves some internal nvcorrd processing (and ruleset programming time). Is what is saved internally in nvcorrd enough to outweigh the additional processing elsewhere? Probably not, but it would be hard to measure in any case. A lot will depend on how many vendor traps are being suppressed by being made "Log Only" and how frequently they occur. Her method is as good as any other as long as the system will support it.

Trial and error is the only method available here I'm afraid.

James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp

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)