Re: [nv-l] Traps not converting to variables
2004-10-04 18:03:18
I sent them the mib and the mib2trap
and my trapd.conf file. I think youa re right though in that they
are probably receiving exactly what I am. The integer value. I
will try the oid_to_label and see what happens. That or the action
node script.
I want the message to get to TEC as
plain as possible. I haev other messages that say $2 where (crossedover(1),
noChange(2). But I would rather make it simple in the message saying
spSensor returned to NORMAL status with actual value of $2.
Thanks
Chris Petrina
| James Shanks
<jshanks AT us.ibm DOT com>
Sent by: owner-nv-l AT lists.us.ibm DOT com
10/04/2004 01:31 PM
Please respond to
nv-l AT lists.us.ibm DOT com |
|
To
| nv-l AT lists.us.ibm DOT com
|
cc
| nv-l AT lists.us.ibm DOT com,
owner-nv-l AT lists.us.ibm DOT com
|
Subject
| Re: [nv-l]
Traps not converting to variables |
|
Well, I don't know about your PMR but since this trap also contains some
variables which are textual strings, perhaps Level 2 does not follow what
you are saying. Have you sent them this exact example and explanation?
I'll bet not, so I'll bet Level 2 is confused about what you are
expecting to see.
But I can tell you for certain that trapd will not resolve that enumeration
on his own.
In my opinion, if you are already sending this event to TEC in a TEC ruleset
which is passing the log message as "msg", then the easiest thing
to do, as I said earlier, is to change the log message.
>From this,
$E $G $S $# args: $*
(which is the default)
to something like this
$E $5 from $6 indicates an spSensorStatus
value of $1, where noStatus(1), normal(2),
highWarning(3),
highCritical(4), lowWarning(5),
lowCritical(6), sensorError(7). because
the sensor level of $3 was exceeded; with an actual value of $2.
If you really need all the variables laid out as before, then you can shorten
that message and just add $* like before. Or change it however
else you like.
I haven't tried it, but you could also experiment with the oid_to_label
file and see whether it can be made to provide the substitution you wanted
originally, so that the tarp message might be shorter. I am not
certain, but think that nvserverd will get the same result as trapd does
when he calls the trap formatting routine if the oid_to_lable file defines
the correct enumeration. But I like the full enumeration message
myself because it gives the operator a hint as to what the range of values
is that we are talking about and what else to expect from this agent.
The inline ruleset and postzmsg would work, but it's a very bad idea, since
you should never do a command which might not complete immediately in an
inline action, lest you hang nvcorrd. Everything else would halt
while that inline executes. An action node script would be a much
better idea if that's what you prefer.
As an aside, you have to wonder why the vendor chose to send the integer
value in the trap in the first place, since he's already sending additional
text in the same trap. It would have been child's play to have sent
the text value in the trap instead of the integer value since they are
already sending text. Look like it would only make the trap about
10 bytes longer at most.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
"Christopher J Petrina"
<cjp8 AT meadwestvaco DOT com>
Sent by: owner-nv-l AT lists.us.ibm DOT com
10/04/2004 11:50 AM
|
To
| nv-l AT lists.us.ibm DOT com
|
cc
|
|
Subject
| Re: [nv-l] Traps not converting
to variables |
|
Currently I ahve a PMR open about this issue. I sent Level 2 the
mib the mib2trap trap file and my trapd.conf. It seems that I get
conflicting responses from them and here. They are saying it works
fine on their systems. They are receiving the textual equivalent
of the enum value. Below is a short description of one of the traps
that I am seeing doing this.
This is what the event looks like in the event window:
Thu Sep 30 14:53:07 2004 10.40.137.254 A sensorProbe 6 10 6 args:
[1] akcp.sensorProbe.sensorProbeTraps.spSensorStatus.0 (Integer):
5
[2] akcp.sensorProbe.sensorProbeTraps.spSensorValue.0 (Integer): 75
[3] sensorProbeTraps.spSensorLevelExceeded.0 (Integer): 75
[4] akcp.sensorProbe.sensorProbeTraps.spSensorIndex.0 (Integer): 0
[5] akcp.sensorProbe.sensorProbeTraps.spSensorName.0 (OctetString): Temperature1
[6] sensorProbe.sensorProbeTraps.spSensorDescription.0 (OctetString): Test
Temp in Trudi's Lab
2 - 6 are fine since the data they show are actual numeric values. It
is the $1 arg of 5 that I would have expected to see be a textual name
of sensorStatus a value of 1 - 5. in the trapd.conf it looks like
this:
spTemperatureStatus {1.3.6.1.4.1.3854.1} 6 10 A 1 0 "Status Events"
$E $G $S $# args: $*
EVENT_CLASS hhmsTemperatureStatus
SDESC
Temperature sensor trap
EDESC
-----------------------------------------------------------------------------------------------------------------------
The mib shows this:
spTemperatureStatus TRAP-TYPE
ENTERPRISE sensorProbe
VARIABLES
{ spSensorStatus, spSensorValue, spSensorLevelExceeded,
spSensorIndex, spSensorName, spSensorDescription
}
DESCRIPTION
"Temperature sensor trap"
::= 10
-----------------------------------------------------------------------------------------------------------------------
When it uses variables
spSensorStatus OBJECT-TYPE
SYNTAX INTEGER {
noStatus(1),
normal(2),
highWarning(3),
highCritical(4),
lowWarning(5),
lowCritical(6),
sensorError(7)
I figured that it would display the varaible name versus the actual integer.
If the integer is the correct value and that is all I am going to receive
what is the easiest way in anyones opinion to replace the integer with
a name. Would something like an inline action help? write
a script that receives the information then do some if then statements
to post it forward onto TEC via postzmsg?
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service._______________________________________________________________
This electronic message contains information from MeadWestvaco
Corporation or subsidiary companies, which may be confidential,
privileged or otherwise protected from disclosure. The
information is intended to be used solely by the recipient(s)
named. If you are not an intended recipient, be aware that
any review, disclosure, copying, distribution or use of this
transmission or its contents is prohibited. If you have
received this transmission in error, please notify MeadWestvaco
immediately at postmaster AT MeadWestvaco DOT com.
_______________________________________________________________________
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service._______________________________________________________________
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service._______________________________________________________________
This electronic message contains information from MeadWestvaco
Corporation or subsidiary companies, which may be confidential,
privileged or otherwise protected from disclosure. The
information is intended to be used solely by the recipient(s)
named. If you are not an intended recipient, be aware that
any review, disclosure, copying, distribution or use of this
transmission or its contents is prohibited. If you have
received this transmission in error, please notify MeadWestvaco
immediately at postmaster AT MeadWestvaco DOT com.
_______________________________________________________________________
|
|
|