Attempting to create and test new Alert Blueprints for first time. Alert blueprints are currently enabled and working as the out of box ones come through fine. However, when I attempt to create a new alert blueprint linked to a record I have a threshold built against, the triggered alert does not contain the blueprint info, only what is configured via the threshold in the hard client.
I have also tried making a simply modification to an existing out of box alert blueprint (CiscoServerCpuUsage for example), but while the alert contains the blueprint, it doesn't relflect the modification I made (something as simple as changing the text of the event header). Aside from simply saving my alert blueprint creations or changes, is there anything else that needs to be done to apply (bounce a configuration, etc.)?
Thanks!
Hi Timon,
Yes. there is one more manual step added into the documentation:
https://help.prognosis.com/prognosis/116/creating-alert-blueprints-23463178.html
Step 12. These changes are saved into:
C:\Prognosis\WebUI\IIS\Dashboards\irmodel.xml
but irautoan is reading
C:\Prognosis\Server\Configuration\irmodel.xml
Therefore rename as a backup the existing
C:\Prognosis\Server\Configuration\irmodel.xml
as a backup and then copy over the updated one:
C:\Prognosis\WebUI\IIS\Dashboards\irmodel.xml
into
C:\Prognosis\Server\Configuration\
And then stop and start the threshold for it to read in the new irmodel.xml.
HTH
Another condition to keep in mind. The blueprint should be successful IF the records have the same meta.node node name... for it to successfully find the rows/fields from the other records to put into the alerts.
Let us know how it goes!
Thanks for providing the final step missing from the vendor documentation. I will give it a try today and let you know how it goes. I'm actually finally getting around to trying a solution you provided me with from a post I had this past summer titled "SNMP Traps Out Variables". I was looking for a solution to include the device ip address as a variable in trap events we are sending out of Prognosis via threshold conditions for Cisco Call Manager cluster servers (since the ip address is not an available field for most of the Prognosis Cisco Call Manager records)
Sounded like I should be able to accomplish this by linking the PrognosisNode record to many of the Call Manager records I'm trapping off of by using the Alert Blueprint funtionality, thus allowing me to include the corresponding call cluster server's ip address as an additional variable. Will let you know how I make out and if any further guidance is needed.
Thanks again!
This missing step you provided in reference to replacing the irmodel.xml file and restarting the corresponding threshold did the trick as I was successfully able to generate an alert with a new alert blueprint. Appreciate the help!
Is there by chance a way to get a field within the alert blueprint to only include it's value withou the corresponding field name or column header? I'm trying to solely get the ip address of the source device (Cisco Call Manager server) to output in the trap out irAdditionalInfo variable. I've been able to get the TcpIPAddress value from the PrognosisNode record to output in this variable via the alert blueprint, but can't seem to get merely the ip address itself without either the field name or column header be included as well. If I leave the column header blank in the alert blueprint, it outputs the field name in the irAdditionalInfo variable "TcpIpAddress X.X.X.X" whereas all I want in the variable is "X.X.X.X". Closest I've been able to come is to manually edit the irmodel.xml file and then add a single blank space in the header value. Example: <DisplayField name="TcpIpAddress" header=" " />. By including a blank space in the header, the field name and column header don't output in the variable, but I end up with a bunch of white space. Example: irAdditionalInfo= " X.X.X.X".
Great. This one.
https://community.ir.com/t5/General/SNMP-Traps-Out-Variables/m-p/6839#M374
Yes. You are correct. Using PrognosisNode (PNODES) record should work.
Well done. That's good news that it is working.
I believe there is no functionality to remove the field name unfortunately.
Unified Communications has always been an important part of companies' digital transformation efforts due to its ability to enable rich virtual collaboration and communication. But with COVID-19, we've reached a break-through point.
Join Bill Haskins, Sr. Analyst & Partner, Unified Communications at Wainhouse Research, and John Ruthven, CEO at IR discuss UC challenges companies are experiencing due to the COVOID-19 crisis.
Join webinarMembers | Likes |
---|---|
23 | |
23 | |
14 | |
10 | |
8 |