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