If I already have TEC how much does Netcool/OMNIbus cost?
For customers outside of an Enterprise License agreement and who have a current TEC maintenance agreement the cost is worked out in 1 of 2 ways:
- Cost Differential Method – This applies the documented cost of TEC (initial purchase and follow on purchases) as a reduction to the price of Netcool/
- Cost Unknown Trade Up Method – Alternatively customers may upgrade to Netcool/OMNIbus through Trade-up Part Numbers in Passport Advantage (50% price of normal Netcool/OMNIbus parts)
Does Netcool/Impact get included in the license?
Yes. Tivoli Netcool/Impact Version 5.1.1 may be used , for the query and integration of data stored and generated by IBM Tivoli Software products , and not for other data management or automation purposes with data sources that are not Tivoli products.
For example, Tivoli Netcool/Impact Version 5.1.1 can be used to integrate with information generated by IBM Tivoli Netcool/OMNIbus or correlated with information from other licensed Tivoli product data stores, and cannot be used to integrate with non-Tivoli, custom or 3rd party data sources, read/write data to such data sources, or any resources managed by Tivoli products.
In addition implementation of clustering requires purchase of a full IBM Tivoli Netcool/Impact license.
Does WebGUI get included in the license?
Yes. WebGUI (previously WebTop) is now included as part of the Netcool/OMNIbus bundle.
Can you help me write a business case to get the Netcool/OMNIbus upgrade?
Yes – we have a whitepaper on our website that will help with the business case for migration TEC to Netcool/OMNIbus: Business Case PDF
How many events per second can Netcool/OMNIbus process?
The event throughput of the TEC Server is about 25 events/second (without any rules running) whereas an ObjectServer can handle many hundreds of events per second (depending on the hardware specification and other loadings). In lab conditions IBM have seen 2000 events/second on a Blade server running Linux. This is due to the efficiency of the in-memory database.
How do I manage high availability in Netcool/OMNIbus?
The Netcool/OMNIbus solution includes an out-of-the-box, automated failover/failback function for the ObjectServer that encompasses automated failover and failback of all clients, including the probes and the desktop clients, both the Native Desktop and the WebGUI clients.
What tools are available to view and manage events?
The Sub-event List is a component of the locally installed desktop tools suite. The Event List displays each record in the alerts.status table as a row in a scrollable list. User customisable Filters provide the ability to control which alerts are visible within the Sub-event List, for example a Filter could be configured to only show alerts received from Windows servers. Views are used to determine which of the alert fields (e.g. Summary, Tally etc) are displayed. The Sub-event List also provides Tools which enable operators to respond to and manipulate the incoming alerts. Tools are either SQL based, facilitating updates to the ObjectServer database, or command based, which provides a mechanism for running local commands or scripts.
The Netcool/WebGUI interface is accessed by a browser and is delivered as part of the Tivoli Integrated Portal. WebGUI offers a number of graphical tools that can be used to manage alerts. The Active Event List is a Java applet that provides the same functionality as the desktop Sub-event List. With less functionality but with a lighter footprint, the Lightweight Event List and Table Views provide alternative methods for viewing alerts. A key element of the WebGUI interface not found in the desktop equivalent is the Map feature. Maps provide a way of combining static images with dynamic alert summaries and are typically used to provide business dashboard type views.
In addition to the WebGUI and Event List interfaces, Netcool/OMNIbus also offers the Accelerated Event Notification mechanism. Alerts that represent significant issues can be flagged as requiring accelerated notification. When alerts of this nature are received, the desired recipients are notified via pop-up messages on their desktops. The key benefit of AEN therefore being that users don’t have to continually monitor Event Lists, yet they can be assured that they will be notified should any alert requiring their attention be received.
How do I convert my rules?
The actual processing and evaluation of events in Netcool/OMNIbus is handled by SQL statements or SQL procedures executed from triggers. Like TEC rules, triggers fire on conditions being met within the Object Server. IBM states that (as yet) there hasn't been a TEC rule that could not be converted to an ObjectServer trigger and that the 10 most popular are included in the standard product. The development of those triggers is made simpler by the fact they are based on ANSI SQL, skills available in the majority of companies. However, as many triggers are provided out-of-the-box, implementation is further simplified.
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 de-duplication, event correlation and housekeeping.
The TEC Server rules can be migrated to various different functions within the OMNIbus solution, probe rules, ObjectServer triggers or Impact policies. The best location for the event processing logic is dependent on the nature of that processing. However, the migration is simplified by the fact that a number of automations are supplied out-of-the-box with OMNIbus with de-duplication and correlation of resolution and problem events being fundamental to the OMNIbus solution. Shipped automations include triggers to clear individual events based on an expiry time and procedures to enable email escalation.
How long does it take to convert a typical rule?
A typical TEC Server rule enriching an event based on a look-up in a static TEC FACT file will take a couple of hours to migrate and test.
How is event de-duplication handled?
Netcool/OMNIbus server de-duplication is dynamic and flexible. Duplication of events is based on the database primary key, the Identifier field. The value of the field is assigned by the probe, often by concatenating several other attributes to form a unique identifier. On receipt of a duplicate event the Object Server recognizes the duplicate Identifier value and drops the new event (all Primary keys within a database table must be unique). The Tally (count) field within the existing event is incremented, and other fields may optionally be modified.
This compares with the TEC dup_detect facet which is defined in a BAROC file against a particular event attribute and class. This is then used to determine whether two events are the same in conjunction with a rule predicate like first_duplicate. Any subsequent changes to the BAROC file require the rulebase to be recompiled, reloaded and the Event Server restarted.
What are the severities and can I change the default severities?
By default, Netcool/OMNIbus uses the following severities:
These severities can be modified or additional severities added. The EIF Probe rules file uses the following TEC/EIF to Netcool/OMNIbus event severity mapping:
I use fact files. Can I use these in Netcool/OMNIbus?
Yes, three different features are available for implementing lookup tables, each with subtle differences. The chosen option is dependent on how dynamic the lookup data is, the location of the data, the correlation necessary prior to enrichment and when in the event life-cycle the event is to be enriched.
Netcool/Impact is very powerful for utilizing data stored outside of the OMNIbus solution, for example in an RDBMS. However, if the lookups are simple then fact files can be recreated as tables in an ObjectServer database without the need for additional software purchases. Change to these additional tables would be made available immediately and dynamically to all triggers.
Alternatively, probe rules files can be used. For static lookup files the use of lookups in the probe rules would be more efficient than the use of tables within the database as it has the advantage of changing the data closer to the data source.
Does Netcool/OMNIbus provide an equivalent to the TEC exec_task/exec_program predicates?
Yes, in Netcool/OMNIbus external procedures can be used to run scripts and commands on local or remote hosts in a similar fashion to the exec_program and exec_task predicates. Procedures can be called from a trigger or interactively using the nco_sql interface.
There is also a JREExecAction function in Impact that enables the running of scripts and binaries locally. JREExecAction also passes back STOUT/STERR.
Additionally it is possible to create ssh sessions to remote systems from an Impact policy, passing arguments which also allow STDOUT/STDERR to be returned to the policy.
How do I integrate IBM Tivoli Monitoring (ITM) 6 or TEC Logfile adapters with Netcool/OMNIbus?
A range of Tivoli products, and all of the Tivoli Enterprise Console adapters, generates events using the Event Integration Facility (EIF). The Netcool/OMNIbus probe for Tivoli EIF can receive EIF events sent from any of these Tivoli applications and forward them to the ObjectServer. Therefore the EIF probe is a key part of the architecture for integration between TEC and Netcool/OMNIbus.
The EIF probe is not as fast as the Netcool/OMNIbus ObjectServer and as such performance can be limited by its use in an environment. However during performance tests, the throughput achieved using this mechanism and the default configuration shipped is approximately 187 events per second which although is not as fast as the Netcool/OMNIbus ObjectServer is still significantly faster than the TEC. Despite this, more than one EIF probe should be deployed for a single ObjectServer.
Specifically ITM 6 ships with the OMNIbus Event synchronization tool to integrate the two products. The tool is installed on the OMNIbus ObjectServer, and includes ObjectServer automations and EIF Probe rules to format EIF events received from ITM 6. The ObjectServer uses SOAP to communicate event updates back to ITM 6 to ensure two way synchronization.
How do I migrate postemsg/postzmsg based custom alerting
There is an equivalent command for OMNIbus called nco_postmsg which allows you to send an alert directly to an ObjectServer. However, it is not recommended that this utility is used for distributed systems. A more scalable solution is to use the EIF SDK that is shipped with OMNIbus v7.3, and the posteifmsg binaries. This binary is the latest version of postemsg/postzmsg and includes SSL compatibility to enable secure connections.
The nco_postmsg utility accepts name-value pairs for the alert data and constructs an SQL INSERT statement, which is used to insert a new row of data into a specified database table in the ObjectServer.
The nco_postmsg utility is installed with the Probe Support feature of Tivoli Netcool/OMNIbus, and can therefore be deployed separately from the other Tivoli Netcool/OMNIbus features, on one or more hosts.
Full details can be found here: http://www.orb-data.com/knowledge-base/tips/netcool/omnibus/using-nco_postmsg-to-monitor-the-tems-server.html
What can I do with NetView?
There are 2 options available dependent on which function or functions of NetView are currently being utilized.
The IBM Tivoli Netcool/OMNIbus SNMP Probe can receive and format SNMP traps. The foot print and resource requirement of the probe is many times smaller than a NetView Server and hence would be able to replace NetView and remove this support requirement and potentially yet another server.
The probe has the following features:
- Handles a high volume and high rate of traps
- Receives traps independently of trap processing using an internal queue mechanism
- Handles high trap rates and high burst rates using two buffers: one buffer is for all of the sockets that the probe monitors, and the another buffer is an internal queue between the reader and writer sides of the probe
- Supports SNMPV1 traps, V2c traps, and V3 traps
- Supports SNMP V2c and V3 traps and informs
- Uses a USM-based V3 security model
Alternatively IBM Tivoli Network Manager (ITNM) IP Edition provides the features necessary to manage complex networks. These features include network discovery, device polling, including storage of polled SNMP data for reporting and analysis, and topology visualization. In addition Network Manager is able to display network events, perform root-cause analysis of network events, and enrich network events with topology and other network data.
In addition to this existing IBM NetView installations can migrate to Network Manager V3.8 by running a migration utility. You can migrate the following kinds of data:
- Hostnames and IP addresses of all nodes that have been discovered in IBM Tivoli NetView. This file is used by the File finder as input into the Network Manager discovery.
- Nodes and their associated SNMP community strings. The SNMP community strings can be used in the Network Manager discovery.
- Up to six community names that have been specified in IBM Tivoli NetView.
- Unmanaged nodes.
- Device groupings (location containers) specified in IBM Tivoli NetView.
I have more than 1 systems management tool. Can I use Netcool/OMNIbus as a Manager of managers?
Direct integration with a diverse set of Systems Management tools is possible using the associated Netcool/OMNIbus Gateway and/or Probes. For instance the Microsoft Operations Manager Probe has the ability to retrieve alerts from MOM and also supplies, via Netcool/OMNIbus tools, the capability to update, acknowledge and retrieve Knowledge and help items stored on the MOM server.
Probes with similar functionality are available for BMC patrol, HP NNM, SiteScope and many more.
Where direct integration is not available generic solutions such as SNMP receivers can easily be deployed to receive data from any SNMP enabled system. An example of this kind of integration is Nagios.
Impact has a varied selection of Data Source Adapters such as jdbc connectors, webservices stubs, SNMP mediators which can be used to retrieve alert information from disparate sources.
All retrieved data is easily formatted to meet a single standard using the extremely powerful Netcool/OMNIbus Probe rule language, Netcool/OMNIbus ObjectServer triggers or Impact Policies.
I have a service desk that I would like to integrate? How can I do this?
OMNIbus simplifies the integration of 3rd party tools with the use of Gateways. These enable the export or import of data from the ObjectServer, the manipulation of that data and subsequent insertion into an external application.
For example the Gateway for Remedy ARS Action Request System (ARS) is a bidirectional gateway that converts alerts into Remedy ARS help desk trouble tickets. Trouble tickets are updated, according to a predefined mapping, throughout the life-span of the alert. The gateway supports the following functions:
- Failover and failback between Netcool/OMNIbus and Remedy.
- Flexible event filtering that allows you to specify which event details are sent from Netcool/OMNIbus to Remedy.
- Reporting within Netcool/OMNIbus of Remedy operation failures.
- Forwarding tickets in Remedy when the associated events in Netcool/OMNIbus are updated or deleted.
- Updating tickets in Remedy when the associated event in Netcool/OMNIbus is updated.
- Closing tickets in Remedy when the associated event in Netcool/OMNIbus is deleted, and visa versa.
- Creation of journal entries in Netcool/OMNIbus for Remedy.
The Gateway for HP OpenView ServiceCenter / ServiceManager is a fully functional bidirectional gateway.
Alerts forwarded from the ObjectServer through the gateway form HP ServiceCenter / ServiceManager Incident Management tickets. Both systems work together to create and update alerts and tickets. Any change made to a alert or a HP ServiceCenter / ServiceManager Incident Management ticket is reflected in its associated alert or ticket. The gateway manages three types of events, each of which performs a different ticket function. These are:
- Open (PMO)
- Update (PMU)
- Close (PMC)
Integrations with other service desks are available and custom integrations for smaller service desk products can be created if required.
What historical reporting is available with Netcool/OMNIbus?
Netcool/OMNIbus delivers a comprehensive solution for providing alert information for subsequent reporting purposes. The OBDC (or Oracle) Gateway is used to populate an external database (DB2, MS SQL, Sybase and Oracle are all supported) with the details of alerts as they are received by the ObjectServer. As well as the initial alert information, any modifications made to the alert during its lifecycle, such as being acknowledged, severity increased etc, are also recorded. To ensure customers get the maximum value from the raw data, IBM offer a free Tivoli Common Reporting BIRT based report pack. The report pack provides both alert summary reports, which detail the volume and severity of alerts that have been received (which may be grouped by a number of different criteria) but also provide reports showing how well the operators have performed with regards to the number of alerts managed and acknowledgement speed.
I currently run reports on my events. What are my options now?
Running reports can be easily integrated with Tivoli Common Reporting. This is a free add on with many Netcool/OMNIbus reports available. The current reports are
Detailed Average Acknowledgement Times
Summarized Average Acknowledgement Times
Detailed Event Drill Down
Summarized Node Details
Summarized Journal Entries
Is there any in-built knowledge base or help facility for my events?
- However Orb Data suggests integration with a Message Catalogue. The primary function of the Message Catalogue is to document the alerts that a system or application is capable of generating during its operation with the aim of providing the Operations Bridge and other support teams with information that will enable them to respond to incoming alerts in a timely, appropriate and consistent fashion.
Although capable of being tailored for individual customer requirements, a typical format for entries in the Orb Data Message Catalogue is as follows:
Alert Text – the alert as it will appear to the operator
Severity – the severity of the alert
Description – more detail about the alert including what has generated it, why it has been generated and what the implications are
Business Impact – what impact the problem represented by the alert is likely to have on the immediate service and the business as a whole. This information is of vital importance as it will help the operator to understand the significance of the alert and therefore the priority that should be attributed to it
Required Action – how the operator should respond to this alert. Typically includes what first line support actions should be taken and any cross references to the Known Error Database
Escalation – how the operator should escalate this alert to the relevant support area e.g. raise an incident, page on-call support
Owner – each entry in the Message Catalogue has a designated owner who is responsible for the content. This is a key field as it provides a direct contact, should details regarding the message need to be clarified or updates suggested
Revision History – how this entry in the Message Catalogue has been changed over time
This message catalogue can be integrated with Netcool/OMNIbus so that each event has useful information.
What are the advantages of Netcool/OMNIbus over TEC?
The main advantages are:
- Reduce Capital Expenditure - Reduce Hardware costs, simplify the architecture and alleviate future TEC hardware purchases and storm failures
- Improve Operational Expenditure - Utilise normalisation (The process of taking raw input events and extracting individual fields), de-duplication, aggregation, correlation capabilities, as well as time, device, and service based event reductions.
- Maximise Service Availability - Leverage hundreds of out-of-the-box integrations, with included domain intelligent event reduction rules, to monitor end-to-end infrastructure status and health.
- Resiliency and Maintenance - Leverage proven availability and reliability, with trusted system redundancy, failover and security.
Are there any disadvantages?
The Netcool/OMNIbus LogFile Agent is based on ITM autonomous agent technology and is designed to monitor text log files using the traditional ACP format files. However the logfile adapter replacement is not a like for like replacement. Configuration files must be sent to the agent manually, syslog is not supported and complex format files can cause the agent to crash. More details can be read here: http://www.orb-data.com/latest-news-and-views/77-views/338-can-the-ibm-tivoli-netcoolomnibus-logfile-agent-replace-the-tec-logfile-adapter
Two other points to consider are that running remote tasks requires Process Control set-up and version control of the ObjectServer triggers, database, probe rules has to be performed manually whereas creating versioned rulebases was quite easy.
Can you migrate and manage the TEC server for us?
Orb Data has a number of service offerings to migrate customers from TEC to Netcool/OMNIbus.
We can also outsource the management of your Netcool/OMNIbus server completely using our YourTivoli service. Using this option the Netcool/OMNIbus server is held in the cloud and events are sent and accessed securely using a VPN line. http://www.yourtivoli.com