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

2.1 Investigate
AutoNOC's investigate page is the main monitoring page. From one screen the user is presented with a live cross section of all the key groups on the network. The screen below shows one possible configuration of this display.

The investigate page shows all of the AutoNOC Sets that have been enabled for top level display.

2.1.1 Drilldown and AutoNOC's Root Cause Algorithm
Many companies have taken different approaches at computing root cause analysis. A lot of these approaches have involved complex theoretical artificial intelligence methods, neural networks, and other such approaches to root cause. Results vary and none of them have proven truly satisfactory.

At AutoNOC we have taken a much different approach. Rather than try and teach a computer how to figure out complex problems using artificial intelligence, instead we opted to build a system that analyzes objects based on customizable user models. Each issue is evaluated based on different parameters and values. The most critical issues are assigned levels that cause them to become higher priority than other objects.

Additionally, we built-in large numbers of pre-built rules based on real world situations. The user is free to customize this model by defining new rules and modifying old rules.

Let us examine how this works with an example. The following box shows a top level Set object called Ping. This set object has been defined to query the operations model and return all of the ping probes from the model. See 3.3 - Sets for more information on creating your own sets and configuring them to display on the investigate page.

pic_investigate_pingpic.png (1304 bytes)

Note that the name of the object is in bold, the specific probe chosen is listed next as Ping (Interface), the state text is Down and the service level is -100. When you click on text in the object with your browser, in our particular network model this screen is shown.

The two probes at the bottom are shown in red. Here’s how the first of those of probe results rose to the top level. AutoNOC queries any shown object for it's relevant child objects (Sets query the objects within the set) and then compares each child object to all other child objects to determine which has the most severe state, and which object should rise to the top. In the next section we describe how this process works.

2.1.2 Introducing AutoNOC Service Levels
AutoNOC provides a robust analytical capability to determine which objects have priority over others. This capability is defined as AutoNOC Service Levels. Service levels analyze an object, it's current state, newly acquired data, and it's historical data to determine the current state of the object in terms of the displays within the software.

A service level, once computed, provides the following aesthetic, human understandable pieces of information:

  • Text
  • Color
  • Level

In the above example, a service level determined that a failed ping was occuring and it was able to assign a text, color, and level for the object that is representative of the state of the object. State text can be any user defined wording, the color is the color that should be used when displaying the objects state, and the level is a positive or negative number indicating how root cause should manage the object. The more negative the number, the worse the problem, as AutoNOC sees it. The more positive the number, the better the health of the object.

An object with a -100 level will take precedence in display over an object that has a level 10. As a general rule of thumb, anything that is considered a problem should be less than zero, and anything greater than 10 should be considered not a problem.

For more information about defining your own service levels see the section 3.12 - Service Levels.

2.1.3 The Toolbar
The investigate page has a toolbar with the following capabilities included:

  • Previous Object
    Represented by a left arrow, this object steps back up one level in the drilldown display.
  • Top
    Represented by an up arrow, this object jumps to the top level display.
  • Change View
    Depending on the view shown (usually big box view to start), this icon will show a small replica of the next view available when you click on it.
  • Enable/Disable
    When this toolbar button is pressed it will toggle the disable flag for the object clicked next.
  • Ignore
    When this toolbar button is pressed it will toggle the ignore level state flag of the object picked next.
  • Hide
    When this toolbar button is pressed it will hide the object clicked on next.

For more information on object state flags see topic 3.1 - Object Model.

2.1.4 Pulse Graph View
One of the more interesting views available on the investigate page is the pulse graph view. This view allows the user to see the model in a row-wise manner complete with short recent historical graphs for each object. The following screenshot shows an example pulse graph model.

Each object within the pulse graph view can be clicked on and jumped to. Additionally, click on the displayed column headers to modify the sorting order of the objects within the model.

2.1.5 Probe Graphs
The following screenshot shows the graph that is available when the user drills down all the way to the probe level.

Notice how AutoNOC incorporates the color coding directly into the graph. This makes understanding problems and capacity issues very easy and visually very clear. This graph is an actual graph of two users downloading a copy of AutoNOC from one of our mirror servers. You can see that this particular pipe is 256Kbps wide and that during the two downloads of AutoNOC, each time the user filled the down stream pipe to capacity for a few minutes while the code was downloaded.

AutoNOC also renders minimum and maximum lines in addition to the average line. These are more useful and more prominent with longer time scales and higher data point density.

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