You are on page 1of 79

Netcool/OMNIbus Integration Best Practices May 2007

Tivoli Netcool/OMNIbus Integration Best Practices
Document version 1.1

© Copyright International Business Machines Corporation 2007. All rights reserved US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

CONTENTS
List of Figures.................................................................................................................... v List of Tables .................................................................................................................... vi Revision History ...............................................................................................................vii 1 Getting Started ...................................................................................................... 1 1.1 1.2 Tivoli Netcool/OMNIbus Architecture and Overview.................................. 1 Tivoli Netcool/OMNIbus Integration Methods and Interfaces .................... 4
1.2.1 1.2.2 1.2.3 1.2.4 Creation of a Tivoli Netcool/OMNIbus Rules Files ................................... 4 Creation of a Tivoli Netcool/OMNIbus Tool .............................................. 5 Creation of Tivoli Netcool/OMNIbus Automations .................................... 6 Tivoli Netcool/OMNIbus Integration Option Architecture.......................... 7

1.3

Tivoli Netcool/OMNIbus Integration Development Environment................ 8
1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 Tivoli Netcool/OMNIbus Software and Required Components ................ 8 Tivoli Netcool/OMNIbus Software Installation and Licensing ................... 9 Rules Files Editor...................................................................................... 9 Probe Configuration for Development and Testing Purposes ................ 10 Additional Resources.............................................................................. 14

2

Creation of Tivoli Netcool/OMNIbus Rules Files ................................................. 15 2.1 Probe and Rules Files: Function and Architecture .................................. 15
2.1.1 2.1.2 2.1.3 Introduction ............................................................................................. 15 Probe Architecture .................................................................................. 16 Importance of High Quality Rules Files .................................................. 20

2.2

Netcool/Knowledge Library and Include Files Structure .......................... 21
2.2.1 2.2.2 Netcool/Knowledge Library architecture................................................. 21 Structure of the SNMP Base Rules Files................................................ 23

ii

2.2.3 2.2.4 2.2.5 2.2.6 2.2.7

Developing SNMP Include Rules Files................................................... 24 Structure of the TL1 Base Rules Files.................................................... 26 Developing TL1 Include Rules Files ....................................................... 28 Structure of the Syslog Base Rules Files ............................................... 29 Developing Syslog Include Rules Files .................................................. 31

2.3 2.4

Standalone Rules Files Structure ............................................................ 32 Delivering the Basic 3 Functionality......................................................... 32
2.4.1 2.4.2 2.4.3 Basic 3 implementation and associated automations ............................ 32 ObjectServer alerts.status Table ............................................................ 36 Rules Files Standards............................................................................. 38

2.5 2.6 2.7

Rules Files Best Practices, Do and Don’t ................................................ 49 Rules Files Frequently Asked Questions (FAQ) ...................................... 51 Rules Files Check List ............................................................................. 53
2.7.1 2.7.2 Overall Rules Files Readability and Content .......................................... 53 ObjectServer Fields Assignment ............................................................ 53

2.8 2.9 3

Rules Files Examples .............................................................................. 55 Documenting a Rules Files Based Integration......................................... 56

Creation of a Tivoli Netcool/OMNIbus Tool ......................................................... 57 3.1 3.2 3.3 3.4 3.5 Tool Function and Architecture................................................................ 57 Tool Creation Best Practices, Do and Don’t ............................................ 58 Tools Frequently Asked Questions (FAQ) ............................................... 59 Tool Creation Check List ......................................................................... 60 Tool Examples ......................................................................................... 60

iii

..................................................................................................... 66 Appendix: Glossary of Terms .2 4.... 62 Automation Creation Best Practices................. 60 External Effect Tool Example ............................................................................................. 62 4................................................. 65 5 Integration Submission Packaging ............................................................... Do and Don’t ...........................6 Automation Function and Architecture.......6 4 Documenting a Tool Based Integration ............................................. 63 Automation Creation Check List ............................................................ 61 Creation of a Tivoli Netcool/OMNIbus Automation ........... 61 3................. x iv ......................................................................................................................... vi References ...........3.............................. 66 5......... 63 Automation Frequently Asked Questions (FAQ)...........................................1 3...................... 64 Documenting an Automation Based Integration ........ 66 Files Names.............................5............................................ 64 Automation Examples............................5 4............................1 4................................2 Archiving tool .............2 Internal Effect Tool Example................................................1 5.......3 4............5...........................4 4....

............................... 23 Logical flow of the TL1 TSM base rules files................................................... 7 Event Information and Alert Details...... 10 Probe in the Tivoli Netcool/OMNIbus architecture ................................................................................................................ 29 v .............................................................................................................................................................................. 3 Tivoli Netcool/OMNIbus Integration Option Architecture ............ 26 Logical flow of the Syslog Probe base rules files .....LIST OF FIGURES Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 CCAI Methodology ............................ 2 Tivoli Netcool/OMNIbus Overall Architecture............................................................................. 19 Logical flow of the SNMP probe base rules files..................... 15 Processing of the events at the probe and rules files level.......................................................

............................................................................................................................ 36 vi .......... 9 Structure and purpose of NcKL and NcKL Lite directories .............. 22 Alerts..........................................................LIST OF TABLES Table 1 Table 2 Table 3 Rules Files Editor Examples .........Status Schema..................

0 Revised By MSE Comments Initial version Mylene Stolpe-Evras May 2007 1.REVISION HISTORY Date March 2007 Version 1.1 JAR Updated name and title. publish to OPAL. vii .

Through Netcool/OMNIbus’ real-time monitoring. and highly available. network management applications and frameworks. the core component of Tivoli Netcool/OMNIbus. Netcool/Webtop provides an additional Webbased desktop. Windows systems. Tivoli Netcool/OMNIbus can also consolidate information from different domain-limited network management platforms in remote locations. 1 . you can prioritize events according to the business services they could potentially impact. Tivoli Netcool/OMNIbus presents this consolidated information in a meaningful. The chapter also provides guidelines to set up the Tivoli Netcool/OMNIbus integration development environment. Netcool Probes & Monitors collect fault messages throughout the network and forward them in a common format to the Netcool ObjectServer for further processing and filtering. mainframes. You can react to events in real-time and see them in color-coded severity through Netcool EventLists. The Netcool ObjectServer.1 Tivoli Netcool/OMNIbus Architecture and Overview Tivoli Netcool/OMNIbus is at the core of the Netcool suite of software. UNIX applications. The primary user interface is the Native Desktop where Event Lists are displayed. IP routers. among many others. The event list console shows events grouped into categories. each linked to an event list showing details of events in that category. and for display and management in customizable operator views. or monitor the availability of business services using service-level histogram summaries. circuit switches. point-and-click format and provides information of interest to specific users through individually configurable filters and views. scalable. These environments include servers.1 Getting Started The “Getting Started” chapter provides an overview of Tivoli Netcool/OMNIbus and its integration methods and associated interfaces. is a high-speed memory-resident database that acts as a centralized data repository for the fault information collected from the network infrastructure. you can address problems before they cause disruptions in service. voice switches. 1. intuitive. Using a point-and-click interface. SNMP devices. thereby supporting continuity of business operations with architectures that are responsive. The Tivoli Netcool/OMNIbus application focuses primarily on fault and event management. a carrier-class service and business assurance system. It collects and consolidates events and alarms from a wide variety of networking environments in real-time.

most scalable event processing engine COLLECT Industry’s broadest coverage across business and IT data sources Service VoIP Application System Network Web Transactions CRM Wireless Cable Hosting OSS ERP DSL Data Centers 1000+ UNIQUE EVENT AND DATA SOURCES Figure 1 CCAI Methodology Tivoli Netcool/OMNIbus provides technology support at each CCAI Tier. and Inform (CCAI™) methodology. NETCOOL® BUSINESS AND SERVICE Executive Customer Workflow Operations INFORM Realtime active dashboards and trended reporting views ANALYZE & AUTOMATE Dynamic service modeling. data enrichment. Consolidate. Netcool solutions and Tivoli Netcool/OMNIbus in particular use a powerful Collect. 2 . and problem CONSOLIDATE Industry’s fastest. The figure below shows the overall architecture. as depicted in the figure below.Getting Started Fundamentally. Analyze & Automate.

Getting Started Figure 2 Tivoli Netcool/OMNIbus Overall Architecture 3 .

1. The events formatted by the rules files should be compatible with the "GenericClear” automation whenever possible. it doesn’t define criteria for technical validation. Please refer to the Ready for IBM Tivoli Software Product Requirements Document (PRD) for an exhaustive list of requirements and validation criteria.e.Getting Started 1. • • • • • • 4 . no additional event fields other than the default fields provided in Tivoli Netcool/Omnibus) The basic structure of the files should be easy to maintain and easily extendible. The goals and objectives of the rules file development are listed below: • • The rules files created should be of production quality and provide "out-of-the-box" value.2 Tivoli Netcool/OMNIbus Integration Methods and Interfaces Alert: While this section presents the Tivoli Netcool/OMNIbus integration methods and interfaces options. The structure of the rules file should be as efficient as possible to maximize throughput of events.1 Creation of a Tivoli Netcool/OMNIbus Rules Files The rules file defines how the probe should process event data it receives in order to create a meaningful Tivoli Netcool/OMNIbus alert. The rules files should be sufficiently documented to allow each event to be understood without additional documentation. The events formatted by the rules files should be "deduplicated" properly by the Tivoli Netcool/OMNIbus ObjectServer. The rules files should not require any modifications to the ObjectServer (i. enabling the quick addition of event handling for new devices without affecting existing rules.2. Basic textual-conventions for the rules files should be determined and followed to ensure rules files created by different persons share a common format.

1.e. Tools can be grouped in tools menus. the probe will read the core NcKL rules files which will ‘call’ (i. Each tool has an associated SQL statement (called an internal effect).Getting Started At the minimum. and user based. Please refer to the following chapter for further information on the structure of both methods. an executable (called an external effect). 5 . TL1 or Syslog integration can be created using one of the following methods: • • Development of a standalone rules files which will be the only rules files read by the probe at start time. They can be restricted by both Class and Group. Tools are created independently of menus. which can then be associates with a class or classes of alert. This allows the tools to be event sensitive.2 Creation of a Tivoli Netcool/OMNIbus Tool Tools allow the control of alert management functions within Tivoli Netcool/OMNIbus from the EventList. the completed rules files should provide the following basic functionality (the ‘Basic 3’): • • • Automated deduplication of events and alarms in the Tivoli Netcool/OMNIbus ObjectServer Automated 'Generic Clear' correlation of problem/ resolution events Informative and descriptive event presentation in Tivoli Netcool/OMNIbus ObjectServer For the purpose of this integration. At start time. a Tivoli Netcool/OMNIbus rules files can be created for one of the standard-based probes (the SNMP. include) the device-specific or application-specific rules files written to process the information received from the products to be integrated. TL1 or Syslog probes). An SNMP. so a global set of tools can be used on different menus. Development of include rules files which will be added to an already-existing library of rules files called the Netcool Knowledge Library (NcKL).2. or both.

This gives the ability to launch other applications or run UNIX commands. Use field values from an event Use variables from the OS environment or those stored in the ObjectServer Can add a journal entry to track changes. procedures and/or user-defined signals. or forced. Use field values from an event Use variables from the OS environment or those stored in the ObjectServer 6 . These can be optional.3 Creation of Tivoli Netcool/OMNIbus Automations Tivoli Netcool/OMNIbus automations provide automatic management of events in the ObjectServer. a Tivoli Netcool/OMNIbus tool can be created for the Netcool/Desktop which is the proprietary client interface into Tivoli Netcool/OMNIbus (a. For the purpose of this integration. Automations can: • • • • • • • Perform external command(s) automatically on the receipt of certain events. 1. The automation will detect pre-defined changes in the ObjectServer and execute automated responses to these changes.2.k. This gives the ability to launch other applications or run UNIX commands. Execute an external command on UNIX or Windows platforms. Native Desktop) and/or for Netcool/Webtop which is considered the web-based version of the Netcool/Desktop. Incorporate escalation procedures.a. Automations can consist of triggers. Execute SQL statements internally on the events stored in the ObjectServer.Getting Started Tools can: • • • • • • • Execute an external command on UNIX or Windows platforms. Execute SQL statements internally on the events stored in the ObjectServer. This enables the ObjectServer to process many alerts without requiring an operator to take action. Run an executable Gather more information from the user through the use of Prompts. Allow correlation of events.

4 Tivoli Netcool/OMNIbus Integration Option Architecture Figure 3 Tivoli Netcool/OMNIbus Integration Option Architecture 7 .Getting Started • Add a journal entry to track changes. For the purpose of this integration. 1. Tivoli Netcool/OMNIbus automation(s) can be created in the ObjectServer.2.

3 Tivoli Netcool/OMNIbus Integration Development Environment Alert: This section provides an overview and guidelines of the Tivoli Netcool/OMNIbus environment that can be set up to enable the development of Tivoli Netcool/OMNIbus integration. 8 .Getting Started 1. The Ready for IBM Tivoli development team will then make the Tivoli Netcool/OMNIbus software available for download.3. The aim of this section is not to replace the study of the Tivoli Netcool/OMNIbus product manuals or the attendance of Tivoli Netcool/OMNIbus trainings.1 Tivoli Netcool/OMNIbus Software and Required Components Business Partners with an active PartnerWorld membership will be contacted by the Ready for IBM Tivoli development team after having nominated their products/ solution for the IBM Tivoli Open Process Automation Library (OPAL) catalog. At a minimum you will need the following Tivoli Netcool/OMNIbus components: • • • • • • • One Object Server One desktop (Native Desktop or Netcool/Webtop) One Probe (at minimum) Licenses Manager License file(s) for all installed components Tivoli Netcool/OMNIbus Product Manuals Netcool/Knowledge Library (for rules files based integrations using the library) For the most comprehensive set of software and hardware requirements please refer to the Tivoli Netcool/OMNIbus Supported Platforms and Requirements section of the Tivoli Netcool/OMNIbus Installation and Deployment Guide. 1. both being highly encouraged.

please refer to: Tivoli Netcool/OMNIbus Installation and Deployment Guide. For details on Netcool licensing please refer to: Overview of Netcool Licensing 1.3 Rules Files Editor The rules files can be edited by any text editor that can leave the file in a Unix readable format.2 Tivoli Netcool/OMNIbus Software Installation and Licensing To install Tivoli Netcool/OMNIbus.3.3. Table 1 Rules Files Editor Examples Platform Unix Unix Unix Windows Windows Editor Examples Vi Emacs Gedit Notepad Programmers File Editor (PFE32) 9 .Getting Started 1.

These details can be viewed by double-clicking an event in the event list. 10 .3. Figure 4 Event Information and Alert Details Details are added to the ObjectServer details table using the details statement. but not if an event is being deduplicated. By default all events have no details information added. Details are extra tokens created by the probe from the event stream. The ObjectServer details table (alerts. which are not used to propagate a field value. These details must be defined at the probe level. They are only added when an event is inserted.4 Probe Configuration for Development and Testing Purposes The Details Statement In the event list it is possible to display details information for an event. and by selecting the “Details” tab.details) is used to store elements that are not added to the fields of the alert.Getting Started 1.

Raw capture mode is enabled using the command line option -raw or the probe property RawCapture. The ($*) function should only be used to debug or write rules files. This can be useful for auditing. use: details ($*) However. Data captured in raw capture mode is in a format that can be replayed by the generic probe: You can then re-use this file to replay the events.cap” 1 Command line option can also be used Example 11 . the ObjectServer tables will become too large and the performance of the ObjectServer will suffer. Here is an example of the RawCapture properties set for the mttrapd probe. You can even replay them off-line. recording and debugging the operation of a probe. That way there is no need to generate them again in your network to re-test the new version of your rules file.props file: Example RawCapture : RawCaptureFile : RawCaptureFileAppend : 1 “/opt/Omnibus/var/mttrapd. Raw Capture Mode and Events Replay The “Raw capture” mode of any probe allows you to save the complete stream of event data acquired and processed by a probe into a file. in the mttrapd. you would include the following statement in the rules file: details($a.Getting Started To add the elements $a and $b to the details table.$b) To add all of the event information into the details table. If ($*) is used for long periods of time. and to help you creating/testing a rules file. it is not recommended that you use ($*) in a production environment. it is actually recommended to use it in that matter and it is a very useful development tool.

with an easy mean to replay the live event at your fingertips. like the syslog probe you can make sure you won’t have the inconvenience of the “ . you should use the Standard Input (stdin) probe.props -rulesfile /opt/Omnibus/probes/solaris2/snmp. A possible syntax would be: cat <raw_capture_filename> | $OMNIHOME/probes/nco_p_stdin –server <server> -propsfile /opt/Omnibus/probes/<arch>/stdin.cap | /opt/Omnibus/probes/nco_p_stdin -server NCOMS -propsfile /opt/Omnibus/probes/solaris2/stdin. with the rules file you are creating.cap & Note for the SNMP probe: Make sure the QuietOutput property is set to 1 in the mttrapd. so the generic probe won’t parse correctly such a raw – which does not necessary mean that your rules file is not correct. you won’t have this case.rules -messagelevel debug & Example cat opt/Omnibus/var/mttrapd. and you will be able to get events in the object server as if they were received from the original source. The stdin probe does not probe any network management platforms or hardware. You can then work on the rules file. You may encounter cases where an element contains these “. To replay the raw events. in the syslog. by using the replay option of the probe. The stdin probe acquires raw data from the UNIX standard input.rules -messagelevel debug & Be aware that the generic probe uses “ ‘s for demarcation of input data.Getting Started /opt/Omnibus/probes/nco_p_mttrapd -raw –capturefile /opt/Omnibus/var/mttrapd.props file: Example ReplayFile : 1 Command line option can also be used: Example /opt/Omnibus/probes/nco_p_syslog –server NCOMS –replayfile On & 12 . instead of getting the raw capture and replaying them with the generic probe. Most of the time.props while running it in raw capture mode. If you are running a Log File type probe. Here is an example of the Replay property set for the syslog probe.props -rulesfile /opt/Omnibus/probes/<arch>/<probe>.

This methodology is more efficient than running a real probe to test the syntax of a rules file. If no errors are displayed. To enable debug mode on the command line. You can set the probe to run in debug mode in two ways: on the command line. The following example shows the format of the syntax probe: Example nco_p_syntax –rulesfile /opt/Omnibus/probes/solaris2/syslog. the syntax of the rules file is correct. tests the rules files. enter the command: Example $OMNIHOME/probes/<arch>/<probename> -messagelevel DEBUG messagelog STDOUT Alternatively enter the following in the properties file: Example MessageLevel: “DEBUG” MessageLog: “STDOUT” 13 . displays any errors to the screen and then exits. The syntax probe connects to the ObjectServer.Getting Started Testing Rules Files Syntax The syntax of a rules file can be tested using the syntax probe: nco_p_syntax. Debugging Rules Files When making changes to the rules file. This will show exactly how an event is being parsed by the probe.rules The syntax probe always runs in debug mode. and any possible problems with the rules file. or in the properties file. adding new rules or creating lookup tables it is useful to test the probe by executing it in debug mode.

3.jsp IBM Tivoli Training for Netcool http://www-306.5 Additional Resources IBM Tivoli Netcool Documentation http://publib. 1.developer.html IBM Software Access Catalog http://www.com/infocenter/tivihelp/v8r1/index.boulder.ibm.html 14 .com/welcome/softmall.ibm.Getting Started If the MessageLog option is omitted. the debug information is sent to the probe’s log file in the $OMNIHOME/log directory rather than the screen.com/software/tivoli/welcome/micromuse/education.ibm.

the basic 3 functionality are described and each of the ObjectServer fields required to enable these functionalities are reviewed in details. within the rules file. 2.Creation of Tivoli Netcool/OMNIbus Rules Files 2 Creation of Tivoli Netcool/OMNIbus Rules Files This chapter provides an overview of probes and rules files function and architecture. Guidelines are provided for the development of standalone rules files. Probes connect to an event source.status. The structure of the Netcool/Knowledge Library (NcKL) is then outlined in more details and the structure of the SNMP. which together make up the event. Last but not least.1 Probe and Rules Files: Function and Architecture 2. The Rules Files Standard that needs to be applied for the population of each identified field is provided along with meaningful examples and guidelines. which is the alternative rules files structure to NcKL. detect and acquire events. The probe uses a rules file to propagate the field values within alerts. to the event and mathematical calculations can be carried out. Figure 5 Probe in the Tivoli Netcool/OMNIbus architecture 15 .1. The figure below shows how probes fit into the Tivoli Netcool/OMNIbus architecture. TL1 and Syslog base files are presented. and then forward them to the ObjectServer. Extra information can also be added. When the probe receives a data stream it splits the stream into individual tokens.1 Introduction A probe is an application that acquires data from an event source.

16 . It manages the connection to the event source. the acquisition of events and the forwarding of events to the ObjectServer. it can read the event source and forward events to the ObjectServer.status Add extra information to the event Carry out mathematical calculations 2. Using the contents of these files. The first thing a probe executable file does when it is run is to configure its environment. for example: Example $OMNIHOME/probes/solaris2/nco_p_mttrapd This example shows where the Solaris2.x executable of the mttrapd probe is stored. the executable file can define how it should control the connection between the event source and the ObjectServer. where arch is the name of the architecture. To do this it reads the contents of the properties and rules files.Creation of Tivoli Netcool/OMNIbus Rules Files A summary of the functions of a probe is as follows: • • • • • • Probes retrieve and send information It is through the probes that the ObjectServer obtains all the event data Probes tokenize event streams Propagate the field values within alerts. Once the rules file is correctly configured. All probe executable files are stored in the directory $OMNIHOME/probes/<arch>.2 Probe Architecture A probe is made up of three primary components: • • • an executable file a properties file a rules file The Executable File The executable file is the core of a probe.1.

Creation of Tivoli Netcool/OMNIbus Rules Files The Properties File The properties of a probe define the environment in which it will work. enter: Example $OMNIHOME/probes/nco_p_syslog -dumpprops You can change probe properties by editing the properties file using a text editor. For example. to display a list of the properties available from the command line for the Syslog probe. For example. the properties for the Solaris2. Example Server : “NCOMS” Where Server is the name of the property and NCOMS is the value the property is set to. enter: Example $OMNIHOME/probes/nco_p_syslog –help The -dumpprops command line option can be used to provide the extensive list of properties to be set in the property file.x version of the mttrapd probe are stored in the file: Example $OMNIHOME/probes/solaris2/mttraps. the “Server” property defines the server where the events will be sent to. For example. to display an extensive list of the properties available for use with the Syslog probe.props Properties files are formed of name-value pairs separated by a colon. For example. All of a probe’s properties are stored in a properties file. By default.props . with the extension . 17 . You can display a list of the generic and probe specific properties and command line options available for use with a specific probe by using the -help and –dumpprops command line option. all probe properties files are stored in the same directory as the executable file.

rules All the field values of alerts.rules .Creation of Tivoli Netcool/OMNIbus Rules Files The Rules File Not all of the data contained within an event is relevant to the processing of that event. 18 . all probe rules files are stored in the same directory as the executable file with the extension . Elements are identified within the rules file by the $ symbol. Example $OMNIHOME/probes/solaris2/syslog. it breaks it down into tokens. The probe then parses these tokens into elements. When the probe acquires raw data from the event source. Any changes made to the rules file will require the probe to be restarted or made to re-read the rules file (this is preferable.status are normally propagated by the rules file using the information from the incoming event. For example. The rules file defines how the probe should rationalize or add to the contents of an event to create a meaningful Tivoli Netcool/OMNIbus alert. You can force the probe to re-read the rules file by issuing a kill -HUP pid command on the probe process ID (PID). In addition. By default. because the probe will not lose events). $Node is an element containing the node name of the event source. Each token represents a piece of event data. the rules file creates a unique identifier for each event it acquires for deduplication purposes—the identifier field.

the unique @Identifier field is also generated. the field values contain the event details in the form used by the ObjectServer. for example: @Summary = $Node + “ has problem ” + $Summary Elements become details in the alert sent to the ObjectServer by using the details statement. At this stage. Example $newElem = "Here is a new detail field" 19 . For example. The probe then forwards the field values to the ObjectServer as a Tivoli Netcool/OMNIbus alert. There are three ways to assign elements to field values. Adding text. Concatenation. for example: @Node = $Node. @Node can be a field value containing the node name of the event source. which are: • • • Direct assignment. Field values are identified within the rules file by the @ symbol. for example: @Summary = $Summary + $Group.Creation of Tivoli Netcool/OMNIbus Rules Files Figure 6 Processing of the events at the probe and rules files level The probe processes the elements according to the rules in the rules file to assign values to the fields which are available in the ObjectServer. When they have been processed. The rules file allows you to create new elements dynamically.

among many. A well written rules file is an important part of the following. which is required for lookups/triggers in an Impact policy.Creation of Tivoli Netcool/OMNIbus Rules Files 2. the granularity of deduplication can be directly controlled. a large part of the functionality which customers expect from the Netcool Suite. In addition the readability of an event can be directly influenced by the rules file. • • • 20 .By properly setting the 'Identifier' field.Within the rules files the contents of ObjectServer fields can be determined which enable the use of Automations such as GenericClear.1. Rules files which are implemented within the Tivoli Netcool/OMNIbus Probes are responsible for providing. IBM Tivoli Netcool Software features: • Event Normalization .An event can be formatted in the rules files in such a way to allow/simplify the implementation of Tivoli Netcool/Impact. Event Correlation via Automations .The rules files enable a common event format to be implemented regardless of the management system or device which generated the event.3 Importance of High Quality Rules Files An important part of any IBM Tivoli Netcool Software implementation is a set of high quality rules files. This is accomplished by filing ObjectServer fields with the appropriate raw event data. Deduplication . or facilitating. Business Impact .

Directory /rules Description The base Netcool/Knowledge Library directory which contains the base rules files and other related files.1 Netcool/Knowledge Library architecture The following table provide the structure and purpose of the directory and content created as a result of the installation of NcKL or NcKL Lite.2. and highlight with an arrow ( ► ) the directory of most interest. decimal. /rules/include-compat 21 . the logical flow of the provided SNMP. ► This is the directory where the based files used in the context of this integration will be found.Creation of Tivoli Netcool/OMNIbus Rules Files 2.rules and syslog.rules is only available for NcKL Lite. Alert: snmptrap. 3GPP and TMF814 specific log.rules are installed for both the NcKL and NcKL Lite libraries where tl1. Once the directory structure is detailed. lookup table to help convert between hex. 2.2 Netcool/Knowledge Library and Include Files Structure This chapter outlines the overall structure of the Netcool/Knowledge Library and the Netcool/Knowledge Library Lite and provides details on the structure and location of the files of the library that are of most interest in the context of a rules files based integration project. /rules/include-common Contains include files that provide probeindependent logic – for example. and ASCII. Syslog and TL1 base files is described. Contains include files to activate support for various Netcool/Knowledge Library features. Then this chapter focuses on providing the basic structure of the include files specifically developed for the purpose of this integration project. These based files should be edited to add the necessary include statement that will ’call’ the include files developed for this integration.

/rules/include-syslog/regmatch Contains include files that use regular expressions or other matching techniques to make a best guess at the source of an event received by the Syslog-based probe. ► This is the directory where the TL1-based include files created in the context of this integration should be located. ► This is the directory where the Syslog-based regmatch include files created in the context of this integration should be located. Note that this includes the Windows version of the Syslog Daemon probe (nco_p_syslogd. Any other rules files to be used by the probe must be loaded via include statements from this rules file. ► This is the directory where the SNMP-based generic include files created in the context of this integration should be located.Creation of Tivoli Netcool/OMNIbus Rules Files Directory /rules/include-snmptrap Description Contains include files for processing events from the SNMP trap-based probes.exe). Table 2 Structure and purpose of NcKL and NcKL Lite directories The SNMP and the Syslog probes as well as the TL1 TSM are designed to load a single rules file. 22 . ► This is the directory where the SNMP-based include files created in the context of this integration should be located. ► This is the directory where the Syslog-based include files created in the context of this integration should be located. /rules/include-syslog Contains include files for processing events from the Syslog-based probes.exe). but does not include the Winsyslog probe (nco_p_winsyslog. /rules/include-snmptrap/generic Contains SNMP trap-based include files that improve the handling of enterprise-specific implementations of the generic SNMP traps. The single rules file loaded by the probe is referred as the “Base Rules File”. /rules/include-tl1/ Contains TL1-based include files for processing autonomous messages received by the TL1 TSM.

Assigns default probe-specific values to the necessary ObjectServer fields.2 Structure of the SNMP Base Rules Files The base rules file for the SNMP Probe contains logic that meets the following requirements and recommendations: • • • • • • Provides the basic logic and structure necessary to implement a chosen strategy for including vendor or MIB specific rules files. Performs pre-processing of tokens to adjust for differences in various versions of the SNMP Probe Normalizes tokens produced for SNMPv1 and SNMPv2 traps. Begin Set Default Values Include Lookup Files Pre-process Tokens Probe Watch? No Yes Handle ProbeWatch Normalize Tokens Generic Trap? Yes Handle Probes Generic Traps No Include Vendor Rules Files End Figure 7 Logical flow of the SNMP probe base rules files 23 . Handles generic traps.2. The following figure shows the simplified logical flow of a base rules file for the SNMP probe. Handles ProbeWatch messages.Creation of Tivoli Netcool/OMNIbus Rules Files 2.

the enterprise and specific trap number can be considered to determine which rules file logic is applicable to the trap. These case statements are written as individual include files which are added to the base rules file using the include statement. the enterprise-specific traps are handled based on the enterprise and specific trap number of the trap. These segments are created as individual (include) rules files. A switch statement is then used against the $enterprise token.2. 24 .3 Developing SNMP Include Rules Files In the SNMP base rules file. which are then ‘included’ into the base file.rules" ############################################################ include "<<<PATH TO INCLUDE FILE>>>" include "<<<PATH TO INCLUDE FILE>>>" ############################################################ # End of rules file Includes ############################################################ default: @Summary = "Enterprise ID Not Found (see details): " + $enterprise + " " + $generic-trap + " " + $specific-trap @Severity = 2 @Type = 0 @Identifier = @Node + " " + $enterprise + " " + $generic-trap + " " + $specific-trap + " " + @AlertGroup + " " + @AlertKey + " " + @Agent + " " + @Manager details($*) } 2. These include files dedicated to the enterprisespecific traps are the integration rules files that can be packaged and submitted to validation. with corresponding case statements for each enterprise covered by the rules. one segment for each enterprise.include. This is accomplished by first using a switch/case statement to organize the rules file into segments. The include files would essentially be the case statements for the switch ($enterprise) statement: switch($enterprise) { case "dummy case statement": ### This will prevent syntax errors in case no includes are added below. ############################################################ # Enter rules file Includes below with the following syntax: # # include "$NC_RULES_HOME/include-snmp/<rulesfile>.Creation of Tivoli Netcool/OMNIbus Rules Files Once the incoming trap has traversed the SNMP file up to the point where it has been identified as an enterprise-specific trap.

Also. or include file. a default processing of the incoming event should be implemented to ensure no events are ignored. switch/case statements should be used to organize the rules file code necessary for each individual trap definition: case "<<<ENTERPRISE OID>>>": @Agent = "<<<VENDOR-DEVICE/SYSTEM>>>" @Class = "<<<CLASS>>>" switch ($specific-trap) { case "1": <<<RULES LOGIC FOR SPECIFIC TRAP 1>>> case "2": <<<RULES LOGIC FOR SPECIFIC TRAP 2>>> default: @Summary = "Unknown Specific Trap Number (" + $specific-trap + ") Received for Enterprise " + $enterprise @Severity = 1 @Identifier = @Node + " " + @Agent + " " + @Manager + " " + $enterprise + " " + $generic-trap + " " + $specific-trap details($*) } Alert: In order to pass the technical validation. even if they didn’t match the expected format. 25 .Creation of Tivoli Netcool/OMNIbus Rules Files Within each such segment. No MIB should be left unsupported and no specific trap should be left aside. even if they didn’t match the expected format. a default processing of the incoming event should be implemented to ensure no events are ignored. a rules file based integration for a certain product and release MUST support ALL traps for ALL enterprisespecific MIBS supported by the product and release in question. Also.

a. The base rules file for the TL1 TSM contains logic that meets the following requirements and recommendations: • • • • Provides the basic logic and structure necessary to implement a chosen strategy for including vendor TL1 autonomous messages specific rules files.4 Structure of the TL1 Base Rules Files Alert: The TL1 base rules files and associated directory structure are ONLY available in the Netcool Knowledge Library Lite (a.e.Creation of Tivoli Netcool/OMNIbus Rules Files 2. and is not included in the full version of NcKL. Handles TSMWatch messages. in NcKL Lite) or be merged in the full version of NcKL.k.2. NcKL Lite). Assigns default probe-specific values to the necessary ObjectServer fields. The TL1 potion of the logic and directory structure of the NcKL Lite can either be used as is (i. Performs pre-processing and normalizations of tokens Begin Set Default Values Include Lookup Files Pre-process Tokens TSM Watch? No Yes Handle TSMWatch Normalize Tokens Include Vendor Rules Files End Figure 8 Logical flow of the TL1 TSM base rules files 26 .

This is accomplished by first using a switch/case statement to organize the rules file into segments. the SourceID and the Network Element Type (NEType) of the incoming event can be considered to determine which rules file logic is applicable to the message.include. one segment for each NEType. The include files would essentially be the case statements for the switch ($NEType) statement: switch(lookup($SID.rules" ################################################################### include "<<<PATH TO INCLUDE FILE>>>" include "<<<PATH TO INCLUDE FILE>>>" include "<<<PATH TO INCLUDE FILE>>>" ################################################################### # End of rules file Includes ################################################################### default: $Supported = "No" } 27 . which are then ‘included’ into the base file.Creation of Tivoli Netcool/OMNIbus Rules Files Once the incoming autonomous message has traversed the TL1 file up to the point where it has been identified as a vendor or device specific message. These segments are created as individual (include) rules files. ################################################################### # Enter rules file Includes below with the following syntax: # # include "$NC_RULES_HOME/include-tl1/<rulesfile>. NEType)) { case "DUMMY CASE STATEMENT": ### This will prevent syntax errors ### in case no includes are added below.

Also. with corresponding case statements for each Network Element Type (NEType) covered by the rules. switch/case statements should be used to organize the rules file code necessary for each individual NEType: case "<<<NEType>>>": @Agent = "<<<VENDOR-DEVICE/SYSTEM>>>" @Class = "<<<CLASS>>>" Switch ($Verb + " " + $Modifier1) { case "REPT ALM": <<<RULES LOGIC FOR REPT ALM autonomous messages>>> case "REPT EVT": <<<RULES LOGIC FOR REPT EVT autonomous messages>>> case "REPT DBCHG": <<<RULES LOGIC FOR REPT DBCHG autonomous messages>>> default: <<<default RULES LOGIC>>> } Alert: In order to pass the technical validation. A NEType lookup table is used to define the type (i. These include files dedicated to the vendor and devices specific autonomous messages are the integration rules files that can be packaged and submitted to validation. vendor and/or model) of each Network Element that the TL1 TSM will connect to based on the SID. Within each such segment.2. a rules file based integration for a certain product and release MUST support ALL autonomous messages supported by the product and release in question.5 Developing TL1 Include Rules Files In the TL1 base rules file. These case statements are written as individual include files which are added to the base rules file using the include statement. A switch statement is then used against the $SID token. or include file. 28 . the vendor and devices specific autonomous messages are handled based on the Source ID (SID) of the message.Creation of Tivoli Netcool/OMNIbus Rules Files 2.e. even if they didn’t match the expected format. a default processing of the incoming event should be implemented to ensure no events are ignored.

the Source Key (SrcKey.6 Structure of the Syslog Base Rules Files The base rules file for the Syslog probe contains logic that meets the following requirements and recommendations: • • • • Provides the basic logic and structure necessary to implement a chosen strategy for including vendor syslog messages specific rules files. Handles ProbeWatch messages.2. Assigns default probe-specific values to the necessary ObjectServer fields. Performs pre-processing and normalizations of tokens Begin Set Default Values Include Lookup Files Pre-process Tokens Probe Watch? No Yes Handle ProbeWatch Normalize Tokens Include Vendor Rules Files End Figure 9 Logical flow of the Syslog Probe base rules files Once the incoming syslog message has traversed the syslog file up to the point where it has been identified as a vendor or device specific syslog message.Creation of Tivoli Netcool/OMNIbus Rules Files 2. usually the Node) and the SourceType (SrcType) of the incoming event can be 29 .

include. one segment for each SrcType. ################################################################### # Enter rules file Includes below with the following syntax: # # include "$NC_RULES_HOME/include-syslog/<rulesfile>. This is accomplished by first using a switch/case statement to organize the rules file into segments. which are then ‘included’ into the base file.rules" ################################################################### include "<<<PATH TO INCLUDE FILE>>>" include "<<<PATH TO INCLUDE FILE>>>" include "<<<PATH TO INCLUDE FILE>>>" ################################################################### # End of rules file Includes ################################################################### default: @AlertGroup = "[Generic Syslog]" @AlertKey = "" @Summary = $Details @Severity = 1 @Type = 1 @Identifier = @Node + " " + @AlertGroup + " " + @Manager + " " + $Details details($*) } 30 .Creation of Tivoli Netcool/OMNIbus Rules Files considered to determine which rules file logic is applicable to the message. The include files would essentially be the case statements for the switch ($SrcType) statement: switch($SrcType) { case "dummy case statement": ### This will prevent syntax errors ### in case no includes are added below. These segments are created as individual (include) rules files.

These case statements are written as individual include files which are added to the base rules file using the include statement. Within each such segment. A switch statement is then used against the $SrcType token. even if they didn’t match the expected format. vendor and/or model) of each source from which the syslog probe is receiving the syslog messages.7 Developing Syslog Include Rules Files In the Syslog base rules file. switch/case statements should be used to organize the rules file code necessary for each individual SrcType: case "<<<SrcType>>>": @Agent = "<<<VENDOR-DEVICE/SYSTEM>>>" @Class = "<<<CLASS>>>" <<<RULES LOGIC for syslog messages from SrcType>>> Alert: In order to pass the technical validation. the vendor and devices specific syslog messages are handled based on the Source Key (SrcKey) of the message which is usually derived from the Node.Creation of Tivoli Netcool/OMNIbus Rules Files 2. 31 . based on the SrcKey.e. the type (i. A SrcType lookup table is used to define. a default processing of the incoming event should be implemented to ensure no events are ignored. Also.2. a rules file based integration for a certain product and release MUST support ALL syslog messages supported by the syslog interface of the product and release in question. or include file. with corresponding case statements for each Source Type (SrcType) covered by the rules. These include files dedicated to the vendor and devices specific autonomous messages are the integration rules files that can be packaged and submitted to validation.

1 Basic 3 implementation and associated automations At the minimum. even if they didn’t match the expected format.4 Delivering the Basic 3 Functionality 2.1 of this document (Creation of a Tivoli Netcool/OMNIbus Rules Files). a rules file based integration for a certain product and release MUST support messages supported by the interface of the product and release in question. Also.4.2. 2. a default processing of the incoming event should be implemented to ensure no events are ignored.Creation of Tivoli Netcool/OMNIbus Rules Files 2. the developed rules files should provide the following basic functionality (the ‘Basic 3’): • • • Automated deduplication of events and alarms in the Tivoli Netcool/OMNIbus ObjectServer Automated 'Generic Clear' correlation of problem/ resolution events Informative and descriptive event presentation in Tivoli Netcool/OMNIbus ObjectServer 32 . Alert: In order to pass the technical validation.3 Standalone Rules Files Structure While the structure of a standalone rules file is free. it must adhere to the goals and objectives of the rules file development as defined in chapter 1.

status for each row begin set old.LastOccurrence.Tally + 1. end if. The deduplication automation is provided in the ObjectServer by default.Severity > 0)) then set old. set old. set old. set old.status table.LastOccurrence = new.InternalLast = getdate().Severity = new.AlertKey.Creation of Tivoli Netcool/OMNIbus Rules Files Deduplication Automation The ObjectServer database trigger to deduplicate the alerts.Summary. intercepts an attempted reinsert on the alerts.AlertKey = new.Severity = 0) and (new. if ((old. set old. commonly referred as the “Deduplication automation”.status table and increments the tally to show that a new row of this kind has arrived at the ObjectServer. set old.STATUS' before reinsert on alerts. It also sets the LastOccurrence field. out of the box and consists in the following: create or replace trigger deduplication group default_triggers priority 1 comment 'Deduplication processing for ALERTS.Tally = old. 33 . end.StateChange = getdate().Summary = new.Severity.

LastOccurrence date. go create or replace trigger generic_clear group default_triggers priority 1 comment 'Generic Problem/Resolution' every 5 seconds begin -.status where problem.Severity > 0 and (problem. problem.LastOccurrence. Manager varchar(64).status where Severity > 0 and Type = 2 ) begin insert into alerts.Identifier. problem. The GenericClear automation is provided in the ObjectServer by default.Manager. problem. false ). end.Populate a table with Type 1 events corresponding to any uncleared Type 2 events for each row problem in alerts.Node. out of the box and consists in the following: -. Resolved boolean ).A workspace table for the generic clear automation create table alerts. Node varchar(64).AlertKey.Manager) in ( select Node + AlertKey + AlertGroup + Manager from alerts. commonly referred as the “Generic automation”.problem_events values ( problem.AlertGroup + problem. AlertKey varchar(255). AlertGroup varchar(64).status table.AlertKey + problem.AlertGroup. 34 . problem.Node + problem.Creation of Tivoli Netcool/OMNIbus Rules Files Generic Clear Automation The ObjectServer database trigger to correlate the problem and resolution events in the alerts.Type = 1 and problem.problem_events virtual ( Identifier varchar(255) primary key. problem.

Manager and Node = resolution.Remove all entries from the problems table delete from alerts. go Alert: Your integration should NOT alter in any way the deduplication and the generic clear automations.Type = 2 and resolution.status via problem. end. -.status where resolution. Any required customization should be performed at the rules files level as much as possible.AlertGroup . -.Severity > 0 begin set resolution. then create a new automation without altering any of the default one. 35 .problem_events where problem. end.problem_events set Resolved = true where LastOccurrence < resolution.problem_events. update alerts.Creation of Tivoli Netcool/OMNIbus Rules Files -.For each resolution event. mark the corresponding problem_events entry as resolved and clear the resolution for each row resolution in alerts.Resolved = true begin update alerts.AlertKey and AlertGroup = resolution.Severity = 0. and if you need to customize an already existing automation or to create a new automation for the purpose of your integration.Identifier set Severity = 0.Node and AlertKey = resolution. end.Clear the resolved events for each row problem in alerts.LastOccurrence and Manager = resolution.

The alerts.2 ObjectServer alerts.Creation of Tivoli Netcool/OMNIbus Rules Files 2.status Table Alert information is forwarded to the ObjectServer from the probes or TSMs. The Alerts. and displayed in the event list.Status fields are listed in the table below.Status Schema Field Name Identifier Serial Node NodeAlias Manager Agent AlertGroup AlertKey Severity Summary StateChange FirstOccurrence LastOccurrence InternalLast Poll Type Tally Class Grade Location OwnerUID OwnerGID Acknowledged Flash ServerName Data Type Varchar(255) Incr Varchar(64) Varchar(64) Varchar(64) Varchar(64) Varchar(64) Varchar(255) Int Varchar(255) Time Time Time Time Int Int Int Int Int Varchar(64) Int Int Int Int Varchar(64) 36 . Table 3 Alerts.status ObjectServer table contains status information about problems that have been detected by the probes or the TSMs.4. stored and managed in database tables.

Creation of Tivoli Netcool/OMNIbus Rules Files Field Name ServerSerial EventId ExpireTime ProcessReq SuppressEscl Customer Service PhysicalSot PhysicalPort PhysicalCard TaskList NmosSerial NmosObjInst NmosCauseType LocalNodeAlias LocalPriObj LocalSecObj LocalRootObj RemoteNodeAlias RemotePriObj RemoteSecObj RemoteRootObj X733EventType X733ProbableCause X733SpecificProb X733CorrNotif MasterSerial URL Data Type Int Varchar(64) Int Int Int Varchar(64) Varchar(64) Int Int Varchar(64) Int Varchar(64) Int Int Varchar(64 Varchar(255) Varchar(255) Varchar(255) Varchar(64) Varchar(255) Varchar(255) Varchar(255) Int Int Varchar(64) Varchar(255) Int Varchar(1024) 37 .

4. The Identifier field controls the deduplication feature of the ObjectServer. as well as supports compatibility with the GenericClear automation by ensuring “resolution” events are properly inserted into the ObjectServer and not deduplicated with their respective “problem” events. Standard When the guidelines are followed for the other fields mentioned in this document the starting point for the assignment of the Identifier field should be as follows: @Identifier = @Node + “ “ + @AlertKey + “ “ + @AlertGroup + “ “ + @Type + “ “ + @Agent + “ “ + @Manager It may also be necessary to append additional information to the Identifier field to ensure proper deduplication and compatibility with the GenericClear automation.Creation of Tivoli Netcool/OMNIbus Rules Files 2. Example For an SNMP specific trap which contains a “status enumeration value” in one of its variable bindings (bgpBackwardTransition is a good example. Only those fields are addressed below which are part of the default Tivoli Netcool/OMNIbus ObjectServer. Internal hash key/table identifier.3 Rules Files Standards The following describes in further detail the intended use of the ObjectServer fields to ensure a consistent normalization of events as well as proper deduplication and compatibility with the GenericClear automation. the specific trap number and value of the relevant varbind should be appended to the Identifier field as follows: @Identifier = @Node + “ “ + @AlertKey + “ “ + @AlertGroup + “ “ + @Type + “ “ + @Agent + “ “ + @Manager + “ “ + $specific-trap + “ “ + $2 38 . BgpPeerState is the 2nd variable binding). Identifier .varchar(255) Required ObjectServer Field.

• NodeAlias . Standard • IP Devices – For IP network devices or hosts the Node field contains the “resolved name” of the device or host. A good example would be a device managed via TL-1.Creation of Tivoli Netcool/OMNIbus Rules Files Node . the Node field should contain a name for the device that either directly allows. or can be resolved to allow.varchar(64) Required ObjectServer Field. for direct communication with the device. For network devices or hosts this should be the logical (layer-3) address of the entity. i. 39 .e.g. Non-IP Devices – There are many possible addressing schemes that could be used for non-IP devices. Standard • • IP Devices – For IP devices or hosts this would the IP address. customer. Non-IP Devices – Alarms from non-IP devices should contain information equivalent to that of IP devices. This could be a host/device name. In cases where the name cannot be resolved the Node field should contain the layer-3 address (e. service name. The key to choosing a value for the NodeAlias field is that the value should allow for direct communication with the device. The Node field is used to identify the managed entity from which the alarm originated. Contains the Alias of the network entity referred to in the Node field.varchar(64) Default ObjectServer Field. The NodeAlias field could be filled via a lookup table and/or Netcool/Impact Policy with the IP address and port number of the terminal server through which the TL-1 device can be reached. or other logical address which enables direct communication with the device. or other entity. IP address) of the host or device.

The format should be: vendor-MIB description Example “Cisco-Accounting Control”. or MIB Definition Name. Agent = IETFBRIDGE. where the trap is defined. etc.). Standard • SNMP Trap-related Probes – Probes which process SNMP traps should set the Agent field to the name of the vendor or standards body which defined the trap as well as a description of the MIB. HP OpenView NNM. such as device model numbers. MTTrapd Probe on hostname). can be appended to the Agent field for vendor-specifc implementations of standard traps. “ATMF-ATM-FORUM-MIB” Optionally. Manager = MTTrapd Probe. “IETFBRIDGEMIB”.).Creation of Tivoli Netcool/OMNIbus Rules Files Manager . “Cisco-Health Monitor”. The Agent field contains a descriptive name of the submanager which generated the alert. Example An example would be Extreme’s implementation of generic traps. Example The following syntax can be used to set the Manager field: • @Manager = "MTTrapd Probe on " + hostname() Agent . Standard • The Manager field must contain a descriptive name of the Probe which collected and forwarded the alarm to the ObjectServer (Ex. HP OpenView NNM. Ideally this is set in the Probe’s properties file. The model of the device which sent the trap can be interpreted from the trap enterprise and appended to the Agent field as such: “Generic-Extreme Summit48i” NOTE: The vendor name specified in the Agent field should be consistent with that name which is registered with IANA for the traps Enterprise ID.varchar(64) Required ObjectServer Field. 40 . The Manager field should also contain the host on which the Probe is running (Ex. (Ex.MIB). vendor-specific information. and modify if necessary. etc. The Manager field contains a descriptive name of the Probe which collected and forwarded the alarm to the ObjectServer (Ex. but the Rules File should check to ensure it is set properly. MTTrapd Probe. MTTrapd Probe.varchar(64) Default ObjectServer Field.

CPU Utilization. Cisco defines messages from IOS-based devices in separate documentation to that of messages from the PIX Firewall. This field is important for proper correlation of events by the GenericClear automation. Example • Generic SNMP traps 2 and 3. 41 . should both contain the same AlertGroup value of “Link Status”. The format of the message differs slightly as well. linkDown and linkUp respectively. the TL-1 TSM should set the Agent field to the name of the vendor which defined the received message as well as any logical description for the family of messages to which the received message belongs. TL-1 TSM – Typically the AlertGroup field for a TL-1 message will be set to the value of the message’s “Alarm Type”.Creation of Tivoli Netcool/OMNIbus Rules Files • Syslog Probe – The Syslog Probe should set the Agent field to the name of the vendor which defined the received message as well as any logical description for the family of messages to which the received message belongs. The AlertGroup field contains a descriptive name of the type of failure indicated by the alarm (Ex.PIX Firewall”.varchar(64) Default ObjectServer Field. etc…). Standard • The AlertGroup field must contain the same value for “problem” and “resolution” events which are related to each other. Interface Status. • TL-1 TSM – Similar to the syslog probe. Example An example would be system log messages from Cisco. AlertGroup . So syslog messages from Cisco will have the Agent field set to either “Cisco-IOS” or “Cisco.

The disk partition indicated by a “file system full” alarm. in order of preference: o The SNMP instance of the managed object which is represented by the alarm. In other words. any 42 . See “Summary – varchar(255)” for more information. This is usually obtained by extracted the instance from the OID of one of the trap’s variable bindings. or the switch port indicated by utilization alarm).Creation of Tivoli Netcool/OMNIbus Rules Files AlertKey . interface number) of the interface which went down.e. Example switch($specific-trap) { case “1”: @AlertKey = “A” case “2”: @AlertKey = “B” default: } o A mixed combination of variable binding values and information derived from the from the trap name or trap description. The appropriate power supply instance would need to be derived from the MIB’s trap definitions and then encoded in the rules file. The first variable binding of a linkDown trap contains the ifIndex value (i.([0-9]+)$”) @AlertKey = $1 o A textual description of the instance derived from the trap name or trap description. This field is important for proper correlation of events by the GenericClear automation. to indicate the failed status of one or the other power supply. but may also be contained in a combination of one or more of the trap’s variable binding values. without variable bindings. AlertKey can be set with either of the following methods: Example @AlertKey = extract($OID1. Standard The primary goal of the value of the AlertKey field is to ensure proper deduplication of alarms and compatibility with the GenericClear automation. A and B. The AlertKey field contains a descriptive key which indicates the object instance referenced by the alarm (Ex. “\. • SNMP Trap-related Probes – When applicable probes which process SNMP traps should set the AlertKey field to one of the following values. Readability of its value for display purposes is secondary. may be able to send two separate specific traps. A device with two power supplies.varchar(64) Required ObjectServer Field.

The Severity field can indicate any of six defined severity levels. Additionally. Minor and Warning.. Ideally this will be a textual name of the some managed entity.208. all “problem resolving” alarms are initially defined as indeterminate until they have been correlated with problem indicating alarms (for example by the GenericClear automation). changed”) • TL-1 TSM – Typically the AlertKey field for a TL-1 message will be set to the value of the message’s “Alarm Location”.net 195. which provide an indication of how it is perceived that the capability of the managed object has been affected..193 19986: 37w0d: %LINK-3-UPDOWN: Interface FastEthernet0/13. AlertKey) that have the same Alarm Type and/or Probable Cause (i.e. such as the GenericClear automation. “Interface (. Standard The levels defined for use with this mandatory parameter are: • Clear (0) – The Clear severity level indicates the clearing of one or more previously reported alarms.customer. • 43 . but is required to ensure proper deduplication and GenericClear compatibility. Major. Indeterminate (1) – The Indeterminate severity level indicates that the severity level cannot be determined.int Required ObjectServer Field. Severity .Creation of Tivoli Netcool/OMNIbus Rules Files instance information that is not available in the above two methods. This field is important for proper correlation of events by the GenericClear automation. or automatically by a process which has determined the fault condition no longer exists. Alarms which are cleared have either been cleared manually by a network operator.*). The displayed color of the alarm is also controlled by the Severity value. changed state to down . Those severity levels which represent service affecting conditions ordered from most severe to least severe are Critical. These processes.180. • Syslog Probe – The Syslog Probe should set the AlertKey to a textual description of the instance derived from the log message text.the AlertKey would be set to FastEthernet0/13 using the following syntax: @AlertKey = extract($Details.e. typically clear all alarms for this managed object (i. AlertGroup). Example For the following syslog message… Nov 20 13:12:57 device. at which point all correlated alarms are set to Clear.

the best textual description of the managed object instance provided by the available alarm data. The Summary field contains text which describes the alarm condition as well as the affected managed object instance. for example. when there is a severe degradation in the capability of the managed object and its full capability must be restored. Action should be taken to further diagnose (if necessary) and correct the problem in order to prevent it from becoming a more serious service affecting fault. Critical (5) – The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action is required. in parenthesis. Such a severity can be reported. • • • Summary . Such a severity can be reported.Creation of Tivoli Netcool/OMNIbus Rules Files • Warning (2) – The Warning severity level indicates the detection of a potential or impending service affecting fault. Major (4) – The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.varchar(255) Required ObjectServer Field. 44 . service affecting) fault. when a managed object becomes totally out of service and its capability must be restored. before any significant effects have been felt. while making easier for network operators to deal with the event quickly: “BGP Peer Connection Idle” • The Summary field should contain. for example. for example. Standard • Care should be taken to ensure that the Summary field is as compact as possible while still providing all of the necessary information. when the detected alarm condition is not currently degrading the capacity of the managed object. Such a severity can be reported. Minor (3) – The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action should be taken in order to prevent a more serious (for example. Example Based on the bgpBackwardTransition trap defined in BGP4-MIB the Summary field could read: “A BGP Peer Connection has moved to the Idle state” However a simplified Summary text provides the same information.

7000. Exceeded Threshold ( BRI2/0:1 )” o Threshold Name provided: “Link Utilization High: inOctetsMax Exceeded ( BRI2/0:1 )” o Threshold Value provided: “Link Utilization High: inOctetsMax.10 )” A linkDown trap from a Cisco device will contain the ifDescr value in the 2nd variable binding. Exceeded ( BRI2/0:1 )” o Compared Value and Threshold Value provided: “Link Utilization High: 7100 Exceeded 7000 ( BRI2/0:1 )” o Both Names and Values provided: “Link Utilization High: inOctets. 7100.120. 7100. The Summary of such an event would be similar to the following: “Link Down ( FastEthernet0/13 )” • For alarms related to thresholds which contain the compared and/or threshold values one of the following formats should be chosen based on the available data: o No values provided: “Link Utilization High ( BRI2/0:1 )” o Compared Value Name provided: “Link Utilization High: inOctets Exceeded Threshold ( BRI2/0:1 )” o Compared Value Name and Value provides: “Link Utilization High: inOctets.10.Creation of Tivoli Netcool/OMNIbus Rules Files Example For the BGP alarm in the previous example this could be as follows: “BGP Peer Connection Idle ( bgpPeerRemoteAddr = 18. Exceeded inOctetsMax. 7000 ( BRI2/0:1 )” 45 .

where type refers to the problematic or resolving nature of the Alarm.Creation of Tivoli Netcool/OMNIbus Rules Files Type . as well events which are “going up” which do not yet indicate the failure has been fully corrected. The following values are valid values for the Type field: (0) Type not set (1) Problem (2) Resolution (3) Netcool/Visionary problem (4) Netcool/Visionary resolution (7) Netcool/ISMs new alarm (8) Netcool/ISMs old alarm (11) More Severe (12) Less Severe (13) Information Standard Some scenarios are not well suited for strict definition as a “problem” (1) or “resolution” (2). Specifies the type of alarm. There are numerous examples of events which are “going down” but don’t yet represent a failure. 46 . This field is important for proper correlation of events by the GenericClear automation.int Default ObjectServer Field.

Example The following rule file logic is for the handling of traps related to BGP Peer Connection Status… switch ($bgpPeerState) { case "1": ### idle @Severity = 4 @Type = 1 case "2": ### connect @Severity = 2 @Type = 12 case "3": ### active @Severity = 2 @Type = 12 case "4": ### opensent @Severity = 2 @Type = 12 case "5": ### openconfirm @Severity = 2 @Type = 12 case "6": ### established @Severity = 1 @Type = 2 default: @Severity = 2 @Type = 1 } Class . The Class field is used to control the applicability of context sensitive tools to the alarm. Standard Class numbers are issued by the IBM Ready for IBM Tivoli Software Solution team or by the Tivoli Netcool Technology Program. The Class of an alarm can be used to identify the Probe or vendor from which an alarm was generated.Creation of Tivoli Netcool/OMNIbus Rules Files In these cases the Type field should be set to “(1) Problem”.int Required ObjectServer Field. class numbers should be properly set within the relevant rules files. 47 . Once assigned. (11) More Severe or (12) less severe in order to maintain compatibility with the GenericClear automation.

Used by the Expire automation. 48 . in conjunction with the Type field. Standard • SNMP Traps: SNMPTRAP-<vendor>-<MIB>-<specific-trap name> Example Example Example SNMPTRAP-cisco-MPLS-LDP-MIB-mplsLdpSessionDown SNMPTRAP-IEEE-IEEE802dot11-MIB-dot11Disassociate SNMPTRAP-IETF-ACCOUNTING-CONTROL-MIB-acctngFileFull • Syslog Messages: SYSLOG-<vendor>-<event-specific-trap id> Example Example SYSLOG-cisco-ios-LINK-UPDOWN SYSLOG-cisco-ios-LINEPROTO-UPDOWN • TL1 Autonomous Messages: TL1-<vendor>.Creation of Tivoli Netcool/OMNIbus Rules Files EventId – varchar(255) Contains an Identifier for the event which is specific to the event source. This is a generic identifier in that it is not specific to the state or objects represented in the originating message.<verb>[_<modifier1>][_<modifier2>]<condtype> Example Example Example TL1-movaz-REPT_ALM_EQPT-COMMLINK TL1-polaris-REPT_EVT_CHASSIS-FAN TL1-calix-REPT_RMV_OC12-OOS-AU ExpireTime – int The number of seconds until the alert is cleared automatically.

Save it as . MIB abc.e.e. if an event is currently matched in a switch case default statement. It is recommended that lookup tables are defined within an external file based table. “200701310907Z” Always check if a ObjectServer field exists prior to creating a new field that would have the same function Do not “over” deduplicate. release 1. Use lookup tables wherever possible.Creation of Tivoli Netcool/OMNIbus Rules Files 2. or the generic clear automation • • • • • • • • • 49 . and that their extension is set up to be . This is vital in case a roll-back is later required. Never build a separate If statement at the bottom of a Rules File unless you want to reset fields for all events.e.date i. or other specific requirements.rules. “productA. the lookup files include statement are located at the top of base rules file. when and by whom. Any logic or amendments should be accompanied by a #comment line in the Rules File. snmp.lookup. Switch/Case constructs can be used for exact matches. For example. use a multi-column lookup table. The Switch/Case constructs must be used in preference to If/Else statements. Ensure revision control is used on the probe rules file.rules. Never leave Details($*) for all events in the final version of a rules file. Also remember that lookup tables should be the first elements of the rules files that are read by the probe. Do and Don’t • • Always take a backup copy of a Rules File before amending it.5 Rules Files Best Practices. This ensures identification of changes made to the rules file. Unless specifically required. This enables clear identification of the lookup tables. Also specify which product(s). build another case statement to match a new event.070131. as they are much more efficient. Rules File additions should follow the existing structure of the Rules File. thus requiring an amendment. or for default sections where the received data is unknown. i.0.mib rev. Use the Details($*) function with care. The customer devices or application will have its own name which will not match the rule. do not match on device names within a Rules File. i. release(s) and interface(s) are supported by the rules. this can be assessed/ tested by temporarily adding a timestamp to the @Identifier field Do not let field truncation in the code if it is impacting the deduplication automation. When multiple values are linked to a single key. only use it whilst debugging Rules Files.

Do not set the Severity of resolution events to be 0 (Clear) as it would prevent it to be processed by the Generic Clear automation • 50 .Creation of Tivoli Netcool/OMNIbus Rules Files • Matching event pair (problem & resolution) must have exactly the same @AlertGroup and @AlertKey values. Resolutions event must have a Severity of 1 (indeterminate) and a Type of 2 (resolution). and appropriate @Type and @Severity values.

The TL1 potion of the logic and directory structure of the NcKL Lite can either be used as is (i. • Can I add a new automation in the ObjectServer? o You can add a new automation to the ObjectServer if there is no existing automation in the ObjectServer that has the same purpose.k.Creation of Tivoli Netcool/OMNIbus Rules Files 2. Refer the 51 . a new field should be created.a. Refer the Adding and Editing Table Columns section of the Configuring System Components for more details. • Where can I obtain the Class Number dedicated to the integration I am developing? o The Class Number dedicated to your integration will be provided by the Ready for IBM Tivoli team. • Can I add a new field in the ObjectServer? o You can add a new field to the ObjectServer if there is no existing field in the ObjectServer that has the same purpose. Instead. • Where can I obtain the Tivoli Netcool/OMNIbus license? o Business Partners with an active PartnerWorld membership will be contacted by the Ready for IBM Tivoli team after having nominated their products/ solution for the Ready for IBM Tivoli / IBM Tivoli Open Process Automation Library (OPAL) catalog. The Ready for IBM Tivoli team will then make the Tivoli Netcool/OMNIbus licenses available to the Business Partner. • Can I alter an existing field in the ObjectServer? o While you can technically alter an existing field in the ObjectServer. your integration will not likely successfully pass the technical validation if it alters an existing field.6 Rules Files Frequently Asked Questions (FAQ) • Where can I obtain the Tivoli Netcool/OMNIbus software? o Business Partners with an active PartnerWorld membership will be contacted by the Ready for IBM Tivoli team after having nominated their products/ solution for the Ready for IBM Tivoli / IBM Tivoli Open Process Automation Library (OPAL) catalog.e. o The TL1 base rules files and associated directory structure are ONLY available in the Netcool Knowledge Library Lite (a. and is not included in the full version of NcKL. in NcKL Lite) or be merged in the full version of NcKL. NcKL Lite). • Where can I find the TL1 base files and associated directory structure? It doesn’t seem to be included in the Netcool Knowledge Library (NcKL).

your integration will not likely successfully pass the technical validation if it alters an existing automation. Instead.4 “Probe Configuration for Development and Testing Purposes” of this Best Practices document.x Integrations” (PRD) under the section entitled “Tivoli Netcool/OMNIbus Minimum Test Scenario Requirements” 52 . • Can I alter an existing automation in the ObjectServer? o While you can technically alter an existing automation in the ObjectServer. • How should I configure the Raw Capture mode at the probe level to collect sample? o Please refer to chapter 1. and amending it as needed). • What data should I generate to test the integration and submit it to IBM for validation? o This information is found in the “Ready for IBM Tivoli software Product Requirements Document For Tivoli Netcool/OMNIbus 7.3. changing his name and description.Creation of Tivoli Netcool/OMNIbus Rules Files Configuring Automations section of the Tivoli Netcool/OMNIbus manual for more details. a new automation should be created (which can be done by cut-and-pasting the existing automation.

).7 Rules Files Check List 2. all syslog messages. no events left unprocessed. at a minimum: o o o o o o o o Commented section which describes the message/trap and the token received $token mapping (and preprocessing via lookup file where appropriate) @AlertGroup @AlertKey @Summary @Severity. traps etc. should contain the following.7.7.1 Overall Rules Files Readability and Content Clear and regular indentation Consistency in field assignment order (per events/messages/traps) Comments where appropriate Line length of commented section should not exceed 85 characters Correct spelling Accurate processing of all the messages defined in the supporting documentation (ex: all traps. etc. 2. @Type and $OS_ExpireTime (if applicable) Details ( ) @Identifier 53 .2 ObjectServer Fields Assignment The .Creation of Tivoli Netcool/OMNIbus Rules Files 2.rules files should at a minimum start with assignment statements for the following fields and tokens: @Agent and @Class The rules file section dedicated to the processing of each specific messages.

it should not impact the deduplication and generic clear automation Check the Rules Files Standards for more details and examples Severity o o o Any of six defined severity levels. Instance of the managed object which is represented by the alarm Exact same value for “problem” and “resolution” events which are related to each other Value Truncation should be avoided and if it occurs. Descriptive name of the sub-manager which generated the alert Check the Rules Files Standards for more details and examples AlertGroup o Descriptive name of the type of failure indicated by the alarm (as descriptive as possible based on information available in either the tokens received or the documentation) Exact same value for “problem” and “resolution” events which are related to each other No white space at the beginning or at the end of the field Check the Rules Files Standards for more details and examples o o o AlertKey o o o o o Descriptive key which indicates the object instance referenced by the alarm. the best textual description of the managed object instance provided by the available alarm data. (usually AlertKey value or textual equivalent) Format example: @Summary = <$Summary> + " ( " + @AlertKey + " )" with two spaces in front of the opening parenthesis. except Indeterminate (1) as it is for resolution events and unknown events only Severity must be set to 1 for resolution events Check the Rules Files Standards for more details and examples Summary o o o o Text which describes the alarm condition as well as the affected managed object instance.Creation of Tivoli Netcool/OMNIbus Rules Files Agent o o Class o Class should have been requested to IBM as they are specific to each Business Partner and to each integrated product. and one in front of the closing parenthesis o 54 . As compact as possible but extremely clear Provides all of the necessary information Contains in parenthesis.

and should not be 0 (zero) Type must always be 2 for resolution events Check the Rules Files Standards for more details and examples Identifier o o Controls the deduplication and GenericClear automation For SNMP traps.Creation of Tivoli Netcool/OMNIbus Rules Files o Must be followed by update(@Summary) if the Summary value should be updated on deduplication (ex: summary field contains a metric such as CPU utilization) Check the Rules Files Standards for more details and examples o Type o o o Type of alarm must always be set. TL1 and Syslog based integration rules files can be found in the following libraries of rules files or integration modules: • • • The Netcool Knowledge Library (NcKL) The Netcool Knowledge Library Lite (NcKL-Lite) The Tivoli Netcool/OMNIbus Integration Modules which can be downloaded from the Tivoli Netcool/OMNIbus catalog of the IBM Tivoli Open Process Automation Library (OPAL) at http://www.ibm. it should be ‘ @Identifier = @Node + “ “ + @AlertKey + “ “ + @AlertGroup + “ “ + @Type + “ “ + @Agent + “ “ + @Manager + “ “ + $specific-trap ‘ and additional information might be appended at the end to ensure proper deduplication and automation Must NOT contain any timestamp value Check the Rules Files Standards for more details and examples o o 2.8 Rules Files Examples Examples of SNMP.com/software/tivoli/opal/ncomnibus 55 .

Creation of Tivoli Netcool/OMNIbus Rules Files 2.9 Documenting a Rules Files Based Integration Appropriate documentation should be written for submitted Integration and must contain at a minimum: o o o o o o o o o Name and version of the integration Name and version of the integrated product(s) Description of the integration Supported platforms List of Files contained in the integration List of other required files and dependencies if any Installation instructions References if any Description of events supported by the integration. TL1 Autonomous Messages supported for TL1 based integration or syslog messages supported for a syslog based integration. For example: Enterprise OIDs supported for SNMP trap based integration. 56 .

Each tool can have an internal effect. or script) Execute SQL commands on the ObjectServer Tools can be configured by going to the Menus section of the Tivoli Netcool/OMNIbus configuration tool after opening the ObjectServer you wish to add it to. A prompt can be included into an SQL statement. batch file. or both. Alert: The aim of this section is not to replace the study of the Tivoli Netcool/OMNIbus product manuals or the attendance of Tivoli Netcool/OMNIbus trainings. This basically means if you are running a Primary and a Backup.Creation of a Tivoli Netcool/OMNIbus Tool 3 Creation of a Tivoli Netcool/OMNIbus Tool This chapter provides an overview of Tivoli Netcool/OMNIbus tools function and architecture. or a journal entry. For example. Each ObjectServer can have its own set of tools. It then provides guidelines for creating and using tools. 3. tools can be created that enable operators to: • • Execute external commands (for example. some additional information related to the event. launch a local application. so you would need to add the tools to all ObjectServers that they pertain to. an external command. By associating a tool with a specific class of alerts. 57 . • • An internal effect is created by using a SQL statement An External effect is created when you call a script or an executable from outside the system A tool can include a prompt or a popup so the user can enter. both being highly encouraged.1 Tool Function and Architecture Tools allow the control of alert management functions within Tivoli Netcool/OMNIbus from the EventList. the tool will only be available on the menu it has been assigned to when the selected event(s) belongs to the class associated to the tool. you would need to apply all changes to both. external effect. Tools associated with a class or classes of alert (@Class field). or select from a menu.

Creation of a Tivoli Netcool/OMNIbus Tool

Scripts used for External Effect purposes can be written using any of the following; • • • • • Bourne shell (/bin/sh) Korn shell (/bin/ksh) Perl Expect Awk/Nawk/Sed

For information about adding tools to event list menus, see Adding Tools, Sub-menus, and Separators to a Menu.

3.2

Tool Creation Best Practices, Do and Don’t

All tools should utilize the journal functionality to enable inform other Tivoli Netcool/OMNIbus users that the tool has been executed. If for some reasons a journal entry is not implemented on purpose, please describe why while submitting your integration for technical validation All tools should have a meaningful description. Ensure that the tool is made available only from that events pertaining to your Class (be as specific as possible when defining the SQL select statements associated with the tool)

• •

58

Creation of a Tivoli Netcool/OMNIbus Tool

3.3

Tools Frequently Asked Questions (FAQ)

Where can I obtain the Class Number dedicated to the integration I am developing? o The Class Number dedicated to your integration will be provided by the Ready for IBM Tivoli Development team.

Can I add a new field in the ObjectServer? o You can add a new field to the ObjectServer if there is no existing field in the ObjectServer that has the same purpose. Refer the Adding and Editing Table Columns section of the Configuring System Components for more details.

Can I alter an existing field in the ObjectServer? o While you can technically alter an existing field in the ObjectServer, your integration will not likely successfully pass the technical validation if it alters an existing field. Instead, a new field should be created.

Can I add a new automation in the ObjectServer? o You can add a new automation to the ObjectServer if there is no existing automation in the ObjectServer that has the same purpose. Refer the Configuring Automations section of the Tivoli Netcool/OMNIbus manual for more details.

Can I alter an existing automation in the ObjectServer? o While you can technically alter an existing automation in the ObjectServer, your integration will not likely successfully pass the technical validation if it alters an existing automation. Instead, a new automation should be created (which can be done by cut-and-pasting the existing automation, changing his name and description, and amending it as needed).

What data should I generate to test the integration and submit it to IBM for validation? o This information is found in the “Ready for IBM Tivoli software Product Requirements Document For Tivoli Netcool/OMNIbus 7.x Integrations” (PRD) under the section entitled “Tivoli Netcool/OMNIbus Minimum Test Scenario Requirements”

59

Creation of a Tivoli Netcool/OMNIbus Tool

3.4

Tool Creation Check List

Ensure that the tool has been set up to be available only on the platform it has been developed for Ensure that the tool has been set up to be available only for the Class of events it is meant for. Ensure that any SQL select statements are as narrow in scope as they can be Ensure that the tool is only available when the proper set of events is selected (in some cases that could mean none) Ensure that a journal entry is being created (forced or optionally) Ensure that Journal entries are selected for each row if the tool changes multiple events.

3.5

Tool Examples

Please refer to the default tools that are provided out of the box in the ObjectServer.

3.5.1 Internal Effect Tool Example

The “Change Severity” tool uses the following SQL to modify the event: update alerts.status set Severity=$prompt.Priority,Acknowledged=0 where Serial in ( $selected_rows.Serial );flush iduc; The access by default is set to all groups and all classes The Journal entry is not forced but is set for each row selected. The Platform is set to Windows and UNIX since it works the same for both.

60

6 Documenting a Tool Based Integration The following are required for tools integration documentation: • • • Integration datasheet User’s guide or equivalent (must include the description of the integration and the integration installation steps) List of all scripts or executables called by the tools. The Journal entry is not used. $(OMNIHOME)/utils/nco_functions nco_get_PATH export TELNET SLEEP $XTERM -e /bin/sh -c '$TELNET @Node .Creation of a Tivoli Netcool/OMNIbus Tool 3. The description is: Example Telnet tool.2 External Effect Tool Example The “telnet” tool uses the following commands: . (This does not update an event) The Platform is set to UNIX. $SLEEP 3' The access by default is set to all groups and all classes. 3.5. (Can be included in Users Guide) 61 . their functions and expected locations.

Triggers form the basis of the ObjectServer automation subsystem.Creation of a Tivoli Netcool/OMNIbus Automation 4 Creation of a Tivoli Netcool/OMNIbus Automation This chapter provides an overview of Tivoli Netcool/OMNIbus automation function and architecture. you can execute SQL commands and call procedures in response to the change. For more details on Automations. The automation will detect pre-defined changes in the ObjectServer and execute automated responses to these changes. procedures and/or user-defined signals.1 Automation Function and Architecture Tivoli Netcool/OMNIbus automations provide automatic management of events in the ObjectServer. You can enable or disable all triggers in a given group. 4. Alert: The aim of this section is not to replace the study of the Tivoli Netcool/OMNIbus product manuals or the attendance of Tivoli Netcool/OMNIbus trainings. Automations can consist of triggers. This enables the ObjectServer to process many alerts without requiring an operator to take action. both being highly encouraged. In a trigger. please refer to Automation: Triggers and Trigger Groups. Every trigger belongs to a trigger group. It then provides guidelines for creating and using tools. which is a collection of related triggers. 62 . Triggers automatically fire (execute a trigger action) when the ObjectServer detects an incident associated with a trigger.

firstly compare integers. • Can I add a new automation in the ObjectServer? o You can add a new automation to the ObjectServer if there is no existing automation in the ObjectServer that has the same purpose. then characters and lastly the most intensive comparisons – regular expressions Ensure that the automation trigger does not catch events it has already processed (especially important for external script) Stagger automation priority rates so they do no all fire at the same time Add a description to all newly created automations Do not execute a “for each row” within a database trigger Automations should update the journal entry if they modify events in the ObjectServer 4. a new field should be created. 63 .Creation of a Tivoli Netcool/OMNIbus Automation 4. your integration will not likely successfully pass the technical validation if it alters an existing field. • Can I alter an existing field in the ObjectServer? o While you can technically alter an existing field in the ObjectServer. Do and Don’t • • • • • • • Always check if an automation exists prior to creating a new automation that would have the same function In the automation condition. Refer the Adding and Editing Table Columns section of the Configuring System Components for more details. Refer the Configuring Automations section of the Tivoli Netcool/OMNIbus manual for more details.3 Automation Frequently Asked Questions (FAQ) • Can I add a new field in the ObjectServer? o You can add a new field to the ObjectServer if there is no existing field in the ObjectServer that has the same purpose.2 Automation Creation Best Practices. Instead.

clear and complete 4. • What data should I generate to test the integration and submit it to IBM for validation? o This information is found in the “Ready for IBM Tivoli software Product Requirements Document For Tivoli Netcool/OMNIbus 7. Instead.Creation of a Tivoli Netcool/OMNIbus Automation • Can I alter an existing automation in the ObjectServer? o While you can technically alter an existing automation in the ObjectServer. changing his name and description. a new automation should be created (which can be done by cut-and-pasting the existing automation.x Integrations” (PRD) under the section entitled “Tivoli Netcool/OMNIbus Minimum Test Scenario Requirements” 4. your integration will not likely successfully pass the technical validation if it alters an existing automation. Other automations examples are documented in the Tivoli Netcool/OMNIbus manual: Standard Tivoli Netcool/OMNIbus Automations 64 . and amending it as needed).4 Automation Creation Check List All SQL select statements are as narrow in scope as they can be Automation works only on the events that are supposed to trigger the automations Comments are meaningful.5 Automation Examples Please refer to the default automations that are provided out of the box in the ObjectServer.

their functions and expected locations. (Can be included in Users Guide) 65 .6 Documenting an Automation Based Integration The following are required for automation integration documentation: • • • Integration datasheet User’s guide or equivalent (must include the description of the integration and the integration installation steps) List of all scripts or executables called by the tools.Creation of a Tivoli Netcool/OMNIbus Automation 4.

5.Integration Submission Packaging 5 Integration Submission Packaging 5.1 Archiving tool The files submitted to IBM for validation purposes need to be packaged up.tar.tar.gz ABC_Xyz_rft_OMNIbus.gz or *.tar. please ensure that any files created on the windows platforms are converted using a utility like dos2unix for compatibility with UNIX systems. Please package them in either a .tar. For the integrations that cross over multiple platforms.zip 66 . Example So for the company ABC with a product called Xyz.Z. then a descriptive of the integration.2 Files Names The file name should begin with the company name or acronym followed by an underscore. such as the name of the product we are integrating with.zip file or a compressed tar file like *.Z ABC_Xyz_rft_OMNIbus. followed by _rft_OMNIbus. the integration files could be named any of the following: ABC_Xyz_rft_OMNIbus.

Events collected by probes and monitors are structured into a common format for consolidation at the ObjectServer. The default format is configurable through the ObjectServer schema and usermaintainable probe/monitor rules files. vi .1 is used in OSI standards and TCP/IP network management specifications.A language used for defining data types.1) Abstract Syntax Notation 1 (ASN. B C CEF Common Event Format See Common Event Format.1) .APPENDIX: GLOSSARY OF TERMS This section provides a list of the terms and acronyms used within this document. D Deduplication Deduplication is the technique applied to the management of alarms where a single device may generate the same error repeatedly until the problem is dealt with. 1-10 A Automation Abstract Syntax Notation 1 (ASN. Repeated alerts are identified and stored as a single alert to reduce the amount of data that the operator has to manage. ASN.

H-J K/L M Management Interface Base (MIB) Management Interface Base (MIB) .E F G Gateways Bi-directional interfaces that allow Netcool ObjectServer data to be shared with other ObjectServers. or troubleticketing applications. RDBMS archives.A logical database made up of the configuration. status and statistical information stored at a device. vii .

a database schema.1. Q/R S Syslog Syslog is a standard for forwarding log messages in an IP network. optimized for collecting events and designing filters and views. which specify the management data of a device subsystem. P Probe Passive supersets of code that collect event data from more than 300 management data sources. implemented via ASN. The receiver is commonly called "syslogd". Syslog messages can be sent via UDP and/or TCP. The syslog protocol is a very simplistic protocol: the syslog sender sends a small textual message (less than 1024 bytes) to the syslog receiver. using a hierarchical namespace containing object identifiers. viii . and a set of data objects. SNMP is used by network management systems to monitor network-attached devices for conditions that warrant administrative attention. It consists of a set of standards for network management.N-O ObjectServer An in-memory database. Collected data is filtered. The SNMP's extensible design is achieved with management information bases (MIBs). The term "syslog" is often used for both the actual syslog protocol. stored. "syslog daemon" or "syslog server". including an Application Layer protocol. and manipulated in the Netcool ObjectServer. as well as the application or library sending syslog messages. viewed. SNMP The simple network management protocol (SNMP) forms part of the internet protocol suite as defined by the Internet Engineering Task Force (IETF). which provides the core processing functions for the Netcool suite.

Autonomous message .T TL1 Transaction Language 1 (TL1) is a widely used. The TL1 language consists of a set of messages. Input message . management protocol in telecommunications. 2. cross-technology man-machine language. and is widely used to manage optical (SONET) and broadband access infrastructure in North America.This is the command sent by the user or the OSS. 4.These are asynchronous messages (usually events or alarms) sent by the NE. It is a cross-vendor.This is an acknowledgment of the receipt of a TL1 input message and is sent if the response message will be delayed by more than 2 seconds. U-Z ix . 3. Output/Response message . "legacy". Acknowledgment message . It is defined in GR-831 by Bellcore (now Telcordia Technologies). There are 4 kinds of messages: 1.This is reply sent by the NE in response to an input message.

REFERENCES IBM Tivoli Netcool/OMNIbus Installation and Deployment Guide IBM Tivoli Netcool/OMNIbus User Guide IBM Tivoli Netcool/OMNIbus Administration Guide IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide Ready for IBM Tivoli Software Product Requirements Document For Tivoli Netcool/OMNIbus 7.x Integrations” (PRD) x .

INCLUDING. NC 27709 U. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This information could include technical inaccuracies or typographical errors. IBM may have patents or pending patent applications covering subject matter described in this document. in writing. IBM cannot guarantee that identified products (including portlets) will continue to be made available by their suppliers. The furnishing of this document does not give you any license to these patents. to: IBM Director of Licensing IBM Corporation 4205 South Miami Boulevard Research Triangle Park. DB2. Lotus Notes. Other company. therefore.A. Lotus. zSeries. Lotus QuickPlace. these changes may be incorporated in subsequent versions of the paper. S/390. Some states do not allow disclaimer of express or implied warranties in certain transactions.® © Copyright IBM Corporation 2007 IBM United States of America Produced in the United States of America All Rights Reserved The e-business logo. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. Domino. INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PAPER “AS IS” WITHOUT WARRANTY OF ANY KIND. in the United States. You can send license inquiries. Lotus Discovery Server. Information in this paper as to the availability of products (including portlets) was believed accurate as of the time of publication. Lotus and WebSphere are trademarks of International Business Machines Corporation in the United States. SecureWay. THE IMPLIED WARRANTIES OF NON-INFRINGEMENT.S. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this paper at any time without notice. EITHER EXPRESS OR IMPLIED. other countries or both. . Any references in this document to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. Inc. Changes may be made periodically to the information herein. other countries or both. BUT NOT LIMITED TO. Tivoli. IBM. the eServer logo. and Sametime are trademarks of Lotus Development Corporation and/or IBM Corporation. Java and all Java-based trademarks and logos are trademarks of Sun Microsystems. product and service names may be trademarks or service marks of others. OS/390. this statement may not apply to you. the IBM logo.