AutoNOC 2.5 User Guide
Preface
Acknowledgements
System Requirements
Legal

Part 1 - Introduction
1.1 The Ideal Difference
1.2 Automated Operations
1.3 Services & Scaler
1.4 Acquisition Stacks
1.5 Portal Deployment
1.6 Discovery and Crawler
1.7 Monitoring Agents
1.8 Recoiling Database
1.9 Multiple Languages
1.10 Security

Part 2 - NOC Views
2.1 Investigate
2.2 Observe
2.3 Visualize
2.4 Alarms
2.5 Analyze
2.6 Design
2.7 Configure

Part 3 - Model Design
3.1 Object Model
3.2 Devices
3.3 Sets
3.4 Set Criteria
3.5 Probes
3.6 Logs & Events
3.7 Alarms
3.8 Actions
3.9 Reports
3.10 Users
3.11 Polling
3.12 Service Levels
3.13 Dependencies
3.14 Performance

Part 4 - Developer Features
4.1 Adding SNMP MIBs
4.2 Variables
4.3 OSP API
4.4 Probe Template
4.5 Log Template
4.6 Device Template
4.7 Interface Template
4.8 Rebranding

Part 5 - Troubleshooting
5.1 General Issues
5.2 Linux
5.3 Windows

Appendix
A.1 OSP API Functions
A.2 Variables
A.3 Object Reference

3.7 Alarms
AutoNOC features one of the most easy to use and sophisticated alarm and condition monitoring systems available.

When an alarm condition is detected and the conditions described in this section are met, then AutoNOC will fire the child actions of the object. For complete information on alarm actions see 3.8 - Actions.

3.7.1 Object Sets and False Alarm Reduction
AutoNOC's alarms include the ability to analyze large sets of objects for specific alarm conditions. This functionality is implemented by way of Sets. For complete information on defining Sets, see 3.3 - Sets.

To create an alarm, you must first create a Set that contains the objects to be monitored for the alarm condition. Specify the Set of objects for an alarm to monitor on the Trigger tab of the alarm dialog as shown in the following screenshot:

What is very novel and useful about AutoNOC alarms and how they are built on top of Sets is that convenient aggregate groupings can be constructed and monitored. For instance, an alarm can be created that monitors a set of devices for problems. Or that looks at Total Traffic for part of the day and then a different probe at a different time of day.

Additionally, because each alarm is processed for each object in the specified Set, it is possible to vastly reduce the number of false alarms generated. This is important because most operations and monitoring software suffers from a key problem, far too many alarms when something happens. Staff gets overloaded with alarms, pages, and e-mails when something happens. AutoNOC allows you to aggregate many conditions into a single Set. AutoNOC will then fire actions based on the conditions of that Set alone, vastly reducing the number of alarm actions when something happens.

It is theoretically possible to reduce all possible issues in a network down to a single end user notification. If you think about this construction for a little while, you will quickly realize just how novel, powerful and useful an innovation that AutoNOC's set based alarms provide the user with.

3.7.2 Trip Expression and Computation
Alarms in AutoNOC are computed at user configurable time intervals as the Compute Every field shows in the following screenshot.

The first step in the alarm computation is to query the selected Set for the objects to be analyzed. AutoNOC works through each of these objects and evaluates the Trip Expression at the scope of each object. If the expression comes back as TRUE then the alarm for that object is turned on. The alarm is turned off if the expression returns FALSE.

An example Trip Expression is "%L<0" which computes the service level for each object and turns on the alarm for any object with a negative service level. By default AutoNOC analyzes the current state at processing for each object which is computationally very efficient. If the Process Every Data Point capability is turned on then AutoNOC will process every data point for all objects from the last time the alarm is computed until the current time. This can result in multiple alarm on and alarm off occurrences and it can also use a lot of processing power.

3.7.3 Fire on Alarm On / Off
When an AutoNOC Alarm detects a state change (by solving the Trip Expression for each object in the Trigger Set) it causes the Alarm to turn on. If the Fire On Alarm On switch is enabled then all child actions will be fired. This is also true for the FIre On Alarm Off switch, only the action is launched when the alarm turns off.

The launching of an action occurs for each individual instance of every object that meets the fire on alarm on or off condition. So, for instance, you can have a Set that is made up of Set objects and AutoNOC will solve the trip expression within the scope of each nested Set. In this way, alarms can be aggregated.

3.7.4 Reset
Users with the technician flag can reset alarms and temporarily suspend the alarm on condition. Users with the Technician flag can also shut them down for a preset period of time. The length of time the alarm stays reset is controlled by the Reset Button setting.

The button to reset the alarm is available on the Alarms page. For more information, see 2.4 - Alarms.

(C) 2007 - All Rights Reserved - AutoNOC LLC
      Call me!