How often done Prognosis access the Cisco Call Mangaer cluster servers via the CLI to issue the show commands to retrieve ssl certificate information? Does it go off what the cluster profile setting is configured at (high, med, etc.) or some other interval.
The number of CLI reqeusts sent by Prognosis to check certificates (and their trusts) in Cisco UC clusters varies by Prognosis patch version, Prognosis Monitoring Profile and the number of certificates in the cluster.
Prognosis 11.5 patch 3 has the latest fixes for certificate checking and using this verison and patch level are recommended as a first step.
If patch 3 is used, then the total time used to check all certificates in each server of the cluster is determined by the Prognosis Monitoring Profile. The HIGH Monitoring Profile is set to check all certificates and their trusts in 1 hour. Secondly, Prognosis tries to space the reqeusts at least 10 seconds apart per server.
This means Prognosis divides the number seconds in an hour (3600) by the number of certificates and trusts in each server, and then runs a certificate check every xx seconds. If there are more than 360 certificates and trusts in a single server, then Prognosis will send requests more frequently than every 10 seonds.
Thanks for the info Scott. We are currently running on 11.5 patch 3 and our Cisco call clusters are configured with a monitoring profile setting of medium. You'd mentioned a profile setting of high performs the ssl check at hourly interval for each cert/trust. What would be the check interval for a profile setting of medium (on patch 3)? Most of our call clusters servers contain anywhere from 200-250 trusts and certs.
Trying to troubleshoot a recent issue of high thread and process usage across multiple call clusters. One thing we noticed was the call manager audit logs showing a high number of entries where the show cert commands are beign executed via the CLI to retrieve certificate info. Just trying to verify what we should be expecting to see for frequency in relation to specific monitoring of the certifcates.
The Medium Monitoring Profile is set to use 2 hours (7200 seconds) for checking the certificates and trusts.
An alternate solution could be to modify the value for "CLI_ExecCertificateInterval" variable in the Prognosis\Server\Configuration\IPTM\Ccma\cma-profile-high.xml file from 3600 to 7200 or even 86400 (24 hours). Once the value is changed, save the file, then restart the Cisco collectors. This change will decrease the frequency of the certificate polling for all Cisco CUCM clusters, but not change the rest of the polling intervals.
NOTE: This variable change could be set back to default by any patch, and a Prognosis upgrade will definitely return the value to default.
Thanks for the additional information Scott. Querying the call manager servers multiple times a day for ssl certificate details certainly seems rather excessive to me, especially considering that any given server could have several hundred certificates. However, maybe there's some other reasoning behind that interval that I'm overlooking. I've chosen to bump the "CLI_ExecCertificateInterval" in our call manager monitoring profiles up to 86400 (daily), but will keep in mind that this value may revert if any type of software update is performed on the monitoring server. Out of curiousity, is there a limit on how high this particular setting can be set? For example, could we go as high as once week (604800) if we wanted?
I've not tried setting the check interval to anything higher than 86400. I'm sure there is some upper limit for this value, but I've not tried to push until the value breaks something. Checking the certificates and trusts once per day is likely the best setting.
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