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?
Solved! Go to Solution.
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:
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.
Alert Blueprints that can add info from other records into an SNMP alert destination, details here.
Which records do you have in mind for the alert and for the IP address?
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.
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.
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:
NREGPHI > 100 OR NREGPHI< -100
^srcnode@ : Change in the number of registered phones: @CMASUM1.NREGPHI@. (^srcnode@)
INSTNAME CONTAINS "ccmAgt"
^srcnode@: A CUCM service is down -the ccmAgt process is not running.
INSTNAME CONTAINS "Total" AND CPUUSE > 90
^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.
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).
|Source:||10.113.1.135||Timestamp:||55 seconds||SNMP Version:||1|
|Value:||[OctetString] \CUCM12GC:CUCM12PUB : Change in the number of registered phones: 0. (\CUCM12GC:CUCM12PUB)|
|Value:||[OctetString] TcpIpAddress 10.102.12.1|
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