Great info as always. Thank you!
"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 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)
|