Bridge Log Parser

Overview

This example shows how I parse the Bridge logs to generate the four reports included in the Bridge Traffic Analyzer tool found on www.CiscoUnityTools.com and that ships with Unity 3.1(5) and later. It parses the selected log directory for all log files and populates a drop down list showing the dates that contain one or more log files. When the user selects a date, all logs for that date are crunched and the resulting information is stored in two tables: one storing information about incoming and outgoing calls between the bridge server and the Octel nodes it’s talking to and one with information about messages transmitting between Unity, the bridge and the Octel nodes.

The output on the form is very sparse, it just shows progress as the logs are crunched, displays all the Unity and Octel node serial numbers encountered in the logs and throws up a little dialog box giving total calls and messages going in and out of the bridge unit for that day. The real story here is the resulting database which you can use to generate your own reports, charts, graphs or whatever paints your wagon.

The code is very stripped down. I removed as many nonessential forms and routines as possible making it as easy to follow what’s going on as possible. The idea is you can reuse the parsing code for your own routines or use my parsing engine and just use the resulting MDB file for your own purposes.

A brief explanation of what’s in the logs themselves and a breakdown of what’s available in the resulting database tables follows.

Quick Log Breakdown

A small sample Bridge log is included with the source code ZIP file for the Bridge Log Parser application. It’s called “CallLog_20020429.log” and is a file taken from a Bridge 2.1 server after running some traffic through it during a load test. You’ll see the following 8 different types of messages in the logs generated by the Cisco Unity Bridge server:

2002/04/29 17:30:36,Incoming,22,23,1

2002/04/29 17:30:52,Outgoing,9,23,1

2002/04/29 17:30:44,Disconnect,22,23,1

2002/04/29 17:30:39,New Outgoing Message,86364,80007,296af337-45df-4dde-b1a8-806f8d42c549,Normal,238675,1,238675

2002/04/29 17:32:05,Cleared Outgoing Message,86364,80007,296af337-45df-4dde-b1a8-806f8d42c549,Normal,238675,9,2145803

2002/04/29 17:33:07,New Incoming Message,86364,80008,4adab9b8-9b19-490d-8fa0-12069b1731d8,Normal,337572,1,337572

2002/04/29 17:33:07,Cleared Incoming Message,86364,80007,0a55cd9b-d177-4482-8c4b-7c34e0eba28e,Normal,338044,1,337572

2002/04/29 17:31:09,Handshake,9,86364,80007

These are pulled from an actual log in random spots, you wont actually see nice neat orders like this, of course, and the data here is from different times in the log so the values don’t really make sense in the order I show them here – but you get the idea.

The first 3 lines shown in blue are specific to calls being initiated between the Bridge server and the Octel nodes it’s communicating with. Since all data comes and goes between Unity and the bridge via IP (VPIM type SMTP transport) there are no incoming and outgoing call there. As such an “incoming” call here is an Octel node calling to deliver one or more messages (remember numerous messages can and are delivered with each call). An “outgoing” call is the Bridge calling an Octel node to deliver one or more messages.

2002/04/29 17:30:36,Incoming,22,23,1

2002/04/29 17:30:52,Outgoing,9,23,1

2002/04/29 17:30:44,Disconnect,22,23,1

The column details break down like this (left most column is #1, columns are separate by commas):

Time/Date stamp
Incoming or outgoing call or a disconnect
Port number making/taking the call – ports are 1 based
Lines available for taking incoming calls. This value reflects the fact that the current port taking/making the call is not available to take a call. Remember some ports can be configured for outgoing only or incoming only on the bridge. This value is specific to ports available to take calls. It’s logged separately since it’s so important to keep an eye on running out of ports for incoming calls. A “disconnect” event still counts the disconnecting port as not being available for use, so account for that.
Ports in use. This value includes the port being used to handle the incoming/outgoing call being logged. Again, a disconnect event counts the disconnecting port as being in use still.

The next 4 lines shown in green are the actual messages being transmitted between the Bridge and Unity or the Bridge and an Octel node. “Incoming messages” here are coming from an Octel node to the Bridge which then transmits them to Unity. “Outgoing messages” are coming from Unity to the Bridge which then transmits them to an Octel node.

2002/04/29 17:30:39,New Outgoing Message,86364,80007,296af337-45df-4dde-b1a8-806f8d42c549,Normal,238675,1,238675

2002/04/29 17:32:05,Cleared Outgoing Message,86364,80007,296af337-45df-4dde-b1a8-806f8d42c549,Normal,238675,9,2145803

2002/04/29 17:33:07,New Incoming Message,86364,80008,4adab9b8-9b19-490d-8fa0-12069b1731d8,Normal,337572,1,337572

2002/04/29 17:33:07,Cleared Incoming Message,86364,80007,0a55cd9b-d177-4482-8c4b-7c34e0eba28e,Normal,338044,1,337572

The column details break down like this (left most column is #1, columns are separate by commas):

Time/Date stamp
Message type – new incoming is a message coming from an Octel node to the Bridge getting stuck on the queue that’s waiting to send to Unity. Messages don’t sit on this queue long since it’s an IP connection to Unity. A new outgoing is a message going on the queue to be delivered to an Octel node. Since the connection here is analog, messages can hang out in this queue for a while and the queue can get large if there aren’t enough ports available to do deliveries. A cleared incoming message event means a message just completed delivery from the Bridge to Unity. A cleared outgoing message event means a message just completed delivery from the Bridge to an Octel node.
Serial number of the Unity server sending or receiving the message in question
Serial number of the Octel server sending or receiving the message in question
Message GUID. This is a unique identifier used in the logs for tracking messages as they move between the inbound and outbound queue in the bridge.
Ignore this column, it’s a priority flag that’s never different than “normal”
The size of the message in bytes.
The total number of messages in the queue (inbound or outbound – determined by the 2^nd column type).
The size of the message queue (inbound or outbound – determined by the 2^nd column type) in bytes. Yeah, the outbound queue here can get big so this needs to be a big number type here.

The last line shown in red is just a handshake notice, you’ll see these all over the place. They can safely be ignored.

Resulting Database Tables

The PortData.MDB file in the application installation directory will contain two tables filled with data when you finish running the example application here.

RawPortData

The RawPortData table shows all the call activity coming in or going out from the bridge for the logs on the day selected. You should see two rows for each inbound or outbound call: one when the call comes in or starts to dial out and one when the call terminates. The columns in the table break down like this:

Index. Unique value for this row in the table.

Port. The port the call is coming in or going out on.

CallType. Type of call. 1= incoming call, 2= outgoing call, 99 = disconnect

StartTime. Time the call started

EndTime. Time the call ended.

Seconds. The number of seconds the call lasted. This value will be empty if a disconnect was not received for the call on this port in any of the logs parsed (i.e. it spanned midnight).

StartMinute. The number of minutes from midnight the call started. I use this to quickly gather data about, say, the maximum number of ports available for a given minute of the day. Yes, this can be derived but its very nice to have it here for you since you can bind a typical graphing tool right to it without having to do any additional processing.

EndMinute. The number of minutes from midnight the call terminated. See above.

LinesAvailableToTakeCalls. The number of lines available to take new calls on the Bridge at the time the call comes in, goes out or disconnects. In all three cases the port in question is considered to not be available to take calls.

LinesInUse. The number of lines in use as the time the call comes in, goes out or disconnects. Again, in all three cases the port in question is considered to be in use at the time.

RawMessageData

The RawMessageData table shows messages going on and off the inbound and outbound message queues on the Bridge. You should see two rows for each incoming and outgoing message: one when it is placed into the queue and one when it leaves the queue. The columns in the table break down like this:

Index. Unique value for this row in the table.

Time. Time the message transmission started or completed depending on if the message type is an new inbound/outbound or a cleared inbound/outbound.

StartMinute. Minutes from midnight that the message transmission started or completed depending on the message type.

Message Type. 3= New inbound message. 4= New outbound message. 5 = Cleared inbound message. 6= Cleared outbound message. See the log explanation above for more details on what inbound vs. outbound means here.

UnitySerialNumber. The serial number of the Unity server the message is coming from or going to depending on the message type.

OctelSerialNumber. The serial number of the Octel server the message is coming from or going to depending on the message type.

MessageGUID. A unique GUID for this message that the Bridge uses for tracking purposes as it moves around it’s internal queues. You can use this GUID to look through the table and see how long a message sat in the inbound or outbound queue – you can match up the NEW xxx and CLEARED xxx messages in the table and calculate the differences in the time.

MessageSize. The size of the message in bytes.

MessagesInQueue. Total messages in the inbound or outbound queue depending on the Message Type value above.

TotalMessageSize. Total size of the inbound or outbound message queue depending on the Message Type value above.

Requirements/Special Notes

The Bridge Log Parser requires version 2.1 or later of the Cisco Unity Bridge. It is not dependant on the Cisco Unity version, because the reports generated are entirely based on logging output on the Bridge unit.

The Bridge Log Parser can be run on or off the Cisco Unity server. The only necessity is access to the logging directory on the Bridge server. However, if possible, it is recommended that you not run the tool on the Cisco Unity server, to avoid adding additional overhead.

Obtaining Updates

To check for updates to this and any Unity tool, visit http://www.CiscoUnityTools.com

Revision History

Version 1.0.1

First release of example source