OMNIbus or TEC – What are the differences?

With the acquisition of Micromuse earlier in the year, IBM have greatly enhanced their Systems Management portfolio with the NetCool suite of products. One such product is OMNIbus. OMNIbus has been exceptionally successful in companies that require a very high throughput of events, such as telecommunications companies. Of the 25 largest telecomms companies, OMNIbus is used in the Network Operation Centres (NOC) of 24 of them.

However, as IBM already had the Tivoli Enterprise Console (TEC), there are no two products that, at least superficially, do the same thing. This article is intended for TEC users to provide a summary of the functionality, capabilities, benefits and downsides of OMNIbus.

Core Component Comparison

To place the two products into perspective, the table below outlines the core and sub components that make up OMNIbus and relates, where possible, the equivalent TEC components. The article then gives a brief overview of each OMNIbus component and how they differ in the two products.

Function

OMNIbus

Tivoli Enterprise Console

Event Management

Object Server

TEC Event Server

Database

Internal Memory-Resident

External Database

Automation

SQL, SQL Triggers and Procedures

Proprietary Prolog rules engine

Distributed Event Management

No Equivalent

TEC Gateway and State Correlation Engine (SCE)

Adapters

Probes

TEC Adapters

Event Consoles

Event List

TEC Console or WAS TEC Console

Event Visualisation

WebTop

Third Party or Customised

Event Enrichment

Impact

Third Party or Customised

Scalability, Availability and Integration

Uni- and Bi-directional Gateways

Custom

Communications

IDUC over TCP/IP

Framework (RIM Object)

Licensing

Flex License Server required for
validation of component and sub
components

Trust Model

Configuration Utilities

Conductor and Config Manager GUI

TEC Console or command line

Object Server

Database

The key product within the NetCool suite of products is OMNIbus and the core
component of that is the Object Server. Key to the Object Server’s event management capabilities is its internal memory-resident database; allowing it to process an extremely high throughput of events without the degradation in performance due to the constraints of disk I/O. This speed of throughput is the main reason why it has been so successful within Telecommunications companies.

The Object Server is responsible for event management and automation by
manipulating event data through a series of SQL triggers or stored procedures using a sub set of ANSI SQL known as Object Server SQL. This is key to the ability of the Object server for data definition, manipulation and administration.

Automation

The methods in which the two products handle automations are completely
different with respect to the technologies they use. TEC processes events serially by storing the event in the reception log first, evaluating it and processing it using a prolog rules engine, before finally storing it in the event table of the RDBMS. In OMNIbus, the validation of event data against the Object Server’s event schema occurs during the initialisation of the probe or event list. This is shown clearly in the Customisation section later in the article when we add a new field to the Object Server later. This removes the need for defining TEC Classes and event attributes through BAROC files and also the need for a validation process. The actual processing and evaluation of events in Omnibus is handled by SQL Triggers or SQL procedures executed from triggers. Like TEC rules, triggers fire on conditions being met within the Object Server.

There are 3 types of these:

Database

Database driven condition that matches the condition defined
within the trigger

Temporal

Execution based on a timer expiring

Signal

System or User defined condition when a signal is raised

There are a number of generic triggers that are defined and activated during the creation of the Object Server schema. These triggers handle common event management processes like deduplication, event correlation and housekeeping. A good example of the differences is with de-duplication.

In the TEC, the dup_detect facet, defined in a BAROC file against a particular event attribute and class, is used to determine whether two events are the same in conjunction with a rule predicate like first_duplicate. However, any subsequent changes to the BAROC file require the rulebase to be recompiled, reloaded and the Event Server restarted. In OMNIbus, duplication is more dynamic and flexible. Duplication of events is defined by a unique Identifier attribute and is often defined at the probe level by concatenating several other attributes to form an Identifier key. The Object Server then uses this unique field to compare events and match those with the same value. This allows for similar events to be dropped. The following shows how the Identifier field is defined within the simulation (or demo) probe:

@Identifier = $Node + $Agent + $Severity + $Group

Both triggers and TEC rules do a very good job in providing automation and event
management. However, it’s worth noting that OMNIbus can be extended by utilising other products within the NetCool suite such as WebTop and Impact. These products complement OMNIbus by providing event visualisation and further
event enrichment through integration with external data sources and adding further context to the original OMNIbus event.

High Availability

Tivoli provides a means to configure TEC Gateways to forward events to a
secondary TEC Server if the primary TEC server becomes unavailable. However,
there are no means to automatically failover the TEC Consoles so they point to the correct server if one of the servers goes down. Often this, and the fail back process, becomes a manual task and introduces even more headaches when ticketing systems are involved. OMNIbus provides a mechanism out of the box for failing over and automatically (without user intervention) failing back probes, gateways and desktops between a primary and backup Object Server.

composite.jpg1

To configure fail-over between two Object Servers you must first configure a ‘Virtual’ Object Server and it is this that you point your probes/events list to. The screenshot above details the fail-over configuration using the nco_xigen tool. As you can see, a VIRTUAL Object Server has been defined on host orbomnibus with a TCP port 4100.

This actually points to the PRIMARY Object Server as both TCP ports match. The backup server, represented as Backup1, resides on the host, orbomnibus-bk with a defined TCP port of 4101 which actually points to the BACKUP_A Object Server.

composite

Further configurations are required for fail back. For instance, at the probe layer, you need to specify network timeout and poll values so the probe will attempt to detect when the primary server has become available again and the backup Object Server needs to be defined as a BackupObjectServer through its properties file. Once this is in place and you shutdown the primary server, the event list detects a server failure and prompts a logon to the backup server via the virtual Object Server.

It’s usually a good idea to ensure userids and passwords are synced between the two Object Servers for a failover to occur smoothly. Once the correct credentials are set, the event list is refreshed from the backup server. The probe would fail over automatically.

composite.jpg2

When the primary Object Server becomes available again, the event list detects this and prompts you to reconnect to the primary server. The status section on the bottom right of the event list lets you know which Object Server you are currently connected to.

composite.jpg3

Customisation

One of the key benefits OMNIbus has over the TEC Console is the ability to easily customise the event server database by adding or modifying new databases, tables and columns and being able to incorporate these new additions within the running events list. This was something that was not easily achieved within a TEC Console and something that could definitely not take place without restarting the server. The example above adds a regional field to the ObjectServer and console and demonstrates how easily this can be accomplished using the standard tools available through the Object Server.

Adding a field to the Object Server’s event table (alerts.status) can be accomplished either through the command line or the GUI. The screen shot below shows the adding of the new field using the nco_conf tool. This tool is the heart of the Object Server and can be used to configure and manage every aspect of the Object Server(s).

composite.jpg4

Once the new field has been added a restart of the Object Server isn’t necessary. However, all event lists or consoles that are open need to be refreshed. This is quite easily accomplished by performing a ‘resync’ from the event list GUI. Once this has been done the new field can be added as a column to the event list.

composite.jpg5

And we can then see that the event list will now include the new ‘Region Slot’.

composite.jpg6

Desktop

The desktop component is made up of the Conductor, the Event List (shown above) and Tools. The Conductor, as the name suggests, is the top level GUI from where other GUI’s are launched or conducted, one of which is the Event List.

The Event list is the equivalent to a standard TEC console. Much as in a TEC Console, it is made up of one or more Monitor Boxes that represent subsets of events based on filters. This view provides an executive summary of the events being represented by the filter. For example, filters can be set up to represent all events that are in maintenance mode or all critical events that have occurred in the last 10 minutes. From each Monitor Box you are able to drill down and list the events defined within a sub-event list filter. From within the sub-event list, tools (such as ping or ssh or internal SQL commands) can be run against selected events using the context of that event to pass details to the tools.

Probes

OMNIbus Probes are key components of the OMNIbus product and are responsible for obtaining key information by either receiving the information from another source or analysing a local source and passing on the event information to the Object Server. Probes can be compared to TEC adapters in regards to functionality.

However, OMNIbus Probes come in many shapes and forms being both generic and vendor-specific. For example, similar to the TEC Adapters, there are the generic probes for log scraping, syslogd monitoring, and SNMP Traps but there are also Universal probes that are more closely related to the functionality that exists within the Tivoli Monitoring 6.1 Universal Agent. For example, the Exec Probe, Generic ODBC Probe, STDIN Probe and TCP/IP Socket Probe are all available. There are also specific probes that have been designed and developed by the vendor to integrate their own Enterprise Management Systems into OMNIbus or to interface directly with a particular Application or Hardware device. One of key benefits to the probe over the TEC adapter is the ability to parse events for duplication or enrich key events at the probe’s source before passing the event to the Object Server.

In the Tivoli world, events sent from Adapters can be filtered or discarded at the source but any parsing of events means that events have to pass though the State Correlation Engine or end up at the TEC’s rulebase before any manipulation of the event could take place. However, at the probe level, event enrichment is possible through the probe’s local rules file; a lightweight, shell-type scripting language with inbuilt functions capable of string and arithmetic manipulation, regular expressions and conditional logic. For example, where the region field was added earlier, we might have created a probe rule as shown below:

if(regmatch($Node,”.*_a$|.*_b$”)){
@Region = “South West”
}
else if(regmatch($Node,”.*_c$|.*_d$”))
{
@Region = “North West”
}
else if(regmatch($Node,”.*_e$|.*_f$”))
{
@Region = “South East”
}
else if(regmatch($Node,”.*_g$|.*_h$”))

{
@Region = “South West”

}
else
{
@Region = “Unknown”

}

Like TEC Adapters, a probe also has the ability to cache or store events locally if the connection to the Object Server has been lost and re-send the stored events as soon as the connection has been reestablished. However, more importantly, a probe can be configured to automatically fail over to a backup Object Server based on timeouts being met.

OMNIbus Gateways

To Integrate the Tivoli Enterprise Console with problem management systems or asset management databases often requires the need for complex rule writing or a method of extracting the events table using a 3rd party tool; be it Perl, SQL, procedures or triggers. Ensuring the extracted data is in the correct format can often be time consuming and can lead to inconsistencies if changes occur to the event data down the line.

To aid in the integration of the Object Server, OMNIbus provides a series of Gateways that extract data out of the Object Server and into some form ofdestination. The form varies by gateway type and varies again like the probes from generic gateways i.e ODBC, SNMP or Flat file to vendor specific gateways like Oracle Databases, Peregrine, Remedy to Tivoli related gateways.

More importantly, gateways can provide failover and resilience capabilities to the Object Server by synchronising event data in a bi-directional flow between two Object Servers. This is known as a Bi-Directional gateway. A Uni-Directional gateway is available as a mechanism for building a hierarchical architecture of Object Servers by moving specific events to specific Object Servers for presentation to specific customers or organisations.

Licensing

If you’re excited by what you’ve read and it’s whetted your appetite for what OMNIbus has to offer with regards to functionality, reliability and performance then I think at this point it’s worth mentioning licensing!

All NetCool products require a unique license per product and, for the most part, per component (each probe, each gateway, each desktop). Each license is loaded into a central licensing server where they are checked in and checked out each time the product or component is activated. Some of the products produce a heartbeat to ensure the actual license or the numbers of licenses are available or the license hasn’t expired so the product can remain operational. In addition, these licenses are tied to specific hostids which mean each time you install you will need to apply for a new license. Luckily IBM has stated that the license mechanism will eventually fit into their current Trust model and the license server function will be scrapped.

Free Technical Workshop

Why not find out for yourself? We are now taking bookings for our FREE “TEC or OMNIbus? Why Migrate” workshop.

Visits: 166