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

4.5 Log Template
Log templates work much like probe templates only they provide generic configuration for log objects that receive, store, and analyze incoming event data. The following screenshot shows the location of a typical log template:

pic_logs_syslog.png (12395 bytes)

Many of the settings are the same as probe templates. See 4.4 - Probe Templates for more information. In this topic we will focus on the settings and capabilities that are unique to log templates.

4.5.1 Log Records and Delimited Data
Events in AutoNOC are stored as text based event records that occur at a certain timestamp. AutoNOC accesses and processes these records individually in the same way as probe values are managed. Log data is significantly more sophisticated than probe data however.

Events that AutoNOC receives, such as SNMP traps and Syslog events, are setup in a semi-colon delimited format, that is each field in the event is separated by a semicolon.

4.5.2 Service Levels
Developing service levels for events contained in logs requires a bit more sophistication. For instance, syslog events have a type built into the actual event. The process of determining the service level and meaning of a syslog event is equivalent to extracting its type from the semi-colon delimited event text. One way to do this is with the Get(...) interpreter function. For more information on developing interpreter functions see 4.3 - Interpreter.

The following screenshot shows the service level configuration for the built-in Syslog template. The rule extracts the second (index of "1") field from a syslog event out and compares it with the eight standard syslog types. AutoNOC then classifies the object based on this value with options for Emergency on through None.

4.5.3 Name and Detail Expression
Events in AutoNOC are visually displayed throughout the software in the form of a Name which represents the name of the event and Detail which further elaborates on the specifics of the event. Both the Name and Detail fields are expressions evaluated by AutoNOC returning a string for display to the user.

The following screenshot shows the Name and Detail expressions for the syslog log template. Note that the example expressions extract and combine parts of the event text to make a human readable name for the event. The detail expression simply replicates the detail field of a syslog event.

Why even bother with such a setup for analyzing events?

The answer lies in focusing on the purpose of AutoNOC, which is to integrate all available data sources, no matter how complex and present it in a manner that is useful and understandable to human beings. The Name and Detail expressions allow easy, consistent integration and interpretation of event data no matter the source or the shape.

4.5.4 Event Filters and De-Duplication
A big problem with many event generators is overload and event duplication. Syslog, for instance, can generate very large numbers of events. Filtering and de-duplicating events is a must and AutoNOC provides a clean and sophisticated filtering capability.

The following screenshot shows the filtering settings available:

De-Duplicate Records automatically removes incoming events that are the same as ones recently received. Default Policy specifies whether AutoNOC will delete incoming log events by default or keep them by default.

Each individual filter Rule specifies an interpreter expression that if true will be either excluded or included. Filter Type specifies if the event should be included or dropped if the rule evaluates to TRUE.

AutoNOC processes each rule one by one in sequential order and stops when it finds one that is TRUE. If it does not find a true rule, then the default policy is used for the event.

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