Archive

Posts Tagged ‘SNMP’

SNMP Traps from IBM Tivoli Monitoring (ITM)

May 10, 2012 1 comment

You can configure IBM Tivoli Monitoring (ITM) to send SNMP trap data to an SNMP receiver application such as HP open View when ITM monitoring situations become true. This article describes how to do that for the OMEGAMON XE monitoring agents that run in a z/OS environment.

The situations you want to send as SNMP traps for each agent are defined in an xxTRAPS configuration member in one of the PDS data sets allocated to the RKANDATV DD in the agent address space. xx is typically, but not always, the same as the agent product code. For example for CICS (product code CP) the SNMP configuration member would be called CPTRAPS. But for DB2 (product code DP), the member is called D5TRAPS.

The easiest way to find out which xxTRAPS members the agents in a TEMS or TEMA address space wants to use is to to browse the output of the RKLVLOG DD in the TEMS or TEMA and look for the string “TRAPS.RKAN”.

Typically it will look something like this:

*INFO: Local SNMP Trap configuration file name <M5TRAPS.RKANDATV> in effect

You can see that in this example it is looking for the M5TRAPS member (for the z/OS agent).

If the xxTRAPS member does not exist then typically you will see the following sort of message in the RKLVLOG:

KRAX005I, Unable to open XML definition file: M5TRAPS.RKANDATV, reason: ENOSYS, Producer(XML Parser)

Followed by:

KRAS022I, SNMP trap configuration definition failed. Agent trap emitter feature disabled, Producer(SNMPTrap Emitter)

When the trap definition member for an agent is found you should see something like this:

KRAS023I, SNMP trap configuration successful. 1 SNMP trap destinations and 4 situations defined, Producer(SNMPTrap Emitter)

The xxTRAPS Member

This is a sample xxTRAPS member, in this case for a CICS agent, so the member name would be CPTRAPS:

<SNMP>

<TrapDest
name=”SOMENAME”
stat=”N”
Address=”snmp.trapreceiver.some.domain”
Version=”v2″
/>

<Situation name=”CICS_Storage_Violation” target=”SOMENAME” />
<Situation name=”CICS_SOS” target=”SOMENAME” />

</SNMP>

The TrapDest entry tells the emitter where to send the SNMP traps to. ‘name’ is just an arbitrary name used to connect the situation entries to a destination. You can have more than one TrapDest entry and thus send SNMP trap data for different situations to different target destinations.

Stat=”N” simply tells the emitter NOT to send EE_ (life cycle status events) trap data to the target. EE_ traps record events such as heartbeat data used by the ITM infrastructure.

Each ‘Situation’ entry defines the name of one monitoring situation for this agent that is to be sent as an SNMP trap to the target destination indicated by the named TrapDest entry.

Note.

You should only define situation names for the target agent in each xxTRAPS member. What that really means is that you should only specify the names of situations that run against say, CICS attribute groups, in the CPTRAPS member and only situations that run against the DB2 agent in the D5TRAPS member etc.

While there is nothing stopping you from putting the names of say DB2 situations into the CPTRAPS member, they will simply be ignored because those situations will never be run by the CICS agent.

Tracing

You can trace the creation of the trap definition in some detail by tracing the kraaestx module in the TEMS or TEMA.

Add the following to the KDSENV member in the RKANPAR concatenation:

KBB_RAS1=ERROR (UNIT:kraaestx ST ERR)

In the RKLVLOG you will see something like this:

    BindAddress – 1.2.3.4
Type – TRAP
Version – V2
IP   – IPv4
Stat – NO
SNMP Trap Situation Entry:
Name – CICS_SOS
Severity – <2> Warning
Category – <0> Threshold_Events
Mode     – RC
Interval – 15
SendPred – Yes
Target – SOMENAME
Table: – “NULL”
TrapAttrList: – “NULL”

etc…

Advertisements
Categories: Mainframe Tags: , ,