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

Preface
The operations and network management market has a long history going back a decade or more. Nearly every organization and nearly every company has dabbled in it to a lesser or greater extend. Why has no one product or strategy emerged as the absolute best solution for operations management?

Back in the late 90's I began studying the answer to this question. The research involved reviewing hundreds of products from many organizations. From universities, from open source / free developers, on to the biggest vendors in the market.

What I have come to realize is that an operations management platform must exhibit these key attributes:

  • Interoperability
    The typical approach of management vendors has been to create a new API, a new framework, a new management bus, or something along those lines and impose this on the customer. The marketing gimmick being, "switch to our framework and you'll enjoy management bliss!" The problem is that the switch almost always means you lose the ability to manage some device or application you have in your environment. This is not to say that typical management vendors have been trying to do this kind of thing intentionally to their customers (although some might disagree), but rather, they often have an alternative agenda. I.e., they have a platform, operating system, or hardware they need to support and the management model is used to push that agenda rather than to solve the management problem for the customer. The right approach is not to impose a management framework, API, or protocol on the customer, but to build a product that supports the existing management frameworks that a customer has deployed, whether free, public, private, or proprietary.
     
  • Flexibility
    The software must be flexible enough to tie into existing systems, to provide different views to every user, to customize the display for customers, to generate customized reports and to adaptively solve the problem of management for the customer.
    The software must be flexible enough so that the customer can do the things they both want to do and need to do.
      
  • Ease of Use
    Management applications are notoriously complex to use, install, and maintain. I remember the story of one early adopter of AutoNOC in Texas. The data center down the street had done the "responsible" thing to do and spent several million dollars on an installation of a large SNMP based framework (I'll be nice and not mention any names). The vendor flew in six consultants to build the network model and install the software. The consultants did not really understand the customers network and in the process of discovering the network, they crashed several major core devices. The customer that chose AutoNOC (which cost 80% to 90% less) gave us the chance to win their business because they did not want that happening to them. They did not want consultants poking around in their network. They wanted to own their operations model and that is what the AutoNOC approach allowed them to do. The lesson here is that customers understand their networks far better than external consultants. The customer will always build a better model of their network than a consultant, but the software must be easy enough to allow them to do this on their own.
     
  • Infinite Histories
    Thirty seconds? Twenty-four hours? Sorry, that is not enough data to fully understand how the network is working. Expensive and hard to maintain SQL servers are not going to be able to keep up with the volume of data a proper network operations platform generates, and event-only systems do not store sufficient quantities of analytics. Fully understanding what is happening on a network is only possible in a high performance, hybrid event and probe system that allows the user to go back in time six months, or even several years to see what happened at a given moment time. Proper management and network analysis requires the ability to store a near infinite amount of high resolution data
    .
     
  • Scalability
    A scalable operations platform means not only that the software grows with the size of the network, but it is easy to grow the network model. Proper network analysis requires the ability to store a near infinite amount of high resolution data
    .
     
  • Reliability
    The management platform is the last and final stand for network availability. It simply must be reliable. If your applications or network goes down, the management platform must not. Maximizing r
    eliability must be a key component of every design decision in the technology.
     
  • Performance
    A good management solution has to run on rails. It really does. High performance operations management is a more sophisticated problem than even the most powerful databases can handle. An operations management solution has to manage all of the devices, all of the users, perform report generation, query requests, everything, all asynchronously and it has to do it running live, in a real-time environment, in an extremely reliable manner, and without requiring many different staff members to manage parts of the solution.
    Traditional multiple component systems built on generic databases always seem to come up short in performance and ease of use.

With all of these requirements on operations vendors, no wonder the perfect solution has not emerged until today.

Our focus on balancing these criteria from the very beginning has led to an unmatched architectural and design understanding of everything necessary to deliver the optimal management experience for the customer.

It is this focus that has led to the latest release of our core operations platform, AutoNOC 2.2.

Kyle Lussier
President and Architect of AutoNOC

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