
|
Netcool Relational Database
Netcool uses a (mostly) standard SQL database. Netcool rules scripts update fields in this database. Triggers and Impact policies also interact with this database.
Pro
Databases provide uniform access. Netcool users can write Perl scripts to interact with the database (although this is unsupported). You can extend the database schema to add your own fields for implementing complex rules.
Con
Database field sizes are limited, so data may be truncated. Basic, intermediate, and advanced customizations require DB Admin skills.
|
Augur Object Database
Augur uses object-based storage. Configuration is stored in a tree structure. Alerts are stored in separate arrays per gateway. (Alerts can also be copied real-time to a RDBMS.)
Pro
Optimal performance in multi-core servers. No arbitrary field size limitations. No database schema to manage. Supports simultaneous configuration sessions. Availability of SQL for custom alert reports. Basic and intermediate customization is via GUI and plug-ins, respectively.
Con
Advanced customization requires Java skills to develop custom plug-ins. The DB for alerts and configuration is proprietary.
|

|
Netcool Rule Scripts
Netcool uses a script language to parse events for generating/clearing alerts in the Omnibus database. A rule script is essentially a large if/then/else structure, with parsed variables. Scripts can be broken into “include” files. “Lookup” files for variable replacement are supported too.
Pro
Scripts are comfortable for experts to edit, and foster programatic tools like “m2r” (MIB to rules). An IDE helps with syntax checking, etc. There is a large library of existing rule scripts, although they may need customization for your needs.
Con
As the scripts get long, they can be difficult to maintain and debug. Maintenance may require a full-time expert. Rule sets may require additional fees. Rule script files are difficult to delegate to multiple subject matter experts for administration. Events that clear alerts may need to reference built-in or custom database fields (e.g. “class”), which can be difficult to document. Lookups are limited to text files.
|
Augur Rule Trees
Augur rules are also essentially a large if/then/else structure with parsed variables, but the structure is organized via a graphical tree. Each tree node has one “if” condition, and a settings for parsing variables and generating/clearing alerts, if an event matches. Lookups for replacements are supported by plug-ins. An XML import schema is supported.
Pro
Tree structure is self-documenting. For large systems, whole rule trees or even branches within a rule tree can be assigned to different subject matter experts to delegate administration. Alerts can reference their own tree node path, for easy identification. Events that clear alerts reference node paths, instead of “class” fields. Plug-in support for lookups allows unlimited options (e.g. lookup from file, DB, etc., or change lookups based on time-of-day, etc.) The XML schema supports programatic tools (e.g. MIB-to-rule tree generator). Syntax errors are eliminated by GUI. The GUI also has tools to debug rules against your sample event data. Start-to-finish development can be much faster, especially for large rule sets.
Con
Library of existing rules is small compared to Netcool. Rule tree editing requires use of the GUI editor, which can seem tedious to advanced users with repetitive tasks. The XML import option is fully equivalent to the GUI editing, but it is not ideal for human editing.
|

|
Netcool Impact
Impact polls the Omnibus database per policies you configure. You can use this for data enrichment from external databases or to perform other advanced interactions with the live alert database.
Pro
Mature GUI and SQL-based tools. Easy linking to other databases.
Con
Continuously polling the database waiting for a condition can be inefficient. Customization is limited to what Impact supports. Additional fees.
|
Augur Handler Plug-Ins
Augur handlers are called for each alert when (and only when) a condition is met. For example, one call-out point is right after an event is parsed by an Augur rule tree.
Handlers can be linked in AND/OR/NOT logic, to implement complex systems from simple building blocks. For example: link a “time-of-day” handler with a “maintenance lookup” handler to implement a system that logs events only at night but not for equipment in maintenance mode.
Pro
Efficiency in calling only when necessary. Full Java language capabilities. Library of common plug-ins are included; installed and configured via GUI.
Con
Custom plug-ins require Java skills.
|

|
Netcool Probes
You connect Netcool to event sources via Netcool probes. The probes delimit events (whether text or binary) and pre-parse general event fields into text variables, then run the rules scripts.
Pro
ll general and many uncommon protocols are supported.
Con
You don’t have access to the raw event format. Custom probes or modifications must be requested from IBM. You must program your own idle time-out. May require additional fees.
|
Augur Connector Plug-Ins
You connect Augur to event sources via connector plug-ins. Connectors convert any binary protocols into a text format (e.g. XML). You configure the event delimiter(s) and variable parsing in the rule trees.
Pro
All general protocols are supported. The open API allows you to build or modify connector implementation, or request from us. (Anything is possible, even Netcool ISM-like polling.) Built-in time-out triggered if events stop.
Con
Custom plug-ins require Java skills. Uncommon protocols may require plug-in development.
|

|
Netcool Administration
Netcool is configured via a combination of files and GUIs.
Pro
File editing is comfortable for Unix admins.
Con
Limited ability to delegate configuration duties. Changes may require ‘kill -HUP’ command line signals or restarts. Limited support for multiple administrators or simultaneous editing.
|
Augur Administration
Augur’s entire configuration is tree-based.
Pro
Any changes are automatically propagated. You can use the tree structure’s Unix-like file permissions to create domains of ownership and visibility. Coordinated multi-session editing. You can copy an arbitrary branch to a file and email it to a peer for sharing, or to your support vendor for debugging help or advice.
Con
Since the configuration is in a binary format, it requires the GUI for changes. XML alternative is overkill for small changes.
|

|
Netcool for Enterprise
Netcool uses bi-directional gateways to synchronize the alert database between distributed Omnibus servers. This can be used to create parallel copies or to roll up hierarchical trees.
Pro
Supports ability to offload all reporting to a dedicated server. In the event of a failure, a secondary server contains copies of all alerts from the primary server.
Con
Does not scale easily, since all alerts ultimately need to be in one server. Scaling requires larger hardware or compromises between number of rules/policies, clients, reporters,etc.
|
Augur for Enterprise
Augur alerts stay in the Augur server that generated them. The enterprise view is created on-the-fly, by collecting data from all servers. Configuration changes are automatically synchronized.
Pro
Easily scales for capacity. Well suited to distribution of servers to the data centers where events are generated... WAN outages do not prevent distributed servers from operating, and self-healing when network restored.
Con
Current “warm-swap” strategy does not have copies of live alerts from a failed server. Some reporting functions cannot be separated from their respective servers.
|

|
Netcool Cost
Netcool costs 6 to 7-figures to license and deploy; 5 to 7-figures in annual support and contracted rule maintenance services. Everything is licensed a la carte.
Pro
Quickly resolves budget surplus problems. (LOL, ouch.)
Con
Customers cut costs by limiting the number of client or probe licenses. The first-year “investment” causes management to resist change for several years.
|
Augur Cost
Augur costs 4 to 5-figures to license and deploy, and the same for support and maintenance in subsequent years. Unlimited client and server licensing.
Pro
Inexpensive (relatively), and easy-to-forecast expenses.
Con
The flat pricing (no first-year hit) requires different way of thinking about budgets and capital expenditures.
|

|
Netcool Notification
Netcool has basic notification features. It is best suited for integration to a third-party solution.
|
Augur Notification
Augur’s notification features compare well to third-party solutions such as TelAlert and AlarmPoint.
|

|
Netcool/ISM
Netcool's Internet Service Monitoring solution polls Internet services to ensure availability.
Pro
It can speed your deployment of Internet service monitoring. Includes SLA views and performance graphs.
Con
ISM is an additional license cost. Customization is limited.
|
Augur Polling
Augur’s connector plug-ins can perform any type of polling, including polling of Internet services.
Pro
You can achieve the ideal custom solution for your needs.
Con
Some assembly required (plug-in development).
MoM
Augur is also ideal for consolidating and refining alarms from other service monitoring tools, i.e. as a manager-of-managers.
|