You meant trapd.conf, didn't you? Not trapd.log.
Officially it is not recommended that you edit trapd.conf manually. The
two ways we recommend that you make changes to trapd.conf are by using the
trap.exe GUI or the addtrap command. We do explain how to read an entry in
the books, however, but I wouldn't be adding many new entries or changing
the order because some things are indeed positional.
trapd uses a best-fit algorithm to match traps. If 1.3.6.1.4.1.232.8
doesn't match, he'll drop the last octet and try 1.3.6.1.4.1.232 and if
that doesn't match he try 1.3.6.1.4.1, which will match and he'll know that
he doesn't have a defined entry. Play with the ordering and you could get
some unexpected results. Furthermore, there is no guarantee that any
re-ordering you did would be preserved in the next version. If you do a
migration, the migration utilities will only strive to make your new
trapd.conf workable, not necessarily human-readable.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
Michael D Schleif
<mds AT helices DOT org>
Sent by: To
owner-nv-l@lists. nv-l mailing list
us.ibm.com <nv-l AT lists.us.ibm DOT com>
cc
01/18/2006 01:33 Subject
PM [nv-l] trapd.log: Necessary
sequence of entries ???
Please respond to
nv-l AT lists.us DOT ibm
.com
NV v7.1.4 ; FP03 ; windows
Is there any necessary sequence / order for entries in trapd.log?
[1] For example, when trapd.log is automatically generated, following
occur in this sequence:
cpqSsFanStatusChange {1.3.6.1.4.1.232.8} 6 1 A 4 0
"LOGONLY" -
Storage System fan status changed to $1.
cpqSeCpuThresholdPassed {1.3.6.1.4.1.232} 6 1001 A 3 2
"LOGONLY" -
CPU internal corrected errors have passed a set threshold.
[2] For human readable reasons, I would order them this way:
cpqSeCpuThresholdPassed {1.3.6.1.4.1.232} 6 1001 A 3 2
"LOGONLY" -
CPU internal corrected errors have passed a set threshold.
cpqSsFanStatusChange {1.3.6.1.4.1.232.8} 6 1 A 4 0
"LOGONLY" -
Storage System fan status changed to $1.
Perhaps, the when trapd.log is parsed, there is NO _exact_ match on OID?
In other words, if the actual OID is 1.3.6.1.4.1.232.8 ; will scenario
[2] STOP parsing at 1.3.6.1.4.1.232 ?
What do you think?
--
Best Regards,
mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know. The more I know, the more I know I don't know . . .
--
(See attached file: signature.asc)
signature.asc
Description: Binary data
|
