RE: [TEC] snmp adapter problems

Hi Justin,

I sent all modules to the same file ... the trace below is from my single 
output file.  As luck would have it, I can't get to that particular box today 
to retrieve the entire logfile.  However, I can tell you that the conf file has 
no exclusions or other filters in it.  Here is the specific event definition 
from my cds file:

CLASS cpqDa6LogDrvStatusChange
  SELECT
    1: ATTR(=,$ENTERPRISE), VALUE(PREFIX, "1.3.6.1.4.1.232") ;
    2: $SPECIFIC = 3034 ;
    3: ATTR(=,"sysName") ;
    4: ATTR(=,"cpqHoTrapFlags") ;
    5: ATTR(=,"cpqDaCntlrHwLocation") ;
    6: ATTR(=,"cpqDaLogDrvCntlrIndex") ;
    7: ATTR(=,"cpqDaLogDrvIndex") ;
    8: ATTR(=,"cpqDaLogDrvStatus") ;
  MAP
    sysName = $V3 ;
    cpqHoTrapFlags = $V4 ;
    cpqDaCntlrHwLocation = $V5 ;
    cpqDaLogDrvCntlrIndex = $V6 ;
    cpqDaLogDrvIndex = $V7 ;
    cpqDaLogDrvStatus = $V8 ;
    msg = PRINTF("Logical Drive Status Change: Status is now %d.",$V8);
    severity = CRITICAL;
END


And here is the definition of this trap from the Compaq mib file:

    cpqDa6LogDrvStatusChange TRAP-TYPE
        ENTERPRISE compaq
        VARIABLES  { sysName, cpqHoTrapFlags, cpqDaCntlrHwLocation,
                     cpqDaLogDrvCntlrIndex, cpqDaLogDrvIndex,
                     cpqDaLogDrvStatus }
        DESCRIPTION
            "Logical Drive Status Change.

            This trap signifies that the agent has detected a change in the
            status of a drive array logical drive.  The variable
            cpqDaLogDrvStatus indicates the current logical drive status."

        --#TYPE "Logical Drive Status Change"
        --#SUMMARY "Status is now %d."
        --#ARGUMENTS {5}
        --#SEVERITY CRITICAL
        --#TIMEINDEX 99

        ::= 3034

I am no expert at snmp in general, nor the snmp adapter in specific, but it 
looks to me that my cds definition fits the mib definition properly. I am very 
unclear on what the .oid file does, though.  I can see that the oid file does 
not list the specific traps, but seems to be identifying the individual 
arguments of the traps ... e.g, 

"cpqDaCntlrHwLocation"          "1.3.6.1.4.1.232.3.2.2.1.1.20"
"cpqDaLogDrvCntlrIndex"         "1.3.6.1.4.1.232.3.2.3.1.1.1"
"cpqDaLogDrvIndex"              "1.3.6.1.4.1.232.3.2.3.1.1.2"
"cpqDaLogDrvStatus"             "1.3.6.1.4.1.232.3.2.3.1.1.4"


Can anyone tell me if the order of the entries in the oid file is important?  I 
found nothing in the adapters guide to help me here ... when I 
compiled/combined all the mibs into one and ran it through the mib2tec script, 
the oid file had a lot of duplicate entries, and they were in no particular 
order -- actually they were in order of the definitions by mib, but not in 
alphabetical or numerical order by arg name or oid value.  I manually edited 
that oid file to eliminate duplicate entries, and I reordered everything to be 
in oid order. These attributes are not in the same order as they appear in the 
event definition in either the cds or mib.


thx,

John Guadagnino
Gap Inc.


-----Original Message-----
From: owner-tme10@xxxxxxxxxxxxxxxx
[mailto:owner-tme10@xxxxxxxxxxxxxxxx]On Behalf Of
justin_eagleson@xxxxxxxxxxx
Sent: Tuesday, November 30, 2004 12:56 PM
To: tme10@xxxxxxxxxxxxxxxx
Subject: Re: [tme10] [TEC] snmp adapter problems


John:

I should have clarified below that in my experience it makes 
troubleshooting the adapter easier if tecad_snmp.err is setup to send the 
debug output for each module to a separate file (e.g. here I setup TECIO 
module to output to /tmp/snmp_tecio.log, DRVSPEC goes to 
/tmp/snmp_drvspec.log, etc.). Not sure if you were already doing that also 
or sending them all to the same file...

Regards,

Justin Eagleson
Enterprise Systems Management, JPMorganChase
office: 614-213-9017
pager: 877-864-2056
cell: 614-226-1148



Justin Eagleson

justin_eagleson@xxxxxxxxxxx
Sent by: owner-tme10@xxxxxxxxxxxxxxxx
11/30/2004 02:55 PM
Please respond to tme10
 
        To:     tme10@xxxxxxxxxxxxxxxx
        cc: 
        Subject:        Re: [tme10] [TEC] snmp adapter problems


Hi John. 

Can you post the DRVSPEC and TECIO debug (set these modules to output to a 

file in tecad_snmp.err if you haven't already), along with the 
corresponding .cds  and .conf definitions for cpqDa6LogDrvStatusChange? 

If it's making it into DRVSPEC, but not TECIO, then it could be 1) 
tecad_snmp.conf filtering has this Event Class filtered out or 2) there is 

a varbind defined in the SELECT in the .cds that is not being passed in 
the actual trap, which you can check by comparing DRVSPEC with the .cds 
definition and see what's different. 

There may be other scenarios I'm not thinking of right now, but that's a 
good place to start looking.

Regards,

Justin Eagleson
Enterprise Systems Management, JPMorganChase
office: 614-213-9017
pager: 877-864-2056
cell: 614-226-1148



Justin Eagleson

"John Guadagnino" <John_Guadagnino@xxxxxxx>
Sent by: owner-tme10@xxxxxxxxxxxxxxxx
11/30/2004 02:25 PM
Please respond to tme10
 
        To:     "Tme10list (E-mail)" <tme10@xxxxxxxxxxxxxxxx>
        cc: 
        Subject:        [tme10] [TEC] snmp adapter problems


fwk 411
tec 39
ep 41104
interp linux-ix86

I am trying to use the Tivoli SNMP adapter to pick up Insight Manager 
traps on some linux boxes.  I originally installed the HP-provided 
components (the OID & CDS files) but soon discovered that they were in 
fact missing a lot of traps that IM was throwing.  I had the IM admin here 

send me his mibs, and then I used the mib2tec script to convert them ... 
all told, his mibs contain about 1100 traps whereas the HP-provided IM 
definitions contained only about 700 traps.  We ran a test where an admin 
pulled a disk (broke the mirror) which generated a 3034 trap ... 
'cpqDa6LogDrvStatusChange' as defined in the MIBs.  But this trap did not 
generate a Tivoli Event.  I reviewed the CDS & OID files, and found that 
this trap is not defined in the HP-provided integration files.

Great.

So I merged all the mibs, ran it through mib2tec and manually edited the 
results as needed just to make it run, but it is not working properly. 
I've got every trap from the MIBs clearly defined in the CDS file, but the 

adapter still won't generate a Tivoli event when we test it.  Again, we 
pulled a disk, generated a 3034 trap, and it failed to process properly 
... here's my trace ( I set everything in the tecad_snmp.err file to write 

to a log):


 849852 Trying Class "cpqDa6LogDrvStatusChange"
 849853 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0067: Entered TECAD_EvalSelect
 849854  Name: TECAD_TYPE 1     11      "ENTERPRISE"    <--- testing for 
the 'enterprise' string of the received trap ...
 849855   Key: TECAD_TYPE 4     0       NULL
 849856 Value: TECAD_TYPE 1     15      "1.3.6.1.4.1.232"     <--- the 
value of the enterprise string, in this case the Compaq/HP enterprise 
string 
 849857
 849858 Wed Nov 24 10:45:54 2004 VERBOSE: KERNEL , err 00, 
cad/evaluation.c line 0094: TECAD_GetConstantEntry Index <976>
 849859 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0510: Enter TECAD_TestSelectValue 1 1 15 15 
775106097 775106097
 849860 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0513: Test_Value: 135105288
 849861 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0516: Value: 137766040
 849862 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0221: Correct is TRUE              <--- this says 
the trap matched our definition, so far so good
 849863  Name: TECAD_TYPE 1     8       "SPECIFIC"     <--- testing for 
the 'specific' trap type
 849864   Key: TECAD_TYPE 4     0       NULL
 849865 Value: TECAD_TYPE 2     4       "3034"     <--- the trap 
"specific" id is 3034 which matches the 'cpqDa6LogDrvStatusChange' trap as 

defined in the Compaq mib
 849866
 849867 Wed Nov 24 10:45:54 2004 VERBOSE: KERNEL , err 00, 
cad/evaluation.c line 0094: TECAD_GetConstantEntry Index <977>
 849868 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0510: Enter TECAD_TestSelectValue 2 2 4 4 3034 3034
 849869 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0513: Test_Value: 135105400
 849870 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0516: Value: 137765864
 849871 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0221: Correct is TRUE              <--- this says 
that the 'specific' trap id matched our definition, again this is good.
 849872 Wed Nov 24 10:45:54 2004 VERBOSE: KERNEL , err 00, 
cad/evaluation.c line 0094: TECAD_GetConstantEntry Index <978>
 849873  Name: TECAD_TYPE 1     7       "sysName"     <-- the sysName 
variable
 849874   Key: TECAD_TYPE 1     0       ""
 849875 Value: TECAD_TYPE 1     8       "tlrcc005"     <-- contains the 
hostname 
 849876
 849877 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0221: Correct is TRUE              <-- matches our 
definition
 849878 Wed Nov 24 10:45:54 2004 VERBOSE: KERNEL , err 00, 
cad/evaluation.c line 0094: TECAD_GetConstantEntry Index <979>
 849879  Name: TECAD_TYPE 1     14      "cpqHoTrapFlags"     <--- the 
cpqHoTrapFlags variable
 849880   Key: TECAD_TYPE 1     0       ""
 849881 Value: TECAD_TYPE 2     4       "0"                      <--- 
contains this value 
 849882
 849883 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0221: Correct is TRUE              <-- matches our 
definition
 849884 Wed Nov 24 10:45:54 2004 VERBOSE: KERNEL , err 00, 
cad/evaluation.c line 0094: TECAD_GetConstantEntry Index <980>
 849885 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0277: Finished TECAD_EvalSelect, returning FALSE 
<--- WHAT FAILED???? I have no idea why it failed at this point.



I cannot see anything to indicate why this trap failed ("returning FALSE" 
... line 849885) ... can anybody offer some hints or tips on how to debug 
this or otherwise figure out what is going on?


tia,

John Guadagnino
Gap Inc.