NerveCenter^TM 3.8: An Overview - Contents - How Behavior Models Work - Behavior Model Operation -
How Behavior Models Work      NerveCenter Components

Behavior Model Operation

A behavior model is not a NerveCenter object. Rather, it is a collection of NerveCenter objects designed to monitor specific network devices, events, or behaviors.

A Simple Behavior Model shows the interaction of objects in a simple behavior model.

A Simple Behavior Model

When a trigger-generating object detects an event of interest on a node, it raises a trigger. This trigger generator might be a NerveCenter poll that looks for a specified network condition or a trap mask that detects a certain type of SNMP trap. NerveCenter alarms internally subscribe for triggers based on the state of the alarm. When an alarm detects its first trigger, the alarm transitions to a predefined state. Based on the state, the alarm ignores triggers that can no longer cause transitions and listens instead for those triggers that can. The alarm waits in that state until another trigger is received -- either from the same or another trigger generator. This allows an alarm to react only to relevant events and poll only for relevant data. For more information about alarms, see Alarms.

How properties affect behavior models

Properties allow you to limit excessive polling and control which nodes are targeted by which alarms. A property is text string that describes the type of node or one of the node's MIB objects. A property group is a group of properties assigned to a node. Each node is targeted based on its assigned property group, which can contain many properties. Before an alarm can be applied to a node, the node's group of properties must include any property specified in the alarm or its associated polls. Additionally, before a node can be polled, the node's property group must contain the MIB base object that the poll is designed to evaluate. Assigning a node to a property group with multiple properties allows the node to be targeted by multiple alarms.

Other trigger generators

You've already seen how polls and trap masks detect pre-defined network events and fire triggers. NerveCenter has other generators as well.

Alarm transitions can trigger actions that, themselves, generate triggers. These trigger-generating actions can cause a transition in another alarm or transition yet another state in the same alarm. An alarm can also execute a Perl subroutine, which can fire a trigger when certain conditions are met. In both cases, the alarm serves as a trigger generator that provides an important function in a behavior model. These types of trigger generators provide an additional level of control over your alarms.

The following diagram shows the interaction of various trigger generators in a behavior model.

A Behavior Model with Triggers Generated by Alarms

Alarm actions

NerveCenter can implement a broad range of actions when an alarm is instantiated. A transition might cause NerveCenter to send a trap, email, or page. NerveCenter has its own type of message -- an inform -- that contains the variable bindings associated with the event that caused the alarm to transition. Informs can be sent to one or more destinations, including network management platforms and other NerveCenters. For each destination, you can specify a minimum severity level that your network conditions must meet before the informs are issued.

NerveCenter can call a Perl subroutine as an alarm action. The Perl subroutine might fire a trigger when certain conditions are met or execute other commands that effect changes to your network. Perl subroutines have access to associated alarm and trigger data for nodes that cause alarms to transition. Subroutines can then evaluate this information and conditionally take further action.

NerveCenter can also log alarm data and perform corrective actions such as setting SNMP attribute values. Finally, all actions can be performed conditionally using the NerveCenter Action Router. The Action Router performs actions based on user-defined criteria such as time of day, severity of the alarm, type of node, and so on.

NerveCenter allows you to monitor alarm activity in its Client or Web Client consoles. For a description of the NerveCenter Client, see The NerveCenter Client Console. For information about the Web Client, see Web-based Monitoring.

For more information

To learn more about NerveCenter's behavior models, refer to the following sources of information:

• The Learning How to Create Behavior Models and the Designing and Managing Behavior Models online guides shipped with NerveCenter contain complete descriptions and procedures for behavior models.
• Each model ships with its own HTML file that describes the model and includes related procedures. The HTML files are stored in the NerveCenter installation/Model directory.
• NerveCenter objects, such as alarms, include notes that describe the object and provide specific information related to that object. For example, the notes for an alarm include a list of triggers that transition the alarm, the objects that fire those triggers, and any actions associated with the alarm's transitions.

Alarms

Alarms are key to the operation of behavior models. An alarm is a finite state machine that defines the operational states it wants to detect and transitions from one state to the next when the proper trigger is received. Each transition is triggered by its own set of network data, which is defined in the NerveCenter object that generates the associated trigger. Transitions can also be driven by any alarm action that causes a trigger to be fired. If actions are associated with a transition, the server performs these actions each time the transition takes place.

IfUpDownStatus Alarm shows the state diagram for a NerveCenter alarm called IfUpDownStatus. IfUpDownStatus monitors the operational status of interfaces on managed nodes. If an interface is down, an inform action notifies the network management platform.

IfUpDownStatus Alarm

Each state is depicted as an icon in the diagram. The state icons are color coded to represent a particular level of severity.

The alarm contains four states related to the status of an interface:

• Up -- The interface is up. The current (operational) and desired (administrative) statuses are set to 1 (defined in RFC1213 as up). This state has a severity level of Normal.
• Administratively down -- Both the current (operational) and the desired (administrative) statuses are set to 2, defined in RFC1213 as down.
• Testing -- Either the current (operational) or desired (administrative) status is set to 3, defined in RFC1213 as test mode.
• Operationally down -- The current (operational) status is down but the desired (administrative) status is up. This state has a high severity level of Major. All transitions leading to this state include an alarm action that sends an inform to NerveCenter or to the platform.

The ifStatus poll fires all the triggers that transition the IfUpDownStatus alarm. The poll is designed to evaluate the MIB base object attributes ifAdminStatus and ifOperStatus, which belong to the ifEntry base object in the interfaces MIB-II group. The poll fires four triggers -- one for each of the four states previously described -- based on the values returned for the two attributes. The alarm correlates the data it receives from the poll and transitions based on the combinations shown in Correlation of IfEntry Attributes in the IfUpDownStatus Alarm.

Correlation of IfEntry Attributes in the IfUpDownStatus Alarm

In this alarm, a trigger representing a condition other than up for either attribute -- ifAdminStatus or ifOperStatus -- transitions the alarm from the Up state. A subsequent trigger representing a condition other than up for the remaining attribute then transitions the alarm to a different state. The state to which it transitions depends on the combination of the values for the two attributes.