Cisco Release 4.6.2 Network Applications Manager (NAM) Product Description
Alarm Management (Release 4.6.2)

Table Of Contents

Alarm Management

Distributed Diagnostics and Services Network

DDSN Basic Operation

The Listener

AlarmTracker Alarm Management System

Nodes

States

Alarms

Monitor ICM Event Viewer

Windows NT Event Viewer

Per-Process and Command Log Files

InspectLog Viewing Utility

CiscoWorks2000 Support

ICM Job Scheduler

Informational Messages

Serial Alarm Feed

SNMP Feed


Alarm Management


ICM software tracks events and alarms for the processes and applications running in the system. Events and alarms are recorded on a local and system-wide basis to aid you in system maintenance. An event is any significant occurrence within the ICM system that you might want to know about. An alarm signals that a process or application has become unavailable.

This chapter provides an overview of alarm management within the ICM system. It also includes an overview of the Distributed Diagnostic and Services Network (DDSN), which is a remote support service that forwards specific events to the Cisco Technical Assistance Center (TAC).

Distributed Diagnostics and Services Network

ICM software is designed to communicate directly with the Technical Assistance Center (TAC). The system includes facilities that communicate automatically with the TAC and tools that allow you to manually send files and messages to the TAC. These facilities are collectively called the Distributed Diagnostics and Services Network (DDSN).

The DDSN allows service representatives to remotely diagnose, and in many cases remotely fix, problems in an ICM system. Specifically:

A representative can connect to either side of an ICM Logger through a dial-in or direct network connection.

The Logger can dial-out to the TAC whenever ICM software detects an error or other unusual condition.

The DDSN is based on the Windows NT Remote Access Service (RAS). To support the DDSN, each computer running the ICM Logger process is equipped with a modem to handle outbound DDSN calls.

DDSN Basic Operation

Each Peripheral Gateway, NIC, CallRouter, and Logger runs the ICM Event Management Service (EMS). The EMS facility detects and reports any unusual conditions or events that occur in the system. Each ICM Logger runs processes for the DDSN. These processes collect event reports and forward them to the TAC. Figure 12-1 provides an overview of the DDSN.

Figure 12-1 Distributed Diagnostics and Services Network (DDSN)

Error reporting is handled by two processes that are part of the ICM Logger:

Customer Support Forwarding Service (CSFS) receives events, filters them, and saves appropriate messages in the Logger's \export directory.

DDSN Transfer Process (DTP) transfers the events in the \export directory to the TAC through a Remote Access Service (RAS) dial-up connection or a direct network connection.

The Listener

The Listener is the process at the Customer Support Center that receives events from multiple ICM installations. The events reported to the Listener come from various parts of the system and are of various types. They range from informational messages to reports of serious errors. The event mechanism gives quick notification to customer support representatives when a problem occurs. It also provides a history of activity at each system.

AlarmTracker Alarm Management System

An alarm and event management system called AlarmTracker allows customer support personnel to monitor the events received by the Listener. AlarmTracker lets support personnel view events that have been generated from one or more ICM installations. The AlarmTracker client application communicates with an LGMapper Server process that acts as a distributor of Events received from Listener (see Figure 12-2). In addition, the LGMapper creates an object hierarchy so that AlarmTracker users can view Alarms and Events as part of a hierarchical object-oriented set of nodes.

Figure 12-2 AlarmTracker and the Listener

Nodes

Typically a node is some key component of ICM software. A node might be an ICM component, such as a Peripheral Gateway or a Database Manager; an external device, such as an ACD or IVR system; a process within the CallRouter, or the communication path between two nodes. For example, an event might report that a peripheral has gone offline. A subsequent event might report that the peripheral is back online.

Each ICM system contains a number of such nodes. A sample of node hierarchy is shown in Figure 12-3. A key role of the DDSN is to allow customer support to track the state of these nodes. The AlarmTracker shows the current state of each node for each ICM system.

Figure 12-3 Partial Node Hierarchy as Shown by the AlarmTracker

States

Different objects have different possible states. For example, a device might be online or offline; a communications path might be active or idle; a process might be running or not running.

ICM software includes a number of facilities to diagnose and correct its own problems. In many cases, a problem that causes an object to fail or become unavailable is corrected automatically by ICM software itself. In other cases, support representatives may need to intervene.

Even if ICM software can correct the problem itself, customer support should be aware of what has happened. The AlarmTracker allows support representatives to recognize when an unusual number of problems occur within an ICM system and investigate further.

Alarms

The event that signals that an object has failed or is unavailable is called an alarm. An event raises a condition for the object. The condition might be that a specific object is offline, unavailable, or has failed. A subsequent event might report that the object has returned to normal function. This second event clears the condition.

The AlarmTracker uses a red icon to denote alarm objects for which a condition is currently raised. In Figure 12-3, four alarm objects are shown. (The red icons may appear as a darker gray on the printed page.)

In addition to displaying the current state (and history) of alarm objects, the AlarmTracker allows a Customer Support team to actively manage alarms. The AlarmTracker can be used to assign alarm objects so that other Customer Support representatives can be aware that someone is working on a particular alarm. The status of what Customer Support is doing about an alarm is shown as the icon on the left of the Alarm Detail View shown in Figure 12-3. For the four alarms shown, the first two and the fourth are currently unassigned which is denoted by a red exclamation mark with a yellow background. The third alarm has been acknowledged by a Customer Support representative and may have been assigned to a support engineer. An alarm that is assigned is denoted by a hammer to the left of the state of the object. More information about a particular alarm can be obtained by double-clicking on the alarm object which presents more details on the alarm.

In summary, the AlarmTracker solution provides a comprehensive real-time alarm monitoring and management system that can be used at a Customer site and/or by the Cisco TAC. It is the primary initial diagnostic tool used at the Cisco TAC for supporting our Customer base.

Monitor ICM Event Viewer

The Supervisor reporting application also features an Event Viewer. The Event Viewer lets AW users display near real-time EMS events that have been logged by each process and application running in the ICM system to which the AW is connected.

The Event Viewer provides a graphical application that allows you to:

Retrieve and view event data

Print detailed event information

Filter event data (that is, specify the types of event data to be retrieved from the central database)

Export event data in different file formats

Sort event data on the screen

Figure 12-4 shows an example of the Event Viewer window.

Figure 12-4 Event Viewer

Windows NT Event Viewer

The Microsoft Windows NT Event Viewer allows you to view and manage events on a system-by-system basis. You typically use the NT Event Viewer to isolate problems on specific computers. For example, if you notice unusual event activity while using the Monitor ICM Event Viewer, you can use the NT Event Viewer to further investigate events on individual nodes in the system.

The Windows NT event logging process starts automatically each time a Windows NT system is started. At an AW, you can view event data generated at that AW through the NT Event Viewer. You can also view event data for other locally connected computers (for example, a CallRouter, Logger, or PG). You can connect to these local systems through menu selections in the NT Event Viewer.

Figure 12-5 shows an example of a Windows NT Application Log for an Admin Workstation.

Figure 12-5 Windows NT Event Viewer

Per-Process and Command Log Files

Detailed process-specific log files are created during the operation of the ICM system. These logs are stored in binary format in the logfiles directory on the system. The files are called EMS event source files and are appended with the .ems extension. The files contain specific EMS events as well as trace messages, which are optional detailed records about the operation of a process.

InspectLog Viewing Utility

InspectLog is an EMS viewing utility located in the bin directory on the ICM system. You can use this tool to decode ICM Process logs from the binary format in which they are stored into human readable text. With InspectLog, you can also select various filtering criteria to retrieve only the data that is of interest to Customer Support. Log results can be saved in either text format or in the native InspectLog format for viewing at a later time.

Figure 12-6 shows two processes selected for creating a report from their logs.

Figure 12-6 Selecting a Process to View

Figure 12-7 Customizing the Report

Figure 12-7 shows a date and time range selected for the report while Figure 12-8 shows the report created.

Figure 12-8 Report Created by InspectLog

Clicking on an EMS record in an InspectLog report displays a detailed help message explaining the significance of the log entry. Figure 12-9 shows an example.

Figure 12-9 Example Log Entry Help Message

CiscoWorks2000 Support

The ICM system supports the Syslog event reporting mechanism for CiscoWorks2000. If you are using CiscoWorks2000 for monitoring other Cisco products, you can optionally add the ICM system by configuring the ICM logger for CiscoWork 2000 support. Please refer to the CiscoWorks2000 documentation for details on how to add the ICM system as a managed device.

Figure 12-10 shows an example CiscoWorks2000 report setup window.

CiscoWorks2000 Syslog event reports show the EMS event data in a web browser.

Figure 12-10 CiscoWorks2000 Report Setup Window

ICM Job Scheduler

When you use the ICM Job Scheduler tool to schedule report print jobs, you can specify whether to have the job processing information written to a log file. The log file confirms whether the job properly executed and contains any error messages the job generated. You can view these log files through a standard text editor such as Notepad.

Informational Messages

In addition to sending error information, the DDSN can forward messages and files on demand. You can report a defect, suggest an enhancement, place an order, or comment on ICM documentation. To send an informational message, you can use the Send Home tool ( Figure 12-11).

Figure 12-11 Send Home Window

Serial Alarm Feed

ICM software provides an optional serial alarm feed that allows you to establish your own alarm/event links to the DDSN. The Serial Alarm Feed process uses the Customer Support Forwarding Service (CSFS) to communicate alarm information to an external system. The Serial Alarm Feed process receives events and sends alarms in ASCII code to a communications port on the Logger. The ASCII code can be in any one of three formats. For implementation, consult your sales engineer.

Once the process is started, alarm messages are sent to the communications port as they occur.

The Serial Alarm Feed consists of a series of alarm messages that are sent out over a 9600 baud serial connection. You typically see alarms from the following sources:

Nodes

Processes

Connections

Peripherals

Sessions/Links

You can find information about specific alarm traps in the ICM Information Base (MIB). The MIB correlates to the driving table used by the Customer Support Forwarding Service (CSFS). You can look up each trap number in the MIB to see the descriptions and appropriate ASN.1 syntax used to generate the SNMP traps.

SNMP Feed

The SNMP feed is an ICM feature that supports an event feed through a SNMP-compliant interface (TCP/IP). With the SNMP feed, you can integrate ICM alarms and events into your corporate network management system.

The Cisco SNMP Extension Agent takes advantage of the Customer Support Forwarding Service (CSFS) event feed. The SNMP Extension Agent is an ICM-supplied Dynamic Link Library (DLL) that is installed on Loggers. The SNMP Extension Agent receives an event feed from the CSFS process and communicates with the Windows NT SNMP Agent to generate SNMP traps when certain "alarmable" events occur.

For more information on the SNMP feed and ICM Alarm MIB, see the Cisco ICM Software Administrator Guide.