Thanks Dave, I will give you a call. Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.mar...@cms.hhs.gov WFH Tuesdays and Fridays
-----Original Message----- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Tuesday, November 10, 2009 4:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending an SNMPTRAP alert from Velocity to NETCOOL/OMNIBUS console On 10/23/09 4:35 PM, "Martin, Terry R. (CMS/CTR) (CTR)" <terry.mar...@cms.hhs.gov> wrote: > I am trying to send an ALERT captured in Velocity ESAMON over to our > NETCOOL/OMNIBUS console. I have the Velocity piece set up and we can see that > the ALERT gets to the OMNIBUS console. See logs below. However nothing is > being done with it because the OMNIBUS guy tells me that there needs to be a > SNMP TRAP PROBE RULE defined. > > What should this rule look like on the OMNIBUS side to pick up my ALERT and > have an email sent out based on the alert? Omnibus first needs to know what the formal definition of the alert payload is. There should be a ASN.1 MIB file supplied with ESAMON that contains these definitions. If there isn't a file like that, bug them until they provide one. You take that file, copy it to the Omnibus machine, and compile it into an internal representation using the Omnibus MIB compiler utility. There's a section in the Omnibus manual on how to incorporate new MIBs; same process as dealing with a new kind of switch or router. You then define an action in Omnibus to tell Omnibus what to do when it receives that alert. The compiled MIB tells Omnibus how to parse the SNMP trap payload, and those values will be made available to the probe rule processing engine as variables $1, $2, etc. You write a script that takes those variables and does whatever you want with them (eg, generates an email in your case). Your Omnibus admin then associates your script with the alert name, and you're done. I think one of the predefined Omnibus actions would work, but you may want to put some explanatory text around the values or do a little cherry-picking on what you report, so you might want a custom script to do the email generation. (BTW, this is not unique to Omnibus. All SNMP managers work pretty much the same way. The same process will work with Netview or HP Openview or any common SNMP management software). > I am also a little confused between a MIB and an OID in some of the > documentation I read they seem to be used interchangeable. A MIB is a collection of formal definitions of alerts and variables that can be queried or set, each identified by an OID. In Z terms, you can think of it as similar to a message repository: the OID is equivalent to the message ID (HCPnnnnS), and the rest of the MIB is the structure and formatting of the message payload, eg what parameters to expect and what the order, formatting and type of those parameters should be. > 10/15/09 14:37:21: Debug: <<<<< (snmptrap.rules) Enterprise ID not found, > checking ncotdc include files. >>>>> These messages tell you that Omnibus does not know how to interpret the alert. You need to incorporate the MIB for ESAMON into Omnibus. Then you can define a rule -- right now, it's falling through to the "generic" one used when it doesn't know what else to do. Call me on the phone if you want and I'll explain further. -- db
