Enhancement

[Anon]

Why, after 3 plus years and same number of upgrades have the minion yet to come up with a way in which a connection between a device; such as a Cisco Gateway and a Prognosis monitoring node, cannot be deactivated from being monitored and reactivated when ready to resume monitoring? This has been a request of mine for as long as we have been users of the Prognosis product.

[Shoaib_Dilawar]

Hi Mark,

we are planning to create a utility that can suppress alerts by device. Idea is to allow user to mark a device as suppressed, so that any alerts for that device are silently absorbed. As a second phase, same would be available for a specific text. That way any alert with specific text can be made silent.

For deactivating monitoring, you can comment out specific devices from the prognosis conf, or you needed some other way to do so?

[Anon]

Hi Mark,

There is kind of a way that you can try to see if that help you to stop gateway thresholds from firing for those gateways that you don't care.

There is a file called GWayDesc.csv in Prognosis\Server\Configuration\IPTM\Ccma\Config directory where people can overwrite the gateway description (DEVDESC) available in most of the gateway records with a string that they specified in that file.

The format of the file is:
CLUSTER,GWAYNAME,GWAYDESC

If you open the file on the monitoring server, you should see a heading line there already. You can add entry below that heading line for the gateways of your choice. You will have to specify the cluster name, and the gateway name exactly as that show up in the Prognosis record/display, and then add a description such as "NotMonitored" for it. You will need to do this on the monitoring node from where the cluster / gateway is coming from. The collector pick up this list regularly (I think it is something like every 10-30 minutes) and you should start seeing the record being populate with the description that you specified.

Once all the gateways have the same description such as "NotMonitored" and you see that data coming through on the display, then you can add something like

AND DEVDESC “NotMonitored”

to the various gateway threshold conditions with gateway record having DEVDESC field and you should be able to avoid further alerts from those condition.
Once in place, you can add and remove the gateways from the list and the collector will refresh regularly as mentioned before.

While this is more or less a stop gap, as Shoaib mentioned above we are in fact planning on doing something more substantial regarding alert suppression.

The thing is we really want to understand is why are those gateways still in the systems anyway if they are not of interested to be monitored?
Are they just retired gateway that are waiting for procedures to go through for removal or they are there for some other reasons?

Is there a problem of monitoring them because the IP address discovered is not the one that can be used to reach the gateways from the Prognosis monitoring node? If so, there are NAT configuration that can be used to map IP addresses for monitoring etc.

Anyway, it would be of great value to us if you could describe a couple of use cases for us in terms of why you would want to stop a gateway discovered in CUCM DB to be monitored and whether stopping of threshold is all you needed or there are more. We just want to make sure what we plan to build will solve the problem you have in a more user friendly way.