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