Cisco Unified Call Manager (CUCM) Records Monitoring

Overview

LogicMonitor processes the CDR and CMR records produced by Cisco Unified Call Manager (CUCM) to produce more granular information on the records of actual calls including metrics for call failure/success, duration, jitter, latency, and cause codes, as well as metrics for processing of the the records themselves.

The LogicModules in this monitoring package are unusual in that they consume record files to function, and rely on a LogicModule hierarchy to do this efficiently. The initial step is for the PropertySource to run and verify that (1) the provided properties are correct and (2) there are records to process. This PropertySource then identifies the method by which the records are provided and creates an automatically assigned property on the host which is used by the Cisco_CUCM_FileCache DataSource. This DataSource is responsible for the ingest and management of the CDR and CMR record files, creating a cache of condensed and quick-to-read formatted data that can be efficiently consumed by downstream LogicModules.

This unique approach removes the need for each LogicModule to read all relevant records, which in turn allows LogicMonitor to process large numbers of calls (millions a month).

Compatibility

As of December 2020, LogicMonitor’s CUCM package for monitoring records is known to be compatible with:

• All known versions of Cisco CDR and CMR record formats.

Setup Requirements

Satisfy Dependencies

• Requires Collector version 29.101 or higher.

Configure CUCM to Send Records to the Collector Host

CUCM can be configured to continuously send CDR and CMR records to an external machine (typically via FTP). LogicMonitor recommends the use of industry standard third party FTP servers such as FileZilla or Windows IIS, especially if vast numbers of calls need to be handled. A trusted FTP server should give you full control over required security for sending these files, as call information contains potentially sensitive information. (As discussed in the Assign Properties to Resources section of this support article, the CUCM.gdpr property assists with compliance with General Data Protection Regulation (GDPR) guidelines.)

Our suggested setup is for the CDR and CMR files to arrive via FTP in a single folder or network share that is accessible by LogicMonitor on the Collector host.

Add Resources Into Monitoring

Add your CUCM device (or one that represents it) into LogicMonitor. When choosing a resource to represent CUCM, keep in mind that the location of the folder containing the CDR and CMR records must be present on the Collector host. Using the Collector itself as the device to monitor the calls is also acceptable.

Assign Properties to Resources

The following custom properties must be set on the device you’ve chosen to represent CUCM within LogicMonitor. For more information on setting properties, see Resource and Instance Properties.

Property	Value
CUCM.path	The path of the directory containing incoming CDR and CMR records.
CUCM.gdpr	When set to TRUE (default), removes information that breaks General Data Protection Regulation (GDPR) guidelines from the cache.
CUCM.time.store	The number of days before CDR/CMR files are deleted from the directory provided above. Default is 0 (never). We advise setting a value that falls in a range between 31 (one month’s worth of stored data) and 365 (one year’s worth). When kept within this range, LogicModules should function well for several years even with large numbers of records accumulating in the directory.
CUCM.time.cache	The number of days a call remains in the cache (default is 1 day which is recommended).

Import LogicModules

From the LogicMonitor public repository, import all CUCM record monitoring LogicModules, which are listed in the LogicModules in Package section of this support article. If these LogicModules are already present, ensure you have the most recent versions.

Once the LogicModules are imported (assuming all previous setup requirements have been met), data collection and property assignment will automatically commence.

Troubleshooting

If metrics are not populating, start the troubleshooting process with the Cisco_CUCM_FileCache DataSource. Specifically, review the “File Throughput” graph for evidence of file processing. If file processing is absent, this suggests an incorrect CUCM.path property or a failure of the mechanism used to transfer CDR/CMR files and warrants manual verification that recently updated files are present in the directory to confirm absence.

LogicModules in Package

LogicMonitor’s package for CUCM record monitoring consists of the following LogicModules. For full coverage, please ensure that all of these LogicModules are imported into your LogicMonitor platform.

Name	Type	Description
Cisco_CUCM_CollectionPath	PropertySource	Verifies record directory and passes path information to Cisco_CUCM_FileCache.
Cisco_CUCM_FileCache	DataSource	Ingests CDR and CMR records into a cache which is used by the other LogicModules. Provides detailed statistics on the ingest process including performance characteristics, cache size, and file throughput.
Cisco_CUCM_CallDetailOverview	DataSource	Provides an overview of the min/max/average of common stats for calls. This is the key module for actual analysis of call manager health of the calls themselves.
Cisco_CUCM_LowMOSCalls	DataSource	Creates instances for calls with unacceptably low MOS values. Any call with an instance here was likely of a very poor quality.
Cisco_CUCM_CauseCodes	DataSource	Monitors the frequency of various cause codes. Observing changes in frequency here can offer insight into a vast range of errors that can result in calls terminating early.

The DataSources in this package do not include predefined datapoint thresholds (that is, no alerts will trigger based on collected data). If you’d like to receive alerts for collected data, you’ll need to manually assign thresholds, as discussed in Tuning Static Thresholds for Datapoints.