Designing and Managing Behavior Models - Behavior Models and Their Components - Behavior Models -
Behavior Models and Their Components      NerveCenter Objects

Behavior Models

For NerveCenter to detect a network condition or correlate network conditions, someone must specify how NerveCenter is to detect and react to one or more conditions. Such a specification is called a behavior model. Some behavior models ship with NerveCenter -- these are called predefined behavior models -- and others you must write to handle site-specific conditions.

When writing a behavior model, you must answer the following questions:

• What condition or conditions do I want to detect?

  Although NerveCenter can receive status information from a number of sources, the most common source of such information is an SNMP agent on a managed node. Therefore, in most cases, you must decide whether the behavior model will be poll driven or event driven. That is, will you poll the agent's MIB for status information, look for SNMP traps, or both?

  NerveCenter provides two objects -- polls and trap masks -- that enable you to get information from SNMP agents. For an overview of these objects, see the section Detecting Conditions.

• What network conditions, or states, do I want to keep track of?

  Each behavior model includes at least one alarm, and the definition of each alarm consists primarily of a state diagram. For example, an alarm that tracks the status of a managed node's SNMP agent might have the following terminal states:

  • Normal
  • Device Unreachable
  • Agent Down
  • Device Down

    The state of such an alarm changes as related polls and trap masks gather new information.

    For an overview of alarms, see the section Tracking Conditions.

• What set of nodes do I want to manage?

  A particular behavior model may not be intended for all managed devices. NerveCenter enables you to specify the set of devices that a model will manage using the following objects: nodes, property groups, and properties.

  For an overview of the roles these objects play in a behavior model, see the section Monitoring a Set of Nodes.

Detecting Conditions

In the typical situation where your behavior model is either polling, or looking for a trap from, an SNMP agent, you detect network conditions by creating polls and trap masks.

A poll contains a poll condition that refers to a single MIB base object. For example, the following poll condition looks at an attribute of the ip base object (1.3.6.1.2.1.4):

When NerveCenter polls an agent on a device, NerveCenter evaluates the poll condition against information stored in the agent's MIB. In the case of the poll condition shown above, NerveCenter would check the value of the ipForwarding attribute and compare it to 1. If the value of ipForwarding is 1 -- indicating that the device is a gateway -- the poll generates a trigger. In this case, the trigger is gatewayFound. Every poll must be capable of generating at least one trigger.

A trap mask describes the contents of an SNMP trap. This description can be very general, such as "generic trap 4." Or it can be very specific and include an enterprise OID, a specific trap number, and the contents of the trap's variable bindings. In either case, if the NerveCenter server receives an SNMP trap that matches the description given in a trap mask, that trap mask generates a trigger. Like the triggers generated by polls, this trigger can affect the state of one or more alarms.

Tracking Conditions

NerveCenter tracks each detected network condition using one or more alarms. The scope of an alarm is variable: an alarm can represent the state of an interface on a device, the device itself, or an entire enterprise. Many instances of an alarm can exist simultaneously.

Each alarm is basically a finite state machine. It consists of a series of states and transitions between the states. Each transition is initiated by one or more input events and can produce one or more output events. This state machine is represented in NerveCenter by a state transition diagram.

For example, you could use the state diagram in Monitoring the Load on an Interface to monitor the traffic on an interface.

Monitoring the Load on an Interface

In this diagram, the states are low, medium, and high, and the transitions are LowLoad, MediumLoad, HighLoad, and HiLoadPersists. The initial state of the interface-traffic alarm is low. The instantiation of an alarm instance and a transition to the medium state occur when the alarm manager receives the trigger mediumLoad from a poll that is gathering information about an interface. Note that the trigger name and the transition name are the same.

When a transition occurs, not only does the alarm's state change, but NerveCenter can perform actions. These actions are defined as part of the transition and can include such things as sending e-mail to an administrator or notifying a network management platform that a condition has been detected. For an overview of NerveCenter's alarm actions, see the section Responding to Conditions on page 9.

Monitoring a Set of Nodes

In addition to creating the polls, trap masks, and alarms that define how to detect a network condition, track its severity, and respond to it, you must define which devices you want to monitor for this condition. NerveCenter uses a simple mechanism, involving three types of objects, to define this set of devices. The three types of objects are:

• Nodes
• Property groups
• Properties

Nodes represent workstations and network devices and contain property groups, which in turn contain strings called properties. Polls and alarms are assigned properties. Given this situation, NerveCenter can enforce the following rules:

• A poll can be sent to a particular node only if the node's property group contains the poll's property.
• An alarm can be instantiated for a node only if the node's property group contains the alarm's property.

For more detailed information about the NerveCenter objects used to construct behavior models, see NerveCenter Objects.