netcool/omnibus core overview © 2009 ibm corporation netcool/omnibus core overview venkat m. surath...

Netcool/OMNIBus Core Overview

Netcool/OMNIBus Core Overview © 2009 IBM Corporation


Venkat M. [email protected]


© 2009 IBM Corporation2 Netcool/OMNIBus Core Overview

Agenda

What is Netcool/OMNIbus

Basic Architecture/Components

– Object Server

– Probs

– Gateways

– Administrator GUI Tool

– Event List (Desktop)

– Web GUI

– Basic Failover

– SQL Interface

– Import/Export Utility

– Process Agent (PA)

– Server Editor

– Proxy Server

Deployment Steps

Supported Platforms

Basic Failover

Multi-tiered Architecture

OMNIbus Automations

– Triggers

– Procedures

ObjectServer SQL

Troubleshooting

OMNIbus Probe Architecture

OMNIbus Gateways Architecture

Additional Information/References

Questions



Product Overview - What is Netcool/OMNIbus

It is a SLM system that collects enterprise-wide event information from a wide variety of IT and network resources in real time.

Presents a consolidated view of this information to operators and administrators for monitoring and management.

Tracks alerts/events in a high-performance, in-memory database, and presents information of interest to specific users via filters and views.

Provides automation functions that can perform intelligent processing of alerts.

Alerts (Events) information can then be:– Assigned to operators– Passed to helpdesk systems– Logged in a database– Replicated to remote OMNIbus system for consolidation/failover/HA– Used to trigger automatic responses to certain events



Netcool/OMNIbus - Basic Architecture



Netcool/OMNIbus - Components

ObjectServer

Probes

Gateways

Desktop – Event List

Administration tools

The Web GUI Server

Gateway Target(s)

– RDBMS

– HelpDesk/CRM/Etc.



Netcool/OMNIbus – Object Server

Provides the in-memory database which is the core

Event information is forwarded to the ObjectServer from

– Probes, Gateways, etc.

Event information is stored and managed in database tables

Events are displayed in Desktop Event Lists

– or Active Event List (AEL) in the Web GUI

Provides Automations



Netcool/OMNIbus – Probes

Probes connect to an event source and

– Detects/Acquires event data

– Forwards the data to ObjectServer as events/alerts

Probes use the logic specified in a rules file

– to map event elements to OS fields/columns of alerts.status

Each probe is uniquely designed – to acquire event data from a specific

source

Probes can acquire data from – Sources like Network Devices,

Databases, Log Files



Netcool/OMNIbus - Gateways

Gateways enable exchange of events between ObjectServer to

– Applications, Databases, Helpdesk, etc.

ObjectServer Gateways to replicate events with

– backup ObjectServer for failover

Application gateways integrate business functions.

– Eg. Reporting/Archiving, Auto Trouble Ticketing, etc.

Transfer of events once configured is transparent to operators



Netcool/OMNIbus – Administrator GUI Tool

OMNIbus Administrator is a graphical tool

OMNIbus Administrator can be used to

– Configure and Manage ObjectServers

– Configure process control (PAs)

Started via

– $OMNIHOME/bin/nco_config

– Netcool Suite > Administrator



Netcool/OMNIbus - Administrator GUI Tool …

Use Administrator to configure the following ObjectServer objects:

– Users, groups, roles, and restriction filters– Event list menus, Tools and prompts– Trigger groups/triggers/Procedures– User-defined signals– Event list alert severity colors – Conversions, Classes, Column Visuals– ObjectServer DB, Files, and properties– Channels for AEN

Note most of the functions are available via CLI or SQL interface



Netcool/OMNIbus – Event List (Desktop)

The desktop is an integrated suite of graphical tools used to

– View and manage events

– Configure how event information is presented

Event information is delivered in a format that you can use to

– Quickly determine the availability of IT resources/Services

Most of the features of the desktop are also available in the Web GUI component



Netcool/OMNIbus – Event List (Desktop) …



Netcool/OMNIbus – Web GUI

The Web GUI is a Web-based application that

– Processes network events from one or more data sources

– Presents the event data to users in various graphical formats

The Web GUI contains most features of the /OMNIbus native desktop environment.

The Web GUI uses a client-server architecture.

The Web GUI server runs inside Tivoli Integrated Portal (TIP)

Clients connect to TIP to access the Web GUI.

The Web GUI can be configured for integrations with other Tivoli products.



Netcool/OMNIbus – Web GUI …

Web GUI main components:– Active Event List (AEL)

• A Java™ applet functionally similar to native desktop

– Lightweight Event List (LEL)• A dynamic HTML event list that provides the

data filtering, data sorting, and information drill-down capabilities of the AEL without the event management tools

– Table View• A static HTML event list in the form of a table

showing a defined set of alerts.

– Event Dashboard• Presents the alert information as a series of

monitor boxes, from which you can open AELs.

– Maps• Administrators can use maps to design visual

representations of a network and to create interactive graphical views network performance.

– Chart rendering component• Administrators can create charts that present

high-level information to users in a number of graphical formats including bar charts and pie charts.



Netcool/OMNIbus – Web GUI …



Netcool/OMNIbus – SQL Interface

SQL interactive interface

– Connect to an ObjectServer, and use you to

– SQL cmds. for defining and manipulating database objects.

– SQL cmds. to interact with, and control, the objectServer

– Enables tasks such as creating a new database table or stopping the ObjectServer

Available via Admin. GUI or CLI

– Use nco_sql on UNIX, isql on Windows or ‘nco_config’



Netcool/OMNIbus – Import/Export Utility

Utility or Tool (nco_confpack):

– Export and Import configurations to deploy duplicate systems

– Extract a subset of configuration items from ObjectServers and import them into other ObjectServers

– Save ObjectServer configuration data for backup/restore purposes



Netcool/OMNIbus – Process Agent (PA)

PA performs two primary tasks:

– It runs external procedures that are specified in automations.

– It manages local and remote processes.

PA is used to configure remote processes in order to simplify the management of OMNIbus components

– ObjectServers, probes, and gateways.

The process control system consists of:

– Process agents installed on each host for managing processes

– A set of command-line utilities that provide an interface to process management



Netcool/OMNIbus – Server Editor

Server Editor used to maintain communication information for the OMINbus components

– Interfaces files

The desktop client and client components connects to the ObjectServer using the port defined by the interfaces file for communications.



Netcool/OMNIbus – Server Editor …

Use the Server Editor to

– Create and modify communication details (interfaces file)

– Test server activity (nco_ping)

– Configure virtual server for failover pair (primary/backkup)

To start the Server Editor

– On Windows Click Start → Programs → Netcool Suite → System Utilities → Servers Editor

– $NCHOME/omnibus/bin/nco_xigen at Unix cmd. prompt



Netcool/OMNIbus – Proxy Server

Usually alerts are forwarded directly to the ObjectServer.

When a large number of probes and desktops connects directly to the ObjectServer, there can be a negative impact on performance.

– Proxy server can reduce the number of probe connections

– Multiple probe connections made to the proxy server are multiplexed and forwarded through a single connection to the ObjectServer.



Netcool/OMNIbus - Deployment Steps

Step 1: Access software and Product documentation

– From Passport Advantage, XL, etc.

Step 2: Evaluate H/W and S/W system required

– See Planning information

Step 3: Review the base architecture

Step 4: Install the non-Web components of Tivoli Netcool/OMNIbus

Step 5: Create an ObjectServer database for use

Step 6: Install the probe and gateway components

– Download and install the required probe and gateway components



Netcool/OMNIbus - Deployment Steps …

Step 7: Set up the connections between server components

– Define and generate the interface file using the Server Editor

Step 8: Install and configure the Web GUI component (optoinal)

– Before installing the Web GUI component, start the ObjectServer.

Step 9: Configure process agents (optional) to manage processes

Step 10: Install additional desktop clients (optional)

– On additional user workstations, if required.



Netcool/OMNIbus – Supported Platforms

Tivoli Netcool/OMNIbus is supported on various versions of UNIX, Linux, and Windows.

– aix5 - AIX® systems

– hpux11 - HP-UX PA-RISC-based systems

– hpux11hpia - HP-UX Integrity-based systems

– linux2x86 - Red Hat Linux® and SUSE systems

– linux2s390 - Linux for System z®

– solaris2 - Solaris systems

– win32 - Windows systems



Netcool/OMNIbus – Starting/Stopping ObjectServer

To start an ObjectServer as a process, enter the following command:

– nco_pa_start -process ObjectServer

Use the nco_objserv command to start the ObjectServer manually.

– $NCHOME/omnibus/bin/nco_objserv [ -name servername ]

To stop an ObjectServer as a process, enter the following command:

– nco_pa_stop -process ObjectServer

Use the SQL interactive interface connects to ObjectServer. When the SQL prompt is displayed, enter the following commands:

– 1> alter system shutdown;

– 2> go



Netcool/OMNIbus – Basic Failover

The virtual ObjectServer is configured using

– Primary/Backup failover pair

Desktops, gateways, and probes are connected to the failover pair

If the primary object server fails,

– Clients switch to the backup automatically

When the primary object server is available again,

– Clients reconnect automatically to it (Fallback)



Netcool/OMNIbus – Multi-tiered Architecture

The standard multitiered architecture ( 3-Tire )

– Collection

– Aggregation

– Display

ObjectServers and associated ObjectServer Gateways



Netcool/OMNIbus - Automations

Processes alerts without requiring an operator to take action

For example,

– Generic_Clear Trigger

– Deduplication Trigger

Netcool/OMNIbus includes a number of standard automations

Include Triggers, Signals, and External Procedures



Netcool/OMNIbus - Automations …

Triggers automatically perform a trigger action or fire

– when the ObjectServer detects an incident (DB change) associated with a trigger

Triggers can can run in response to changes

– SQL commands

– Call procedures

Signals are also part of the automation subsystem

– Signals can have triggers attached

– ObjectServer can automatically respond to signals are raised

Procedures are executable programs that are created to perform common operations



Netcool/OMNIbus Automations - Triggers

Trigger Types

– Database triggers

• Pre/Post database action• Delete/Insert/Reinsert/Update

– Signal triggers

• Signal triggers fire when a system or user-defined signal is raised

– Temporal triggers

• Temporal triggers fire based on a specified frequency

• For example, delete_clear



Netcool/OMNIbus Automations - Procedures

A procedure is an executable object that can be called to perform common operations.

The types of procedures are as follows:

– SQL procedures, which manipulate data in an ObjectServer database

• For example, SQL procedure that generates a report on the total number of alerts received (and deduplicated) for a given node

– External procedures, which run an executable file on a local or remote system

• For example, external procedure calls a program called nco_mail, which sends e-mail about unacknowledged critical alerts.



Netcool/OMNIbus - ObjectServer SQL

ObjectServer SQL commands include:

– DDL cmds. to create, alter, and drop DB objects

– DML cmds. to query and manipulate data in existing database objects

– System cmds. to alter the configuration of an ObjectServer

SQL interactive interface to connects to an ObjectServer and run SQL commands.

– UNIX nco_sql -server servername -user username; Windows isql -S servername -U username

– nco_sql -server OS1 -username myuser -password mypass

• 1> select * from alerts.status;• 2> go



Netcool/OMNIbus - ObjectServer Troubleshooting

Check Environment variables

– $NCHOME, and $OMNIHOME

Check nco process

– PA, ps –eaf | grep nco

Check Port Usage

– netstat -na | grep 4100

Check the interface file

– Servers Editor (nco_xigen)

Check DEBUG logs

– MessageLevel DEBUG

Check DB Size (number of events)

– select count(*) from alerts.status;

Check ObjectServer profile

– Enable Profiling



Additional Information/References

IBM Tivoli Netcool/OMNIbus documentation

– http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp

IBM Redbooks

– Certification Guide Series: IBM Tivoli Netcool/Webtop V2.0 Implementation

– Best Practices for IBM Tivoli Enterprise Console to Netcool/OMNIbus Upgrade

– Integration Guide for IBM Tivoli Netcool/OMNIbus, IBM Tivoli Network Manager, and IBM Tivoli Netcool Configuration Manager



Netcool/OMNIbus - Probe Architecture

The function of a probe is to acquire information from an event source and forward it to the ObjectServer.

Probes use tokens and elements, and apply rules, to transform event source data into a format that the ObjectServer can recognize.

1. Event data is generated by the probe target.

2. The probe acquires the event data and processes it based on a rules file. The probe then forwards the processed data to the ObjectServer as an alert.

3. The ObjectServer stores and manages alerts, which can be displayed in the event list, and optionally forwarded to one or more gateways.



Netcool/OMNIbus - Probe Architecture …

1. The probe breaks the raw event data into tokens.

2. The probe then parses these tokens into elements and processes the elements according to the rules in the rules file.

Elements are identified in the rules file by the $ symbol. For example, $Node.

3. Elements are used to assign values to ObjectServer fields.

Elements are indicated by the @ symbol.

4. Fields make up the alerts that are forwarded to the ObjectServer, and are stored/managed in the alerts.status table.

5. The Identifier field is derived or generated by the rules file and is used for deduplication.



Netcool/OMNIbus - Probes

Universal Probes, for example,

– SNMP probe - nco_p_mttrapd

– Log File Probe - nco_p_glf

– ODBC Probe - nco_p_odbc

Specific Probes, fore example,

– Tivoli EIF Probe nco_p_tivoli_eif

– Cisco PIX Probe - nco_p_pix

– Microsoft SCOM Probe -nco-p-scom2007



Netcool/OMNIbus - Probe Types

Probes can be categorized based on how they acquire events. The types of probes are:

– Device – Log file – Database – API – CORBA – Miscellaneous

The probe type is determined by the method in which the probe detects events. For example,

Probe for Agile ATM Switch Management detects events produced by a device, but it gets events from a log file, not directly from the switch. So, it is considered as a log file probe and not a device probe.

Probe for Oracle obtains event data from a database table, and is a database probe.



Netcool/OMNIbus – Probe Components

Netcool/OMNIbus probe usually consists of the following primary components:

– an executable file, a properties file,

– a rules file, and Optional additional probe specific components.

The executable file is the core of a probe. It connects to the event source, processes events, and forwards the events to the ObjectServer as alerts.

– The executable file for the Simnet Probe that runs on Linux is: $OMNIHOME/probes/linux2x86/nco_p_simnet

To start Simnet Probe on UNIX, run the wrapper script :

– $OMNIHOME/probes/nco_p_simnet

When the probe starts, it gets the configuration information from event definition, properties, and rules file

– simnet.def, simnet.props, simnet.rules



Netcool/OMNIbus – Gateways



Netcool/OMNIbus – Gateways …

The preceding figure illustrates how to use gateways for a variety of purposes:

1. Probes send alerts to the local ObjectServer.

2. The ObjectServer Gateway replicates alerts between ObjectServers in a failover configuration.

3. The Helpdesk gateway integrates the Network Operations Center (NOC) and the helpdesk by converting trouble tickets to alerts, and alerts to trouble tickets.

4. The RDBMS gateway stores critical alerts in a relational database management system (RDBMS) so that you can analyze network performance.




Gateways can send alerts to a variety of targets:

– Another ObjectServer (Uni & Bi Gateway)

– A database (ODBC Gateway)

– A helpdesk application (Remedy Gateway)

– Other applications or devices (Flat File Gateway)




A unidirectional ObjectServer Gateway

– allows alerts to flow from a source ObjectServer to a destination ObjectServer

A bidirectional ObjectServer Gateway

– allows alerts to flow from both source/destination ObjectServer




Gateways have reader and writer components.

Readers extract alerts from the ObjectServer.

Writers forward alerts to another ObjectServer or to other applications.




Tivoli Netcool/OMNIbus gateways

Gateway for Clarify

Flat File Writer Gateway

Gateway for HP ServiceCenter

ObjectServer Gateway Guide for V7.3.0

ObjectServer Gateway Guide for V7.2.1

ObjectServer Gateway Guide for V7.2

ODBC Gateway

Gateway for Oracle

Gateway for Remedy ARS

Gateway for Siebel

SNMP Writer Gateway

Socket Writer Gateway

TCP Echo Utility Gateway

Gateway for Tivoli EIF

Gateway for TSRM

Message Bus Integration

Integration with TSRM



Questions

netcool/omnibus core overview © 2009 ibm corporation netcool/omnibus core overview venkat m. surath...

Documents