Designing and Managing Behavior Models - Using Alarms - Alarm Scope -
Defining an Alarm      Defining States

Alarm Scope

NerveCenter alarms can have one of four scopes: subobject, instance, node, or enterprise. A subobject scope alarm monitors a subcomponent of a node, usually an interface (subobject). Instance scope lets you monitor different base objects in a single alarm instance. Node scope monitors activity on a single node, and enterprise scope monitors all managed nodes for a particular behavior.

This is fairly straightforward, but let's look at an example of how alarm scope might affect a particular behavior model. Let's say that you have a model that manages three workstations, each of which has four interfaces.

Managed Nodes and Their Interfaces

One component of this behavior model is a poll that checks variables in each workstation's ifEntry table to find interfaces that are experiencing high traffic. This poll can fire a trigger up to twelve times on any poll interval, as shown in Triggers Fired by High-Traffic Poll.

Triggers Fired by High-Traffic Poll

The behavior model also includes the alarm whose state diagram is shown in High-Traffic Alarm:

High-Traffic Alarm

A beep action is associated with the highLoad transition.

Assuming that you've set the alarm's property properly, you've enabled both the poll and the alarm, and all interfaces are experiencing high traffic, how many beeps will you hear?

The answer depends on your alarm's scope. If the alarm has subobject scope, twelve alarm instances will be created, and you'll hear twelve beeps, one per interface. Similarly, for instance scope, twelve instances will occur and beep. The main difference between subobject and instance scope is that, with instance scope, you could add another transition to the alarm to monitor some base object other than ifEntry.

If the alarm has node scope, three alarm instances will be created, and you'll hear three beeps. Once an alarm instance for a node transitions out of the Ground state -- upon receipt of the first highLoad trigger for that node -- any subsequent highLoad triggers that refer to that node have no effect. Finally, if the alarm has enterprise scope, only one alarm instance is created, and you'll hear just one beep.

For behavior models that contain just one alarm, choosing an alarm scope is usually simple. Just state the condition you want to be able to detect:

• "I want to be able to detect high traffic on any interface." (Subobject scope)
• "I want to detect several conditions on any interface." (Instance scope)
• "I want to monitor each node on which a particular condition occurs." (Node scope)
• "I want to be notified the first time that high traffic occurs on any interface." (Enterprise scope)