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.


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.


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.)


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.


Advanced customization requires Java skills to develop custom plug-ins.  The DB for alerts and configuration is proprietary. 

Rule Script

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.


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.


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.


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.


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.


Mature GUI and SQL-based tools.  Easy linking to other databases.


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.


Efficiency in calling only when necessary.  Full Java language capabilities.  Library of common plug-ins are included; installed and configured via GUI. 


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.


ll general and many uncommon protocols are supported.


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.


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. 


Custom plug-ins require Java skills.  Uncommon protocols may require plug-in development.

Admin Tools

Netcool Administration

Netcool is configured via a combination of files and GUIs.


File editing is comfortable for Unix admins. 


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. 


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.


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.


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. 


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.


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.


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.

Dollar Sign

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.


Quickly resolves budget surplus problems.  (LOL, ouch.)


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.


Inexpensive (relatively), and easy-to-forecast expenses.


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.

Internet Service Monitoring


Netcool's Internet Service Monitoring solution polls Internet services to ensure availability.


It can speed your deployment of Internet service monitoring. Includes SLA views and performance graphs.


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.


You can achieve the ideal custom solution for your needs.


Some assembly required (plug-in development).


Augur is also ideal for consolidating and refining alarms from other service monitoring tools, i.e. as a manager-of-managers.

Augur vs Tivoli Netcool

Augur can be compared to Netcool Omnibus + Impact.

Terminology Note

The Netcool term probe is equivalent to the Augur term gateway.  The functionality of a Netcool gateway would be implemented by an Augur Handler plug-in.  (A little confusing, sorry.)


We are biased in our topics, but we try be fair.  We are not experts in other tools.  Please send us corrections if you think we got it wrong.


Augur Systems, Inc.

Software for managing data and event streams

© 2012