Event Overview


In order to successfully process all events, you need to be able to understand the different event producers, types of events, and the methods used to deliver them.

Events can be divided into two broad categories: state change and performance. State change events are triggered when something in the network changes state. Performance events are generated when a possible performance issue is noticed by some component of your network. Most performance events are generated by thresholds that are defined by you on your network devices or NMS stations.

Table 6-1 summarizes these items, and the next three sections discuss them in detail.

Table 6-1. Methods Used by Event Producers to Deliver Events
Methods Event Producers
Network Device Server Network Management System polling Trouble Ticketing System
Event Type State Change

SNMP notification

Syslog message\

SNMP notification

Syslog message

Log file entry

SNMP notification

NMS event

Log file entry

NMS event

Log file entry

Performance SNMP notification

SNMP notification

Syslog message

Log file entry

SNMP notification

NMS event

Syslog message

Log file entry

NMS event

Syslog message

Log file entry

Event Producers

Any device on the network can produce an event. In addition, events can be produced by your network-management systems or call-tracking systems. Network engineers can identify issues and directly enter them as events.

Some examples of components that produce events and the types of events they might generate are as follows:

  • Devices that provide network connectivity such as hubs, switches, and routers can generate events such as the loss or re-establishment of connectivity between two devices.

  • Computers providing services can generate events such as a database or print server becoming available or unavailable.

  • Network-management systems can generate events such as an event that is triggered if, after calculating the number of collisions versus the network load, a sample falls outside the expected curve.

  • An event could be produced by an end user of the network calling the help desk and reporting a problem such as the inability to reach a particular printer. The help desk technician may generate an incident report that would trigger an event describing the incident reported.

State Change Event Types

Examples of state change events include the following:

  • A network device loses power and the NMS notices it via availability polling and generates an event.

  • A WAN link goes down and the network devices attached to it generate link-down events.

  • A device using spanning tree becomes the root bridge and reports this event as a newRoot SNMP notification.

One of the first types of network monitoring that companies typically implement is availability monitoring. Typically, an application or system will send pings or SNMP requests to devices to determine whether they still have network connectivity. If devices change state, an event is generated.

Performance Event Types

Examples of performance events are the following:

  • An NMS is polling for interface utilization and triggers an event when utilization exceeds 80 percent.

  • A network device triggers an event when an RMON alarm determines that the number of errors on a WAN link exceeds 10 per second.

  • A database on a network server reports that it only has 10 percent free space for new data.

Performance events may represent high-priority faults on your network. For example, the number of errors on the WAN link may represent all data on that link and, therefore, a total loss of connectivity on that link.

On the other hand, many performance events represent a capacity issue on a link or device. You may have used most or all of your bandwidth on a link, or the CPU on a device may be very busy for a significant amount of time. Both of these situations represent degradation of the network. If the degradation is severe enough it may represent a high-priority fault. If not, the faults can be logged for viewing at a convenient time.

Protocols

Many protocols or methods can be used to save or deliver events. You'll have to deal with several of them to handle all your network devices. Many network devices send your EMS some events via SNMP and others through the syslog protocol. To make matters more complicated, some events are sent by only one protocol or the other, whereas other events are sent via both protocols. Your EMS will have to deal with duplicate events, in some cases. The following sections discuss the commonly used delivery protocols. For more details, see Chapter 8, "Understanding Network Management Protocols."

Log Files

Log files are used by many event producers to record the events they generate. Sometimes, the only way to determine that these events occurred is to parse the log files and extract the event information. Some log files only have event information. Others have a variety of data mixed in with the event information. Your EMS must extract the event information and then process the events. In addition, it must keep track of how much it has processed so that it can continue to process the file in the correct place, even if the system has been rebooted. Also, your EMS must understand how to manage your log files so it can keep track of its place.

Some examples of log files that might have event information include the following:

  • syslog log files

  • system console log files

  • application message files

Syslog log files have some degree of structure, unlike most other log files. Log files are the most difficult source of events that your EMS has to deal with. The section "Collecting and Normalizing Log Files" provides some tips on how best to handle them.

Syslog Messages

The syslog protocol usually is associated with UNIX environments. Syslog was developed to manage console messages for the UNIX OS. It is now used for many different applications. It is suited to free-form text messages and allows the sender of the messages to associate a facility or category and a priority to each message. Typically, a syslog server collects these messages into a log file. An event management system needs a process to watch this file and process the messages as events. For more information on syslog, see the "Syslog" section of Chapter 8. We'll cover details on how to handle syslog files in the section "Collecting and Normalizing Syslog Messages" later in this chapter. At least syslog log files have some semblance of structure!

Cisco devices send messages to the console. These messages are the same messages that are delivered via the syslog protocol, with the exception of boot and crash messages.

SNMP Notifications

The Simple Network Management Protocol has a facility for agents (typically implemented as a process running on each device on the network) to send asynchronous messages to a trap receiver. These messages are much more rigidly formatted than syslog messages and, therefore, are more complex to define and administer. This same rigidity, however, facilitates the normalization of these messages into a common event format. These notifications, sent as either SNMP traps or informs, are defined in the SNMP Management Information Base supported by the agent. For more information about SNMP notifications please see the "Notifications" section of Chapter 8.

Traps Versus Informs

The first version of SNMP that was standardized, typically referred to as SNMPv1, defined traps as the mechanism to deliver asynchronous messages. When SNMP was being redesigned, a new delivery mechanism was defined in the SNMPv2 proposals. Although SNMPv2 never was ratified as a standard, the same mechanism was carried over to the SNMPv2c protocol, which is now an Internet standard. This mechanism, informs, is similar to traps and adds a reply mechanism so the SNMP agent can better ensure that a message is delivered. Although this mechanism provides an acknowledgment, it can't ensure that every notification gets to its destination. If there is no network connectivity to a destination, the agent eventually stops trying to send the notification. If the agent is reset, usually all notifications and states are lost. Informs use more resources in the agent than traps. If connectivity is lost to the management station for awhile, some of the notifications delivered after connectivity is restored may no longer be relevant.

Agents that implement SNMPv2c or SNMPv3 can deliver all SNMP notifications to a given destination via either the traps or informs method. Thus, the agent can choose to send informs for all SNMP notifications, including those defined before the informs mechanism was defined.

RMON Alarms/Events

RMON defines a generalized alarm mechanism, whereby an alarm can be defined as an SNMP object crossing a threshold. A hysteresis algorithm is built-in through the definition of rising and falling thresholds (see "Hysteresis" in Chapter 5, "Configuring Events"). RMON alarms trigger RMON events. RMON events can be defined that cause the SNMP agent to send a SNMP notification.

Syslog Events Delivered as SNMP Notifications

Certain devices can trigger an SNMP notification every time a syslog message is generated. This mechanism provides a unified delivery mechanism for all syslog messages and SNMP traps or informs. However, the details of the message are still contained in text and must be parsed out as if the event were a syslog message.

Cisco IOS devices allow you to deliver syslog messages as SNMP notifications with the syslog keyword on either the snmp-server enable or the snmp-server host commands.

NMS Events

NMS generate events for a variety of reasons, including thresholds set on polling objects. Your EMS needs these events delivered to it for processing, along with all other events. If your NMS includes the functions of your EMS, the delivery will be built-in. If not, you will have to choose a method to deliver these events. The method you choose will depend on both your NMS and your EMS. Often, your NMS will support sending SNMP notifications and your EMS should be able to receive them.



Performance and Fault Management
Performance and Fault Management: A Practical Guide to Effectively Managing Cisco Network Devices (Cisco Press Core Series)
ISBN: 1578701805
EAN: 2147483647
Year: 2005
Pages: 200

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net