Ingest Other CM data via syslog

Set up Syslog

Our first big task is to have syslog installed and available. This is very likely only going to be a concern if you run a single, standalone Splunk+Cisco CDR instance. If you have a bigger Splunk install than just our Cisco CDR Reporting and Analytics app, then you are likely ingesting syslog somewhere already. If you have a Splunk ​“Team,” then I’m *sure* you have syslog somewhere. Ask them about it after bringing them brownies or cake.

If you do not already have a syslog server, you or a colleague will first have to build one, and that is outside the scope of this document.

Configure CUCM to output Syslog

Next we’ll walk you through collecting all the CallManager service information, which includes device registration/​deregistration, resource allocation failures, and lots more. There are other options scattered around in CUCM – finding them and interpreting them is an exercise left to the reader.

1. Open Cisco Unified Serviceability.
2. Click Alarm, Configuration.
3. Select your CUCM Voice/​Video server and click Go.
4. Select the Service Group CM Services and click Go.
5. Select Service Cisco CallManager (Active) and click Go.
6. You may or may not need to click the ​“Apply to all nodes”, depending on your Voice infrastructure.
7. Under the section, Remote Syslogs:
   • Click in the checkbox to Enable Alarm.
   • Enter the IP Address of your Syslog system in the first available Server Name # spot.
   • Change the Alarm Event Level to Informational.
   • Do NOT click the checkbox Exclude End Point Alarms.
     
8. Click Save.

You might want to also check the other services available – I’d suggest enabling only one at a time and carefully checking the license amounts they seem to take. If you have suggestions, please send them to us!

Check Splunk license amounts

Now that we have this dumping data to syslog, let it run for an hour or two, then check the filesize of the created log.txt file and do a little math.

What you need to check is only that this amount of data isn’t likely to take you over the license. The file size isn’t exactly going to be the size ingested in Splunk, but it’s usually close enough to give you an idea if this is a good idea or not.

Also note that Splunk Enterprise lets you go over your allocated data amount up to 5 times in a rolling 30-day window (up to 3 times if you’re on a Trial Splunk license), so even if you ​“blow up your license” for a day, it’s not the end of the world. Perhaps ingesting one afternoon’s worth of data into Splunk would be useful just to see what answers you can really get out of it?

A warning though that if you have a ​“no enforcement” license, then ​“going over” isn’t really a concept; but if you consistently do it, at some point, Splunk will make you pay for that extra license.

Have Splunk ingest the data

If it’s not there already, install the UF on the syslog machine, and in the Splunk configuration tell it to read the files in a ​‘local’ input.conf file:

However if you are using kiwi syslog, then do not set sourcetype to ​“syslog”. Instead set sourcetype to ​“cucm_​kiwi_​syslog”

[monitor:///var/log/remote/192.168.0.*/log.txt]
 host_segment = 4
 # NOTE: if you are using kiwi syslog, then uncomment the following line and comment out the sourcetype=syslog line.
 #sourcetype = cucm_kiwi_syslog
 sourcetype = syslog
 index = cucm_syslog

Obviously, that’s just a sample – you need to fix it up to your path!

After that, as long as your UF’s outputs are set right, you’ll have data coming in.

Configure the Cisco CDR app to display syslog events on Device Detail

Index Macro: return to the Cisco CDR Reporting and Analytics app, click ​“Settings” in the top navigation bar, then ​“Advanced Search”, then ​“Macros”. Find the macro titled ​“custom_​syslog_​index” and click it. 

The default value will be index=“cisco_cdr_syslog”. If you followed our recommendation above and named your index ​“cucm_​syslog”, then edit the value here to be index=“cucm_syslog”.

More generally, change this to match whatever index your syslog data lives in. Also if your syslog data lives in two or more indexes, you can specify ( index=“A” OR index=“B” ) in parentheses.

Field Extractions: Assuming that the syslog sourcetype you are using includes the fields: Device_​name, cucm_​eventname and cucm_​eventdescription then you will see this information display in the Device Detail, within its ​“Summary” tab. 

Under the hood — what do the raw syslog events look like

Device Unregistered

%UC_CALLMANAGER-6-DeviceUnregistered:%[Device name=CiscoUM1-VI3][Device IP address=10.10.20.18][Protocol=SCCP][Device type=80][Device description=VM][Reason Code=9][IPAddressAttributes=3][App ID=Cisco CallManager][Cluster ID=LocalCluster][Node ID=hq-cucm-pub.abc.inc]: Device unregistered

Device Registered

%UC_CALLMANAGER-6-DeviceRegistered: %[Device name=CiscoUM1-VI3][Device IP address=10.10.20.18][Protocol=SCCP][Device type=80][Performance monitor object=2][Device description=VM][Associated directory numbers=7003][IPAddressAttributes=3][App ID=Cisco CallManager][Cluster ID=LocalCluster][Node ID=hq-cucm-pub.abc.inc]: Device registered

Something broke when a device tried to register

%UC_CALLMANAGER-4-DeviceTransientConnection: %[Connecting Port=50538][Device name=][Device IP Address=10.10.20.18][Device type=255][Reason Code=6][Protocol=SCCP][IPAddressAttributes=0][App ID=Cisco CallManager][Cluster ID=LocalCluster][Node ID=hq-cucm-pub.abc.inc]: A device attempted to register but did not complete registration

What else is available?

Cisco has a variety of places that syslog output can be enabled. We talk about a few of the locations and services that they provide syslog ability for, but there’s also Cisco Unified CM Administration, System, Enterprise Parameters, and the section Cisco Syslog Agent, which gets system information too – both OS and hardware information and alarms.

Frankly, we’re not even SURE what all is available or how you might use it. The sky really is the limit, we think, but we aren’t *nearly* as hip to what’s in CUCM as you probably are, so tell us your ideas!

And, that concludes our wonderful foray into the wide world of Syslogging from CallManager.

If you have any comments at all about the documentation, please send them to docs@​sideviewapps.​com.