What Has Changed
Well, pretty much everything about the event record structure has changed. So has the method you would need to use to collect the events. On the Windows based system, you could use the LogParser tool (or a WSH script) directly on a CM server. You could also use the tool to query the server remotely, though I don’t do this in my customer environments as I block RPC/SMB/etc. from most networks.
Once you get adjusted to the data collection method, and come up with a way to handle the new record structure, you can leverage the LogParser tool just as you would with Windows events. Actually, since I have been coerced into normalizing the record set I find that LogParser is easier to use.
Data Collection
On the Cisco Unified Communications Manager (CUCM) appliance the event logs are located on the active partition. Specifically, in the /syslog/* path. You can see the files from the command line using this command: file list activelog syslog/* detail
You can collect the files directly from the console if desired by using the “file get” command. This will allow you to download the files to any SFTP server. It is actually one way to schedule retrieval if you like to write scripts for terminal apps like Expect or tcl/vbs scripts in SecureCRT.
Collecting logs from the command line is handy knowledge and I use this method in many cases because it is just easier for me. However, in this particular case I prefer to use RTMT to collect log (and trace) files. I like RTMT for this task because I can easily collect files from all cluster nodes using one wizard and I can specify date ranges or relative time frames. This is pretty handy when troubleshooting.
To collect files using RTMT, start RTMT, connect to your publisher node (or other cluster node if you wish) and do the following:
1. Choose the System menu
2. Select Tools>Trace>Trace and Log Central
3. In the main window frame you will see several options (e.g. Remote Browse, Collect Files, Query Wizard, etc.) double click on Collect Files
4. A wizard will load that allows you to select the files you would like to collect. don’t select anything on the first wizard page and choose Next
5. On the second wizard page, scroll down until you see “Event Viewer-Application Log”. Select this log for either all servers or the one(s) you are interested in. Click Next
6. On the next page you can specify date ranges or relative time. Relative time is handy because you can request files from the previous X minutes. Specify a date range as appropriate. You also need to specify where you will save the file. I like to change this as the download will create a deep directory structure anyway. Click on Finish.
The application event logs will download as text files named “CiscoSyslog”, “CiscoSyslog.1”, “CiscoSyslog.2”, etc. The system event logs will download as text files named “messages”, “messages.1”, “messages.2”, etc. Finally, the security logs will download as text files named “secure”, “secure.1”, “secure.2”, etc. The logs without an extension contain the latest records and the logs with the highest number extension contain the oldest records.
While you are looking at RTMT you may want to consider poking around the schedule collection and query wizard options under trace collection. These can come in handy if you are putting together a periodic operation schedule.
Normalizing the Data
I would like to say that you can get right into using LogParser with the raw text files that you just pulled down but I can’t. Unfortunately, the text files that are retrieved do not have a discrete field delineation. All the white space you see are spaces and sorting record values by spaces won’t work well. It would have been nice if some delimiter was used but oh well, we make do.
Each person will have their own method, I prefer to use a script to read in the Cisco files, normalize the records, and dump them to a “well-structured” file format. I find it easier to do it this way myself.
In this blog, I am going to use jscript code as an example.
Separating Records
A standard record is a long string with a line feed at the end (no carriage return). So, if you read in the file using notepad, it looks horrible. I recommend Notepad++. If using a script, then make sure you keep in mind that you should split records using the newline character (e.g. ” “) and not the carriage return (e.g. ” “).
Record Structure
Just like the Windows flavor of the records, the event entries have little in the way of a discrete structure. But, I have found that they aren’t too bad to deal with. An example record is in order. Let’s look at how the record starts:
Jul 6 18:20:11 CM2 local7 3 : 2012 :Jul 6 22:20:11.300 UTC :
Some interesting points at first glance:
- There are actually two spaces between “Jul” and “6”. If it were July 12th, there would only be one space.
- There is some use of colon “:” as a delimiter between record sections
- There are two date fields. The first is local time (of CM) and the second is UTC time
- The “3” after local7 indicates an “Error” event (2 is warning and 1 is informational)
- The “2012” is actually a sequence number of the event (it does span backup versions of the syslog file
The remain portion of the record is equivalent to the message body of the Windows event message (see above for a link to this discussion). For example, starting after the UTC date: