Designing and Managing Behavior Models - Behavior Models and Their Components - NerveCenter Objects - Alarm Scope -
Previous: Alarms     Next: Constructing Behavior Models

Alarm Scope

All NerveCenter alarms have a property called scope. This property can have one of four values:

• Subobject
• Instance
• Node
• Enterprise

If an alarm has Subobject scope, an instance of that alarm tracks activity on a component that can be described using a nonzero MIB object instance, for example, an interface on a router.

Instance scope alarms track instances for every interface or port that fits the polled condition regardless of the base object. Instance scope is similar to Subobject scope but has the following difference: Instance scope lets you monitor any instance for different base objects. This allows you to track a variety of events for any managed subobject in a single alarm instance.

If an alarm has Node scope, an instance of that alarm tracks activity on a single device. If an alarm has Enterprise scope, an instance of that alarm tracks activity on all managed nodes.

---

Note    It might be useful to think of an alarm instance as a copy of the alarm's state diagram whose current state is something other than Ground.

---

Why is NerveCenter architected this way? Well, think about the following network management problem: You want to be notified whenever four interfaces on a device experience high traffic.

Your first step in solving this problem might be to create a poll that detects high traffic on an interface and fires the trigger highTraffic. You might then create an alarm with node scope and five states, as shown below.

Looking for High Traffic on Four Interfaces

Most likely, this alarm won't detect the condition you're looking for because all four transitions can be effected if the poll repeatedly detects high traffic on a single port.

To solve your problem, the trigger highTraffic must cause one or more transitions in a subobject scope alarm, and this alarm must fire a busyPort trigger (using the Fire Trigger alarm action) during its final transition. Such an alarm is shown in the figure below.

A Subobject Scope Alarm

When the high-traffic poll detects high traffic on an interface, a subobject scope alarm will be instantiated, and the transition highTraffic will occur. During this transition, the alarm will fire a trigger called busyPort. Note that once a subobject alarm instance transitions to the BusyPort state, additional high-traffic triggers for the interface concerned have no effect. However, if the high-traffic poll detects high traffic on other interfaces, new alarms will be instantiated and fire the trigger busyPort. Each instance fires its own busyPort trigger.

Now a node scope alarm similar to the one shown below can be configured to receive up to four busyPort triggers, each one from its own instance of the high traffic alarm. Each busyPort trigger signals high traffic on a different interface.

Node Scope Alarm Detecting High Traffic from Four Alarm Instances

An instance scope alarm behaves in a similar manner as the subobject scope alarm. The main difference between subobject and instance scope is that, with instance scope, you could add another transition to the alarm to monitor a different base object than the one for high traffic. Then, the alarm could be instantiated by the high-traffic poll and then transition again when an entirely different condition (MIB object) is detected.