nv-l
[Top] [All Lists]

Re: [nv-l] Traps not converting to variables

To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] Traps not converting to variables
From: James Shanks <jshanks@us.ibm.com>
Date: Mon, 4 Oct 2004 13:31:46 -0400
Cc: nv-l@lists.us.ibm.com, owner-nv-l@lists.us.ibm.com
Delivery-date: Mon, 04 Oct 2004 18:45:06 +0100
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
In-reply-to: <OF2AC22692.3FCD4926-ON85256F23.004BE254-85256F23.00570503@mead.com>
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com

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@meadwestvaco.com>
Sent by: owner-nv-l@lists.us.ibm.com

10/04/2004 11:50 AM
Please respond to
nv-l

To
nv-l@lists.us.ibm.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@MeadWestvaco.com.
_______________________________________________________________________

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web