While the CDR data has a lot of goodness and magic in it (disregarding it’s obtuseness and terseness), it doesn’t tell you things like when phones disconnect or deregister.
Lucky for us, that information can be gotten out of CallManager using syslog.
Please think of the following as more of a general guideline in getting this data out of CM and into Splunk. It’s not perfect, it’s not complete, but it is a good start and should help you get your feet wet.
Also, if you set this up and would like some help digging around in the resulting data and determining what it’s worth, then by all means shoot us an email – we’d be happy to help flesh this out more for you!
Create an index
A new index needs to be created on your indexing tier. If you are standalone, you can do it through the UI under Settings, Indexes. For now call it cucm_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 will have to build one. This is a task far outside our bailiwick, but we can at least give you a few nudges in the right direction.
There are lots of places to go for help with this. Use the Search, Luke!
Linux with Syslog-NG
Assuming you did syslog-ng on a Linux VM, you will need to configure the syslog-ng instance to listen on the network, and to create new directories for each new host it sees. To do this, you’ll want to edit syslog-ng’s configuration (locations vary, use your OS’es documentation on where it hides syslog configuration files) and add something like the below near the top of the file.
That would make directories for each host (either name or IP, depending on if it resolves) like ‘/var/log/remote/192.168.0.1/log.txt’. Restart syslog-ng after making those changes.
Note that this is a really simple, basic config. While it should work, we make no guarantees it’s appropriate for your environment. If you have problems with it, there are lots of forums and help documents available, but let us know what you find out!
Windows with Kiwi Syslog
After installing Kiwi Syslog Server, the only thing you’ll likely need to do is move the log file location.
Note that this is the minimum changes to get a working Kiwi Syslog Server installation working well enough for our needs. There may be other configurations you need to do for your own environment.
Configure CUCM to output Syslog
Here’s where there are choices to make on what you want to collect. This example is going to collect all the CallManager service information, which includes device registration/deregistration, resource allocation failures and lots more. There are other options scattered all over the CUCM installation – finding them and interpreting them is an excercise left to the reader! (Although, down below there’s at least one more location mentioned).
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 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:
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.
What kinds of data do we get?
If you followed along and used the same Alarm settings as we outline above, you’ll get a variety of messages. Here’s a few samples to gaze upon – take in their beauty!:
Something broke when a device tried to register
How would I make a start at using those?
We have some “behind the scenes” extractions for those that you could apply (Contact us – we’ll probably make them more public soon but for now we’d be happy to provide them to you!), but for just fiddling around and trying to find out what sort of useful information you can get, you could start with a search that does a bit of delimiter based extraction…
index="cucm_syslog" | extract pairdelim="" kvdelim="=" auto=f
If you run that search a lot of useful fields should pop up on the left. Cluster_ID, Node_ID, Device_IP_Address, etc… From there, dig around like any other Splunk data!
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 it in to firstname.lastname@example.org.