cancel
Showing results for 
Search instead for 
Did you mean: 

SNMP Traps Out Variables

06 Trekker

SNMP Traps Out Variables

We currently utilize the SNMP traps out functionality in Prognois as a message destination for many of our configured alert thresholds.  These Prognosis SNMPT trap out events are then sent to another solution ours that centralizes trap event from all our various monitoring tools.  One of the challenges we have faced with the Prognosis trap events is that there doesn't appear specific variable within the Prognosis ptrapmib mib that includes the ip address of the device that triggered the threshold alert.  I have seen on occassion whereas the threshold record includes a data definition for the device ip address that can then be selected to include as an optional variable, but this is not always the case for all records. 

 

Is there anything I'm missing or way to always include the ip address in fixed variable within the SNMP trap out for the Prognosis monitored device that triggered the threshold event?

8 REPLIES 8
Highlighted

Re: SNMP Traps Out Variables

Hello Timmon,

 

It depends on the record you are using in your threshold. If the record contains a field which includes the ip address of the device, you could include that field as per the documentation here:

 

Windows, Unix, Linux:

Home > Prognosis for Infrastructure > Prognosis for Distributed Systems > Framework Connector > SNMP Traps Out > Including Field Values

 

Nonstop:

Home > Prognosis for Infrastructure > Prognosis for HP NonStop > Enterprise Manager > SNMP Traps Out > Including Field Values

 

HTH,

 

-Matthew

06 Trekker

Re: SNMP Traps Out Variables

Hi Matthew,

Thanks for the response and info.  I am aware of the ability to add the ip address to the trap as an additional variable if it is an avaialble data field within the record.  Unfortunately, I often run across records that we are thresholding on that don't include the ip address as a data field.  We're relying on the ip address of the monitored device that tripped the alarm to be included in the trap event so that that it can be routed properly when it is received by a centralized solution we utilize for traps coming from our different tools.  Many of these tools include the device ip address as a standard variable within their MIB which is why we went that route in the tool where we aggreate all incoming traps in.  

 

With Prognosis, this will certainly work with the threshold records that do contain the device ip address which can be added as an additional variable in the trap.  Unfortunately, it just doesn't with those that don't.  Figured that was going to be the case, but wanted to confirm I wasn't missing an opportunity to catch the device ip address for all traps we are sending out of Prognosis.  

 

Again, thanks for the response.

Tim

Tags (1)
Community Manager

Re: SNMP Traps Out Variables

Alert Blueprints that can add info from other records into an SNMP alert destination, details here. 

Help > System Functions > Thresholds > Special Features > Alert Blueprints > Alert Blueprints

 

Which records do you have in mind for the alert and for the IP address?

 

HTH

06 Trekker

Re: SNMP Traps Out Variables

Hi Gerald, 

We currently trap out on a large number of thresholds (both out of box and custom created on our end) and each one of those would need to contain the ip address in a variable that was standard across all traps out.  That variable within the SNMP trap would need to be standard across all traps so the receiving side knows which variable to parse for the ip address so the trap could be routed to report under the correct corresponding device.  That variable would also only be able to contain the ip address and nothing else.  I don't have a lot of experience with the alert blueprints as of right now, but will certainly research them more in the vendor documentation to see if this might offer a potential solution.

 

Thanks,

Tim

 

Community Manager

Re: SNMP Traps Out Variables

Hi Tim,

No worries. If you can give me some examples of record and field that thresholds are alerting on then I can test it here and provide you an idea of what the resulting SNMP Trap alert should look like.

Cheers,

Gerald

06 Trekker

Re: SNMP Traps Out Variables

Hi Gerald,

Below are a couple examples of records we are thresholding on that do not contain a field for the ip address of the monitored device:

 

Record:

CallManagerApplianceCallManagerSummaryStatus1

Where Clause: 

NREGPHI > 100 OR NREGPHI< -100

Event Text:

^srcnode@ : Change in the number of registered phones: @CMASUM1.NREGPHI@. (^srcnode@)

 

Record: 

CallManagerApplianceProcessor

Where Clause: 

INSTNAME CONTAINS "ccmAgt"

Event Text:

^srcnode@: A CUCM service is down -the ccmAgt process is not running.

 

Record:

CallmanagerApplianceProcessor

Where Clause:

INSTNAME CONTAINS "Total" AND CPUUSE > 90

Event Text:

^srcnode@: The CPU is too busy - @CMACPU.CPUUSE@ %. (^srcnode@)

 

I believe the above contains the record/field info you were after examples of, but let me know if otherwise.  Thanks for taking a look.

 

Tim

 

 

Community Manager

Re: SNMP Traps Out Variables

Great. I can confirm that using Alert Blueprint these records you have specified can be paired with the PrognosisNode record to provide the IP address of the call manager server in the alert for email alerts. Next I'll provide details of how that should look in SNMP Trap alerts.
Community Manager

Re: SNMP Traps Out Variables

Here we go. This is what it should look like when an alert blueprint is set up - SNMP Trap alert with extra field from another record (IP address of the call manager).

HTH

Prognosis-SNMP-Trap-with-Alert-Blueprint-extra-field-IP-address.png

 

Source: 10.113.1.135 Timestamp: 55 seconds SNMP Version: 1
Enterprise: .1.3.6.1.4.1.6102 Community: public
Specific: 12
Generic: enterpriseSpecific
Variable Bindings:

Name: .1.3.6.1.4.1.6102.1.1
Value: [OctetString] PROGNOSIS

Name: .1.3.6.1.4.1.6102.1.2.2
Value: [Integer] 3

Name: .1.3.6.1.4.1.6102.1.2.3
Value: [Integer] 100001

Name: .1.3.6.1.4.1.6102.1.2.4
Value: [OctetString] CMASUM1.NREGPHI

Name: .1.3.6.1.4.1.6102.1.2.1
Value: [OctetString] \CUCM12GC:CUCM12PUB : Change in the number of registered phones: 0. (\CUCM12GC:CUCM12PUB)

Name: .1.3.6.1.4.1.6102.1.2.5
Value: [OctetString] \CUCM12GC:CUCM12PUB

Name: .1.3.6.1.4.1.6102.1.2.27
Value: [OctetString] G

Name: .1.3.6.1.4.1.6102.1.2.26
Value: [OctetString] TcpIpAddress 10.102.12.1

Name: .1.3.6.1.4.1.6102.1.2.28
Value: [OctetString]

Name: .1.3.6.1.4.1.6102.1.2.29
Value: [OctetString]

Name: .1.3.6.1.4.1.6102.1.2.30
Value: [OctetString]

Name: .1.3.6.1.4.1.6102.1.2.31
Value: [OctetString]

Description:
Webinar: The Journey to Microsoft Teams - Readiness Phase (part 2)

Having looked at the planning phase in session one of this series, we will turn our focus to the readiness phase. The all important technical capabilities assessment, ensuring the network, endpoints and users are adequately prepared for the move.

Hear first hand from IR's Global Head of Information Systems and Technology, Jason Schwendinger, on how he has been tackling these issues.

Join webinar