rule set reference -...

IBM Tivoli Enterprise Console

Rule Set Reference

SC32-1282-00

��

NoteBefore using this information and the product it supports, read the information in “Notices” on page 73.

First Edition (August 2003)

This edition applies to version 3, release 9 of IBM Tivoli Enterprise Console (product number 5698-TEC) and to allsubsequent releases and modifications until otherwise indicated in new editions.

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

Contents

About this guide . . . . . . . . . . . vWho should read this guide . . . . . . . . . vPublications . . . . . . . . . . . . . . v

IBM Tivoli Enterprise Console library . . . . . vRelated publications . . . . . . . . . . viAccessing publications online . . . . . . . viOrdering publications . . . . . . . . . . vii

Contacting software support . . . . . . . . viiParticipating in newsgroups. . . . . . . . . viiConventions used in this guide . . . . . . . viii

Typeface conventions . . . . . . . . . . viiiOperating system-dependent variables and paths ix

Introduction . . . . . . . . . . . . . 1Modifying the rule base . . . . . . . . . . 2

Activating and deactivating rule sets . . . . . 3Rule set sequencing and dependencies. . . . . 3

Cleanup rule set (cleanup.rls) . . . . . 5

Correlation rule set (correlation.rls) . . . 7

Database cleanup rule set(db_cleanup.rls) . . . . . . . . . . . 9

Dependency rule set (dependency.rls) 11

e-business rule set (ebusiness.rls). . . 13

Escalation rule set (escalate.rls) . . . . 23

Event activity rule set(event_activity.rls) . . . . . . . . . . 27

Event filtering rule set(event_filtering.rls) . . . . . . . . . 29

Event threshold rule set(event_thresholds.rls) . . . . . . . . 31

Forwarding rule set (forwarding.rls) . . 33

Heartbeat rule set (heartbeat.rls) . . . 35

Maintenance mode rule set(maintenance_mode.rls) . . . . . . . 39

NetView rule set (netview.rls) . . . . . 43

Notification rule set (notify.rls) . . . . 59

HP OpenView rule set (ov_default.rls) 61

NetView for z/OS event forwarding ruleset (tecad_nv390fwd.rls) . . . . . . . 63

NetView for z/OS message rule set(tecad_nv390msg.rls) . . . . . . . . 65

SNA event rules tecad_snaevent.rls . . 67

Trouble ticket rule set (troubleticket.rls) 69

Notices . . . . . . . . . . . . . . 73Trademarks . . . . . . . . . . . . . . 75

Index . . . . . . . . . . . . . . . 77

© Copyright IBM Corp. 2003 iii

iv IBM Tivoli Enterprise Console: Rule Set Reference

About this guide

The IBM® Tivoli Enterprise Console® product is a rule-based, event managementapplication that integrates system, network, database, and application managementto help ensure the optimal availability of an organization’s IT services. The IBMTivoli Enterprise Console Rule Set Reference provides information about the rule setsprovided for processing common application and infrastructure events.

Who should read this guideThis guide is for system administrators who need to deploy rules for automatingmanagement of Tivoli Enterprise Console events received by the Tivoli EnterpriseConsole event server.

Readers should be familiar with the following topics:v The operating systems and e-business applications that your enterprise usesv The Tivoli® Management Frameworkv The IBM Tivoli NetView® productv The IBM Tivoli Enterprise Console product

PublicationsThis section lists publications in the IBM Tivoli Enterprise Console library andrelated documents. It also describes how to access Tivoli publications online andhow to order Tivoli publications.

IBM Tivoli Enterprise Console libraryThe following documents are available in the IBM Tivoli Enterprise Consolelibrary:v IBM Tivoli Enterprise Console Adapters Guide, SC32-1242

Provides information about supported adapters, including how to install andconfigure these adapters.

v IBM Tivoli Enterprise Console Command and Task Reference, SC32-1232Provides details about IBM Tivoli Enterprise Console commands, predefinedtasks that are shipped in the task library, and the environment variables that areavailable to tasks that run against an event.

v IBM Tivoli Enterprise Console Installation Guide, SC32-1233Describes how to install, upgrade, and uninstall the IBM Tivoli EnterpriseConsole product.

v IBM Tivoli Enterprise Console Release Notes, SC32-1238Provides release-specific information that is not available until just before theproduct is sent to market.

v IBM Tivoli Enterprise Console Rule Developer’s Guide, SC32-1234Describes how to develop rules and integrate them for event correlation andautomated event management.

v IBM Tivoli Enterprise Console Rule Set Reference, SC32-1282Provides reference information about the IBM Tivoli Enterprise Console rule sets.

v IBM Tivoli Enterprise Console User’s Guide, SC32-1235

© Copyright IBM Corp. 2003 v

Provides an overview of the IBM Tivoli Enterprise Console product anddescribes how to configure and use the IBM Tivoli Enterprise Console product tomanage events.

v IBM Tivoli Enterprise Console Warehouse Enablement Pack: Implementation Guide,SC32-1236Describes how to install and configure the warehouse enablement pack for theIBM Tivoli Enterprise Console product and describes the data flow andstructures that are used by the warehouse pack.

v Tivoli Event Integration Facility Reference, SC32-1241Describes how to develop your own event adapters that are tailored to yournetwork environment and the specific needs of your enterprise. This referencealso describes how to filter events at the source.

Related publicationsv IBM Tivoli Monitoring: User’s Guide, SH19-4569v IBM Tivoli Monitoring for Business Integration: WebSphere® MQ: User’s Guide,

GC23-4716v IBM Tivoli Monitoring for Business Integration: WebSphere MQ: Reference Guide,

GC23-4715v IBM Tivoli Monitoring for Databases: DB2®: User’s Guide, SC23-4726v IBM Tivoli Monitoring for Databases: DB2: Reference Guide, SC23-4727v IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server: User’s

Guide, SC23-4705v IBM Tivoli Monitoring for Web Infrastructure: Reference Guide, GC23-4720

The Tivoli Software Glossary includes definitions for many of the technical termsrelated to Tivoli software. TheTivoli Software Glossary is available, in English only, atthe following Tivoli software library Web site:

http://www.ibm.com/software/tivoli/library/

Access the glossary by clicking the Glossary link on the left pane of the Tivolisoftware library window.

Accessing publications onlineThe documentation CD contains the publications that are in the product library.The format of the publications is PDF, HTML, or both. Refer to the readme file onthe CD for instructions on how to access the documentation.

IBM posts publications for this and all other Tivoli products, as they becomeavailable and whenever they are updated, to the Tivoli Software InformationCenter Web site. Access the Tivoli Software Information Center by first going to theTivoli software library at the following Web address:


Scroll down and click the Product manuals link. In the Tivoli Technical ProductDocuments Alphabetical Listing window, click the IBM Tivoli Enterprise Consolelink to access the product library at the Tivoli Information Center.

Note: If you print PDF documents on other than letter-sized paper, select the Fit topage check box in the Adobe Acrobat Print window. This option is available

vi IBM Tivoli Enterprise Console: Rule Set Reference



when you click File → Print. Fit to page ensures that the full dimensions of aletter-sized page print on the paper that you are using.

Ordering publicationsYou can order many Tivoli publications online at the following Web site:

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi

You can also order by telephone by calling one of these numbers:v In the United States: 800-879-2755v In Canada: 800-426-4968

In other countries, see the following Web site for a list of telephone numbers:

http://www.ibm.com/software/tivoli/order-lit/

Contacting software supportIf you have a problem with any Tivoli product, refer to the following IBM SoftwareSupport Web site:

http://www.ibm.com/software/sysmgmt/products/support/

If you want to contact software support, see the IBM Software Support Guide at thefollowing Web site:

http://techsupport.services.ibm.com/guides/handbook.html

The guide provides information about how to contact IBM Software Support,depending on the severity of your problem, and the following information:v Registration and eligibilityv Telephone numbers and e-mail addresses, depending on the country in which

you are locatedv Information you must have before contacting IBM Software Support

Participating in newsgroupsUser groups provide software professionals with a forum for communicating ideas,technical expertise, and experiences related to the product. They are located on theInternet and are available using standard news reader programs. These groups areprimarily intended for user-to-user communication and are not a replacement forformal support.

To access a newsgroup, use the instructions appropriate for your browser.

Use these instructions for a Microsoft Internet Explorer browser.1. Open an Internet Explorer browser.2. From the Tools menu, click Internet Options.3. On the Internet Options window, click the Programs tab.4. In the Newsgroups list, click the Down Arrow and then click Outlook Express.5. Click OK.6. Close your Internet Explorer browser and then open it again.

About this guide vii



http://www.ibm.com/software/tivoli/order-lit/

http://www.ibm.com/software/sysmgmt/products/support/

http://techsupport.services.ibm.com/guides/handbook.html

7. Cut and paste the newsgroup address of a product into the browser Addressfield, and press Enter to open the newsgroup.

Use these instructions for a Netscape Navigator browser.1. Open a Netscape Navigator browser.2. From the Edit menu, click Preferences. The Preferences window is displayed.3. In the Category view, click Mail & Newsgroups to display the Mail &

Newsgroups settings.4. Select the Use Netscape mail as the default mail application check box.5. Click OK.6. Close your Netscape Navigator browser and then open it again.7. Cut and paste the newsgroup address of a product into the browser Address

field, and press Enter to open the newsgroup.

IBM Tivoli Enterprise Console

news://news.software.ibm.com/ibm.software.tivoli.enterprise-console

IBM Tivoli NetView for UNIX® and IBM Tivoli NetView for Windows®

news://news.software.ibm.com/ibm.software.tivoli.netview-unix-windows

Conventions used in this guideThis guide uses several conventions for special terms and actions, operatingsystem-dependent commands and paths, and margin graphics.

Typeface conventionsThis guide uses the following typeface conventions:

Bold

v Lowercase commands and mixed case commands that are otherwisedifficult to distinguish from surrounding text

v Interface controls (check boxes, push buttons, radio buttons, spinbuttons, fields, folders, icons, list boxes, items inside list boxes,multicolumn lists, containers, menu choices, menu names, tabs, propertysheets), labels (such as Tip:, and Operating system considerations:)

v Column headings in a tablev Keywords and parameters in text

Italic

v Citations (titles of books, diskettes, and CDs)v Words defined in textv Emphasis of words (words as words)v Letters as lettersv New terms in text (except in a definition list)v Variables and values you must provide

Monospace

v Examples and code examplesv File names, programming keywords, and other elements that are difficult

to distinguish from surrounding text

viii IBM Tivoli Enterprise Console: Rule Set Reference

news://news.software.ibm.com/ibm.software.tivoli.enterprise-console

news://news.software.ibm.com/ibm.software.tivoli.netview-unix-windows

v Message text and prompts addressed to the userv Text that the user must typev Values for arguments or command options

Operating system-dependent variables and pathsThis guide uses the UNIX convention for specifying environment variables and fordirectory notation.

When using the Windows command line, replace $variable with %variable% forenvironment variables and replace each forward slash (/) with a backslash ( \) indirectory paths.

Note: If you are using the bash shell on a Windows system, you can use the UNIXconventions.

About this guide ix

x IBM Tivoli Enterprise Console: Rule Set Reference

Introduction

The Tivoli Enterprise Console rule engine processes events based on rules writtenin the Tivoli Enterprise Console rule language. A rule defines a set of actions thatare taken when certain conditions are met; these conditions might include thearrival of a particular class of event (or an event with certain attribute values),changes to an event, or the expiration of a timer. See the IBM Tivoli EnterpriseConsole Rule Developer’s Guide for more information about rules and the rulelanguage. A rule set is a file containing a group of logically related rules written inthe rule language, while a rule base is a collection of compiled rule sets andsupporting data (including class definitions and Prolog predicates) used by thoserule sets.

The default rule base provided with the Tivoli Enterprise Console product includesa number of preconfigured rule sets that provide support for processing commonapplication and infrastructure events. These rules provide powerful duplicationdetection, filtering, escalation, notification, and correlation capabilities withoutrequiring any additional rule development. The rules included in the default rulebase provide functions that include (but are not limited to) the following:v Causal analysis of network infrastructure and e-business application events

based on service impact and dependency relationshipsv Scheduling of maintenance windows and discarding of events from systems

currently undergoing maintenancev Integration with external trouble ticket systemsv Heartbeat monitoring and detection of missed heartbeat pulses

Some of the rule sets in the default rule base are already activated, while othersmust be activated before use. In addition, some of the rule sets must be configuredfor your environment. In general, configuration requires only modification ofglobal parameters defined in the configuration rule at the beginning of the rule set;other rule sets might require configuration of external files. The reference sectionsof this book provide specific configuration information for each rule set.

The rule set files are located in the default rule base directory($BINDIR/TME/TEC/default_rb). The following table lists all of the rule sets inthe default rule base and indicates which are already activated, as well as whichrequire configuration before use.

Table 1. Rule sets included in the default rule base

Rule set Description Activated Configurationrequired

cleanup.rls Closes old open events Yes No

correlation.rls Event correlation No Yes

db_cleanup.rls Deletes old closed events No No

dependency.rls Defines dependency relationships for e-businessrules

Yes No

ebusiness.rls Causal analysis of events from e-businessapplications

Yes Yes

escalate.rls Automatic severity escalation No No

© Copyright IBM Corp. 2003 1

Table 1. Rule sets included in the default rule base (continued)

Rule set Description Activated Configurationrequired

event_activity.rls Generation of event activity reports No No

event_filtering.rls Filtering of unwanted events No Yes

event_thresholds.rls Severity escalation based on repeated events No Yes

forwarding.rls Event forwarding No Yes

heartbeat.rls Heartbeat monitoring Yes No1

maintenance_mode.rls Maintenance mode support Yes No

netview.rls Clearing and synchronizing of network events Yes No

notify.rls E-mail or pager notification No Yes

ov_default.rls Processing of HP OpenView events No No

tecad_nv390fwd.rls Forwarding of NetView for z/OS™ events No Yes

tecad_nv390msg.rls Processing of NetView for OS/390® MessageAdapter events

No No

tecad_snaevent.rls Processing of SNA alert events No No

troubleticket.rls Integration with trouble ticket systems No Yes

Notes:

1. Configuration is required for e-mail notification.

Modifying the rule baseYou cannot directly modify the default rule base provided with the TivoliEnterprise Console product. If you want to make any changes to this rule base(including activating or deactivating rule sets, modifying rule sets, or changing rulebase targets), you must first do the following:1. Create a new rule base using the wrb –crtrb command.2. Copy the default rule base to the new rule base using the wrb –cprb command.

By default, this command copies the rule sets, BAROC files, Prolog templates,and rule base targets. It also copies the rule_sets file, which lists the rule sets inthe rule base and indicates which are active. (See “Activating and deactivatingrule sets” on page 3 for more information.)

After you have made a copy of the default rule base, you can then make anychanges you want to make to the copy. In general, follow these steps to modify therule base:1. Make the necessary changes, including any of the following:

v Activating or inactivating rule sets (see “Activating and deactivating rulesets” on page 3)

v Editing rule set or BAROC filesv Creating or deleting rule base targets using the wrb –crttarget and wrb

–delrbtarget commandsv Importing or deleting rule sets in rule base targets using the wrb –imptgtrule

and wrb –deltgtrule commands2. Compile the new rule base using the wrb –comprules command.3. Load the new rule base using the wrb –loadrb command.

2 IBM Tivoli Enterprise Console: Rule Set Reference

See the IBM Tivoli Enterprise Console Rule Developer’s Guide for more informationabout working with rule bases, and the IBM Tivoli Enterprise Console Command andTask Reference for more information about the wrb command.

Activating and deactivating rule setsThe rule_sets file, located in the TEC_RULES subdirectory of each rule base, listsall of the rule sets included in that rule base. It also indicates which rule sets areactive and which are inactive. All of the rule sets listed in rule_sets are consideredpart of the rule base and are included when the rule base is copied. However, onlyactive rule sets can be imported into rule base targets.

The contents of the rule_sets file consist of a series of Prolog statements, each inthe following form:rule_set(label, filename, status).

In each statement, label is the name used to identify the rule set in the trace file,filename is the name of the rule set RLS file, and status is either active or inactive.For example, the following statement defines two rule sets, one active and oneinactive:rule_set(maintenance_mode, ’maintenance_mode.rls’, active).rule_set(correlation, ’correlation.rls’, inactive).

To activate or deactivate rule sets, follow these steps. (Note that you cannot makethese changes directly to the default rule base; see “Modifying the rule base” onpage 2 for more information.)1. Using a text editor, modify the corresponding statements in the rule_sets file,

specifying the active or inactive keyword as appropriate.2. If you are activating rule sets, use the wrb –imptgtrule command to import

those rule sets into one or more rule base targets.3. If you are deactivating rule sets, use the wrb –deltgtrule command to delete

those rule sets from any rule base targets that currently contain them.4. Recompile the rule base using the wrb –comprules command.5. Reload the rule base using the wrb –loadrb command.

See the IBM Tivoli Enterprise Console Command and Task Reference for moreinformation about the wrb command.

Rule set sequencing and dependenciesThe rule engine processes the active rule sets in the order in which they are listedin the rule_sets file, and in some cases this sequencing is important. In addition,some rule sets depend upon supporting functions provided by other rule sets.When you make changes to the rule_sets file, keep the following guidelines inmind:v The event filtering rule set (event_filtering.rls) should be near the beginning of

the sequence, preferably first. This avoids unnecessary processing of events thatare to be filtered out by this rule set.

v The maintenance mode rule set (maintenance_mode.rls) should be near thebeginning of the sequence, preferably immediately after event_filtering.rls. Thisavoids unnecessary processing of events sent from systems in maintenancemode.

v The correlation rule set (correlation.rls) should be near the end of the sequence.This ensures that any event-specific correlation rules run before thegeneral-purpose correlation rules.

Introduction 3

v The escalation rule set (escalate.rls) should be near the end of the sequence, andshould come after correlation.rls. This ensures that event severities can beappropriately adjusted after other processing takes place.

v The e-business rule set (ebusiness.rls) should be near the end of the sequence,and should come after the NetView rule set (netview.rls) and any other rule setsthat process events from e-business services monitored by IBM Tivoli Monitoringproducts.

v The notification rule set (notify.rls) should be near the end of the sequence,preferably last. This ensures that notification is based on the most current eventinformation.

v The escalation rule set (escalate.rls) depends upon the notification rule set(notify.rls) to provide e-mail notification of escalated events. If you want to usethis function, both rule sets must be activated.

v The e-business rule set (ebusiness.rls) depends upon the dependency rule set(dependency.rls), which supports definition of dependency relationships. If youwant to use the e-business rules, both rule sets must be activated.

v The e-business rule set (ebusiness.rls) generates missed heartbeat events inresponse to certain network events. If you want these events to be handledproperly, the heartbeat rule set (heartbeat.rls) must also be activated.

v The NetView rule set (netview.rls) correlates heartbeat events with other networkevents. If you want this correlation to take place, the heartbeat rule set(heartbeat.rls) must also be activated.


Cleanup rule set (cleanup.rls)

OverviewThe cleanup rule set contains rules that are used to purge old open events from theevent cache.

In general, events that remain open for a long time without being addressedshould be closed, on the assumption that they have been resolved or haveotherwise become inactive. Typically, a rule of this sort would be applied only toevents with low severity; for example, you might want to automatically close anyHARMLESS or UNKNOWN event that has remained in the OPEN state for morethan 48 hours. By customizing this rule set, you can specify which events youwant to close and how long you want to wait before closing them.

UsageThe cleanup rule set is already activated in the default rule base. If you make anychanges to this rule set, you must then recompile and reload the rule base. See“Modifying the rule base” on page 2 for more information.

Optional configurationThe cleanup rule set is preconfigured and ready to use. However, you cancustomize this rule set by modifying statements in the cleanup_start configurationrule. The following options are configurable:v Age limit for open events. You can specify the timeout value that controls how

old open events must be before they are closed automatically. The default agelimit is 48 hours. To change the age limit, modify the statement that sets the_default_span parameter as follows:_default_span = seconds,

seconds is the length of time, in seconds, you want to allow events to remainopen before being automatically closed.

v Cleanup frequency. You can specify how frequently you want the rules to checkfor old events to close. The default frequency is every 30 minutes. To change thecleanup frequency, modify the statement that sets the _cleanup_interval parameteras follows:_cleanup_interval = seconds

seconds is the length of time, in seconds, you want to elapse between cleanups.v Severities of events to close. You can specify the severities of events you want

to be closed automatically when they reach the specified age. The defaultbehavior is to close events with severities of HARMLESS or UNKNOWN. To change thisvalue, modify the statement that sets the cleanup_list parameter as follows:_cleanup_list = [ev_sevs],

ev_sevs is a list of valid event severities, each enclosed in single quotation marks,and separated by commas.


v Administrator name. You can specify the administrator name to use when thecleanup rules automatically close events. The default administrator name iscleanup.rls. To change the administrator name, modify the statement that setsthe cleanup_admin parameter as follows:_cleanup_admin = admin,

admin is the administrator name to use, enclosed in single quotation marks.

Rules

Startup rule

rule: cleanup_startThe cleanup_start rule is a configuration rule that runs upon receipt of theTEC_Start event, which is sent during intialization of the event server. This rulesets global parameters for the cleanup rules and then sets the Cleanup timer withthe duration specified by the _cleanup_interval parameter. By customizing this rule,you can configure the behavior of the cleanup rules. See “Usage” on page 5 formore information.

Cleanup rules

rule: do_the_cleanupThe do_the_cleanup rule runs upon receipt of the TEC_Cleanup_event event,which is generated by the cleanup_old_events timer rule to trigger periodiccleanups. When this event is received, the event cache is searched for open eventsthat match the cleanup criteria specified in the cleanup_start rule. Any matchingevents are closed. The received TEC_Cleanup_event event is then dropped.

timer_rule: cleanup_old_eventsThe cleanup_old_events timer rule runs upon expiration of the Cleanup timer. Thisrule generates a TEC_Cleanup_event event, which triggers the do_the_cleanuprule. It then resets the Cleanup timer with the duration specified by the_cleanup_interval parameter in the configuration rule.


Correlation rule set (correlation.rls)

OverviewThe correlation rule set contains rules that correlate incoming events based onpreviously defined relationships. There are two types of possible relationships:

Clearing eventsA clearing event is an event that resolves a previous problem event. Forexample, an event of class Su_Failure might be cleared by Su_Success fromthe same host and user.

Event sequencesAn event sequence is a series of events that are linked by causalrelationships. In an event sequence, each event is an effect of the previousevent. For example, the upsOnBattery event (indicating that anuninterruptible power supply is operating on battery power) might be theroot cause of an event sequence that also includes the lowBattery eventand finally the upsDischarged event.

UsageThe correlation rule set is not activated in the default rule base. Before you can usethis rule set, you must activate it. See “Modifying the rule base” on page 2 formore information on activating rule sets.

Note: If activated, the correlation rule set should be listed near the end of therule_sets file. See “Rule set sequencing and dependencies” on page 3 formore information.

Before using this rule set, you might also need to modify thecorrelation_parameters action of the correlation_configure rule to define theclearing events and event sequences you want the rules to correlate. To define aclearing event, use the create_clearing_event predicate; to define an eventsequence, use the create_event_sequence predicate. (See the IBM Tivoli EnterpriseConsole Rule Developer’s Guide for more information about these predicates.)Clearing events and event sequences can be defined either in this rule set or in anyother active rule set.

Note: After modifying this rule set, you must recompile and reload the rule base.

Optional configurationYou can customize the correlation rule set by modifying statements in thecorrelation_parameters action of the correlation_configure rule. The followingoptions are configurable:v Latency. You can specify the time range, or latency, to be used when searching

the event cache for events to correlate. By default, searches are limited to tenminutes (600 seconds) backward in the event cache. To change the latency,modify the statement that sets the _correlation_time_window parameter as follows:_correlation_time_window = seconds,

seconds is the number of seconds representing how far backward you want tosearch the cache for events.


Note: This parameter sets an upper limit on how far back in time the search willgo, but it does not guarantee that events within that time period are stillavailable. If your event cache is too small, events might be discarded evenif they are more recent than the specified time. If this happens, considerincreasing the size of your event cache. (See the IBM Tivoli EnterpriseConsole User’s Guide for more information.)

v Administrator name. You can specify the administrator name to use whenautomatically acknowledging or closing events. The default administrator nameis correlation.rls. To change the administrator name, modify the statementthat sets the _correlation_admin parameter as follows:_correlation_admin = admin,

admin is the administrator name to use, enclosed in single quotation marks.

Rules

Startup rule

rule: correlation_configureThe correlation_configure rule is a configuration rule that runs upon receipt ofthe TEC_Start event, which is sent during initialization of the event server. Thisrule defines the clearing events and event sequences that are correlated by thecorrelation rules; it also configures the _correlation_time_window parameter, whichdefines the latency used for event searches. By customizing this rule, you canconfigure the behavior of the correlation rules. See “Usage” on page 7 for moreinformation.

Correlation rules

rule: clearing_eventThe clearing_event rule runs upon receipt of any event. If the received event hasbeen defined as a clearing event (using the create_clearing_event predicate), anycleared events in the event cache received within the time window defined by the_correlation_time_window parameter are closed.

rule: correlateThe correlate rule runs upon receipt of any event. If the received event has beendefined as part of an event sequence, the rule uses the first_related_eventpredicate to search the event cache for the a related event received within the timewindow defined by the _correlation_time_window parameter. If the received event isfound to be an effect of a previously received cause event, it is correlated with thecause event using the link_effect_to_cause predicate. The received event is thenacknowledged, because it is an effect of a known cause.

If the received event is found to be a cause of a previously received effect event,the effect event is correlated with the cause event using the link_effect_to_causepredicate. The effect event is then acknowledged, because it is now known to be aneffect of the newly received cause event.


Database cleanup rule set (db_cleanup.rls)

OverviewThe database cleanup rule set periodically deletes old closed events from the TivoliEnterprise Console database. This rule set uses a timer rule to peridocally generateDB_Cleanup_event events. These events can also be sent from other sources if youwant to explicitly trigger a database cleanup. When DB_Cleanup_event is received,the wtdbclear command is used to delete old closed events from the eventrepository, task repository, extended event attribute table, and reception log. Seethe IBM Tivoli Enterprise Console Command and Task Reference for more informationabout the wtdbclear command.

UsageThe database cleanup rule set is not activated in the default rule base. Before youcan use this rule set, you must activate it. See “Modifying the rule base” on page 2for more information on activating rule sets.

Optional configurationYou can customize the database cleanup rule set by modifying the timer intervalthat determines how frequently the database cleanup takes place. The defaultinterval is one hour (3600 seconds). To change this interval, modify the statementin the db_cleanup_start rule that sets the _cleanup_timer parameter as follows:_cleanup_timer = seconds,

seconds is the length of time (in seconds) you want to elapse between databasecleanups.

Rules

Startup rule

rule: db_cleanup_startThe db_cleanup_start rule runs upon receipt of the TEC_Start event, which is sentduring initialization of the event server. This rule first sets the _cleanup_timerparameter and then starts the the DB_Cleanup timer, which is used to periodicallygenerate DB_Cleanup_event events. By customizing this rule, you can configurethe duration of the cleanup timer. See “Usage” for more information.

Database cleanup rules

rule: do_the_DB_cleanupThe do_the_DB_cleanup rule runs upon receipt of the DB_Cleanup_event event.This event is periodically generated by the time_to_cleanup_the_database timerrule, and it can also be generated from other sources in order to trigger a databasecleanup. When this event is received, the rule uses the following command todelete closed events that are older than the length of time specified by the_cleanup_timer parameter in the configuration rule:wtdbclear -e -l -s CLOSED -t seconds -a 1000


seconds is the value of the _cleanup_timer parameter. The receivedDB_Cleanup_event event is then closed.

timer_rule: time_to_cleanup_the_databaseThe time_to_cleanup_the_database timer rule runs when the DB_Cleanup timerexpires. This rule generates a DB_Cleanup_event event in order to trigger thedo_the_DB_cleanup rule. It then resets the timer.


Dependency rule set (dependency.rls)

OverviewThe dependency rule set contains rules that support the definition of dependencyrelationships used by the e-business rule set (ebusiness.rls). These rules processTEC_Dependency events, which are sent by the wrb –imptdp and wrb –deldpcommands. See “e-business rule set (ebusiness.rls)” on page 13 for moreinformation about dependency relationships.

UsageThe dependency rule set is already activated in the default rule base. If you makeany changes to this rule set, you must then recompile and reload the rule base.This rule set must be active if the e-business rule set is active.

Note: This rule set provides required support for the e-business rule set(ebusiness.rls). If the e-business rule set is active, the dependency rule setmust also be active. In order to ensure correct functioning of the e-businessrules, do not make any changes to this rule set apart from the optionalconfiguration parameters described below.

Optional configurationThe dependency rule set is preconfigured and ready to use. However, you cancustomize this rule set by modifying statements in the setup action of the startupconfiguration rule. The following options are configurable:v Dependency fact file name. You can specify the name of the Prolog file that is

used to store dependency facts in the knowledge base. You can either specify anabsolute location for the file or specify the file name only, in which case the fileis created in the $DBDIR directory. The default file name is dependencies.pro. Tospecify a different file name, modify the statement that defines the_dependency_file parameter as follows:_dependency_file = filename,

filename is the name of the Prolog fact file you want to use, optionally includinga relative or absolute path, and enclosed in single quotation marks.

v Debug logging. You can specify whether you want debugging informationwritten to a log file. This can be useful if you are modifying the rule set. Thisfunction should always be disabled before the rule set is deployed in aproduction environment because it can affect performance. To change thisbehavior, modify the statement that sets the _dependency_debug parameter asfollows:_dependency_debug = flag,

flag is either ’yes’ or ’no’.v Debug log file name. You can specify the name of the file used for logging

debugging messages. This file is only used if _dependency_debug is set to yes. Youcan either specify an absolute location for the file or specify the file name only,in which case the file is created in the $DBDIR directory. The default value isdependency.log. To specify a different file, modify the statement that sets thedependency_logger parameter as follows:


_dependency_logger = filename,

filename is the name of the log file you want to use, optionally including arelative or absolute path, and enclosed in single quotation marks.

Rules

Startup and shutdown rules

rule: startupThe startup rule is a configuration rule that runs upon receipt of the TEC_Startevent, which is sent during intialization of the event server. This rule first loads theauxiliary predicates used by the dependency rules and any persistent dependencyrelationships previously defined; it then sets global parameters for the dependencyrules and initializes the log files for the rule set.

By customizing this rule, you can configure the behavior of the dependency rules.See “Usage” on page 11 for more information.

rule: shutdownThe shutdown rule runs upon receipt of the TEC_Stop event, which is sent whenthe event server shuts down. This rule closes any open log files for the rule set.

Dependency processing rule

rule: process_opThe process_op rule processes TEC_Dependency events, which are sent by the wrb–imptdp and wrb –deldp commands. When this event is received, the rule updatesthe dependency knowledge base accordingly (asserting or retracting a dependencyfact), and then it drops the event.


e-business rule set (ebusiness.rls)

OverviewThe e-business rule set analyzes events related to e-business resources in order todetermine whether they are causally related to one another, or to network events.This analysis relies upon user-defined dependency relationships stored as facts inthe knowledge base. These relationships define dependencies among e-businessservices running on different hosts in your environment.

Supported e-business services include those provided by IBM WebSphereApplication Server, IBM DB2 software, and IBM WebSphere MQ. These servicesfrequently depend upon the availability of other e-business services. WebSphereApplication Server services on one host might depend upon the availability of DB2services on another host. Similarly, two interconnected WebSphere MQ hosts eachdepend upon the availability of the other. By using the e-business rule set, you canidentify these dependencies, making it possible for the rule engine to identifycausal relationships between events received from these services. (See “Usage” onpage 16 for information about defining these relationships.) Currently, two kinds ofdependency relationships are supported:

WMQ_DEPENDS_ON_WMQIndicates that a WebSphere MQ resource on one host is dependent upon aWebSphere MQ resource on another host.

WAS_DEPENDS_ON_DB2Indicates that a WebSphere Application Server resource on one host isdependent upon a DB2 resource on another host, or on the same host.

For example, suppose host appserver is running WebSphere Application Serverservices that depend upon DB2 services on host dbserver. In this case, you woulddefine a dependency fact indicating a WAS_DEPENDS_ON_DB2 relationship between thetwo hosts. If the event server receives an event indicating a problem with the DB2services on dbserver, and later receives an event indicating a database-availabilityproblem with the WebSphere Application Server services on appserver, it is likelythat the DB2 problem is the cause of the WebSphere Application Server problem.Because the knowledge base contains a dependency fact describing thisrelationship, the event server can automatically associate the two events as causallyrelated. Similarly, the event server can identify other cause events that might affectthe availability of dbserver, such as service-impact network events andmaintenance events.

WAS DB2

appserver dbserver

Figure 1. Dependency relationship between WebSphere Application Server and DB2 services


In addition, the e-business rules can optionally generate probable-causeinformational events in cases where a likely causal relationship is found but cannotbe matched to a defined dependency fact. This can happen if no dependencyrelationship is defined for the hosts involved, or if the NetView component is notconfigured to generate service-impact events.

The following table summarizes the categories of possible effect and cause events.(For detailed information about specific cause and effect events, see “Rules” onpage 19.)

Table 2. Categories of cause and effect events for the e-business rules

Effect eventsCause events

e-business network maintenance

WebSphereApplication Serverevents

DB2 eventsNetView nodeservice impact events(DB2 services)

TEC_MaintenanceWebSphere MQevents

WebSphere MQevents

NetView nodeservice impact events(WebSphere MQservices)

The e-business events analyzed by the e-business rules are generated by thefollowing products:v IBM Tivoli Monitoring for Business Integration: WebSphere MQ (WebSphere MQ

events)v IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server

(WebSphere Application Server events)v IBM Tivoli Monitoring for Databases: DB2 (DB2 events)

For more information about e-business events, refer to the documentation for theseproducts.

In addition to associating causally related ebusiness and network events, thee-business rules also generate TEC_Heartbeat_missed events in response toheartbeat status events from IBM Tivoli Monitoring. This event can be processedby the heartbeat rule set (heartbeat.rls) or NetView rule set (netview.rls), if thoserule sets are active.

How events are analyzedThe primary analysis of e-business events is handled by the rules in the ″EventAssociation″ section of the e-business rule set. These are the rules that identifycausal relationships between e-business and network events based upon thedependency relationships you define.

When an effect event related to WebSphere Application Server or WebSphere MQservices arrives, the e-business rules search the knowledge base for a dependencyfact involving the host and service that generated the event. If the effect event isrelated to WebSphere Application Server services, the rule searches for aWAS_DEPENDS_ON_DB2 dependency fact; if the effect event is related to WebSphereMQ services, the rule searches for a WMQ_DEPENDS_ON_WMQ dependency fact.

If found, the dependency fact indicates the fully qualified host name of the hostupon which the e-business service depends (the host providing the required DB2or WebSphere MQ services). The rules then search the event cache for a cause


event originating from the specified host and affecting the relevant service. Thereare three categories of cause events, searched for in the following order:v An e-business cause event. An e-business cause event is an event originating a

host and e-business service identified by a dependency fact. This can be either aDB2 cause event sent by IBM Tivoli Monitoring for Databases: DB2 or aWebSphere MQ cause event sent by IBM Tivoli Monitoring for BusinessIntegration: WebSphere MQ. The specific class of the cause event depends uponthe class of the effect event and the type of dependency. If an e-business causeevent is found, the effect event is associated with it using thelink_effect_to_cause predicate.

v A network cause event. A network cause event is a NetView node serviceimpact event specifying a host identified by a dependency fact and affecting therelevant service. This can be a TEC_ITS_NODE_SERVICE_IMPACT event withthe sub_source attribute equal to either IBM_DB2 or IBM_WebSphere_MQ, dependingupon the type of dependency. If a service impact cause event is found, it islikely that the monitored host cannot send an e-business cause event because ofthe network problem. Therefore, the service impact event is considered the causeevent, and the effect event is associated with it using the link_effect_to_causepredicate. If the effect event is of low severity (HARMLESS or UNKNOWN), the effectevent is also automatically acknowledged.

v A maintenance cause event. This event indicates that the specified host hasentered maintenance mode. A maintenance cause event is a TEC_Maintenanceevent with current_mode equal to ON and specifying a host identified by adependency fact. Because all other events from a host in maintenance mode aretypically discarded, in this case the maintenance event itself is considered thecause event. If a maintenance cause event is found, the effect event is associatedwith it using the link_effect_to_cause predicate. (For more information abouthandling maintenance events, see “Maintenance mode rule set(maintenance_mode.rls)” on page 39.)

If a cause event cannot be identified from one of these three categories, the rulescan optionally continue searching for an indication of a probable cause event. (Thisfunction is enabled or disabled by the ebusiness_hints parameter; see “Usage” onpage 16 for more information.) If this function is enabled, the rules continuesearching for the following categories of probable cause events (in the followingorder):v A network probable cause event. A network probable cause event is a NetView

TEC_ITS_NODE_STATUS event with nodestatus equal to either MARGINAL orDOWN and originating from a host identified by a dependency fact. If this event isfound, it indicates that there is a network problem with the specified host, butthe NetView component is not configured to generate service impact events.Instead, the rules generate an informational TEC_ITS_Not_Monitoring_eBusinessevent specifying the effect event and the probable network cause event. Thisevent indicates that NetView needs to be configured to monitor the relatede-business service.

v An e-business probable cause event. An e-business probable cause event is anevent originating from the type of service identified by a dependency fact, butnot from a matching host. This might indicate that the correct dependencyrelationships have not been defined. If an e-business probable cause event isfound, the rules generate an informationalTEC_PROBABLE_EVENT_ASSOCIATION event specifying the effect event andthe probable cause event. This event indicates that the defined dependencyrelationships may need to be updated.

e-business rule set (ebusiness.rls) 15

In some situations, an effect event might arrive before the cause event. If thishappens, the rules cannot identify the causal relationship when the effect eventarrives, because the cause event is not yet in the event cache. In order to handlethis situation, when a potential cause event arrives, the rules repeat thedependency analysis for any possible effect events already in the event cache.

Note: Because of the potential performance impact, reanalysis does not take placefor TEC_Maintenance or TEC_ITS_NODE_STATUS events. In order forassociation to take place, these events must already be in the event cachewhen e-business effect events arrive.

UsageThe e-business rule set is already activated in the default rule base. If you makeany changes to this rule set, you must then recompile and reload the rule base. See“Modifying the rule base” on page 2 for more information.

Note: If activated, the e-business rule set should be listed near the end of therule_sets file (following the NetView rule set, if that rule set is active). Inaddition, the dependency rule set (dependency.rls) provides requiredsupport for the e-business rule set. If the e-business rule set is active, thedependency rule set must also be active.

ConfigurationThe e-business rule set is preconfigured and ready to use. However, you cancustomize this rule set by modifying statements in the startup configuration rule.The following options are configurable:v Generation of informational events. You can specify whether you want the

rules to generate informational TEC_PROBABLE_EVENT_ASSOCIATION andTEC_ITS_Not_Monitoring_eBusiness events. These events are generated in caseswhere a probable cause event is found, but there is insufficient information for acausal association. (See “How events are analyzed” on page 14 for moreinformation.) By default, this function is enabled; if you want to change thispreference, modify the statement that sets the ebusiness_hints parameter asfollows:rerecord(ebusiness_hints, ’no’),

v Debug logging. You can specify whether you want debugging informationwritten to a log file. This can be useful for testing modifications to the rule set.This function should always be disabled before the rule set is deployed in aproduction environment because it can affect performance. To enable or disabledebugging messages, modify the statement that sets the ebusiness_debugparameter as follows:rerecord(ebusiness_debug, flag),

flag is either ’yes’ or ’no’.v Debug log file name. You can specify the name of the file used for logging

debuging messages. This file is used only if ebusiness_debug is set to yes. You caneither specify an absolute location for the file or specify the file name only, inwhich case the file is created in the $DBDIR directory. The default value isebusiness.log. To specify a different file, modify the statement that sets theebusiness_logger parameter as follows:rerecord(ebusiness_logger, filename),



v Administrator name. You can specify the administrator name to use when thee-business rules automatically acknowledge or close events. The defaultadministrator name is ebusiness.rls. To change the administrator name, modifythe statement that sets the ebusiness_admin parameter as follows:rerecord(ebusiness_admin, admin),

admin is the administrator name to use, enclosed in single quotation marks.v Latency. You can specify the time range to be used when searching the event

cache for events to associate. This time range affects both backward and forwardevent searches. By default, searches are limited to ten minutes (600 seconds)backward or forward in the event cache. To change the latency, modify thestatement that sets the ebusiness_latency parameter as follows:rerecord(ebusiness_latency, seconds),

seconds is the number of seconds representing how far backward or forward youwant to search the cache for events.

Note: This parameter sets an upper limit on how far back in time the search willgo, but it does not guarantee that events within that time period will stillbe available. If your event cache is too small, events might be discardedeven if they are more recent than the specified time. If this happens,consider increasing the size of your event cache. (See the IBM TivoliEnterprise Console User’s Guide for more information.)

Defining dependency relationshipsBefore using the e-business rule set, you must define the dependency relationshipsthat apply to the e-business services and network resources in your environment.To define these relationships, create a text file containing a series of dependencystatements, each of which will be converted into a dependency fact in theknowledge base. Each dependency statement is on a separate line, and eachstatement consists of three parts, separated by white space:host_a dependency_type host_b

host_a is the fully qualified name of the host that has a dependency on anotherhost, dependency_type is the nature of the dependency, and host_b is the fullyqualified name of the host upon which host_a depends. The following exampleshows three dependency statements:mq1.raleigh.ibm.com WMQ_DEPENDS_ON_WMQ mq2.raleigh.ibm.commq2.raleigh.ibm.com WMQ_DEPENDS_ON_WMQ mq1.raleigh.ibm.comappserver.raleigh.ibm.com WAS_DEPENDS_ON_DB2 appserver.raleigh.ibm.com

These statements define the following dependency relationships (see Figure 2 onpage 18):v The first statement indicates that WebSphere MQ services on

mq1.raleigh.ibm.com depend upon WebSphere MQ services onmq2.raleigh.ibm.com.

v The second statement indicates that WebSphere MQ services onmq2.raleigh.ibm.com depend upon WebSphere MQ services onmq1.raleigh.ibm.com.

v The third statement indicates that WebSphere Application Server services onappserver.raleigh.ibm.com depend upon the availability of DB2 servicesrunning on the same host.


Note: Each dependency fact represents a single, unidirectional dependencyrelationship. Therefore, if two interconnected hosts have mutualdependencies on one another, you must define a separate dependency factfor each direction of the relationship. This is typically the case forWMQ_DEPENDS_ON_WMQ relationships, as in the previous example.

After you finish defining dependency relationships in the text file, use the wrb–imptdp command to load these relationships into the knowledge base asdependency facts:wrb -imptdp filename

filename is the name of the text file containing the dependency statements.

To remove dependency relationships, use the wrb –deldp command:wrb -deldp filename

filename is the name of a text file containing dependency statements you want toremove from the knowledge base.

Note: Before using wrb –imptdp or wrb –deldp, make sure the event server isrunning, and that the dependency rule set (dependency.rls) is activated.

Dependency facts are persistent, so you do not need to reload dependencyrelationships after stopping and restarting the event server.

For more information about the wrb –imptdp or wrb –deldp commands, see theIBM Tivoli Enterprise Console Command and Task Reference.

WMQ WMQ

WAS

DB2

mq1.raleigh.ibm.com mq2.raleigh.ibm.com

appserver.raleigh.ibm.com

Figure 2. Example of dependency relationships. Each arrow represents a unidirectional″depends on″ relationship.


Rules


rule: startupThe startup rule is a configuration rule that runs upon receipt of the TEC_Startevent, which is sent during intialization of the event server. This rule first loads theauxiliary predicates used by the e-business rules; it then sets global parameters forthe e-business rules and initializes the log files for the rule set.

By customizing this rule, you can configure the behavior of the ebusiness.rls ruleset. See “Usage” on page 16 for more information.

rule: shutdownThe shutdown rule runs upon receipt of the TEC_Stop event, which is sent whenthe event server shuts down. This rule closes the log file for the e-business rule set.

Heartbeat rules

rule: generate_heartbeat_missedThe generate_heartbeat_missed rule generates a TEC_Heartbeat_missed eventwhen one of the following heartbeat status events is received from the IBM TivoliMonitoring product:v HeartBeat_Offv HeartBeat_EndpointUnreachablev HeartBeat_DMAgentDownv HeartBeat_ResourceModelsInError

When one of these events is received, the rule generates a TEC_Heartbeat_missedevent, duplicating the attribute values from the received event. (For moreinformation about heartbeat status events, refer to the IBM Tivoli Monitoringdocumentation.)

rule: link_heartbeat_missedThe link_heartbeat_missed rule associates the TEC_Heartbeat_missed effect eventsgenerated by the generate_heartbeat_missed rule with the cause events receivedfrom the IBM Tivoli Monitoring product. The effect events are associated with thecause events using the link_effect_to_cause predicate.

Case manipulation rules

rule: lower_itmThe lower_itm rule runs upon receipt of a potential e-business cause or effect eventfrom an e-business service. This rule converts the value of the fqhostname attributeto all lowercase letters, in order to prevent mismatches when performingcase-sensitive comparisons.

rule: lower_itsThe lower_its rule runs upon receipt of a potential network cause event from theNetView component. This includes any TEC_ITS_NODE_SERVICE_IMPACT eventwith sub_source equal to IBM_DB2 or IBM_WebSphere_MQ. This rule converts thevalue of the fqhostname attribute to all lowercase letters, in order to preventpossible mismatches when performing case-sensitive comparisons.


rule: lower_tecThe lower_tec rule runs upon receipt of a potential maintenance cause event. Thisincludes any TEC_Maintenance event with current_mode equal to ON. This ruleconverts the value of the fqhostname attribute to all lowercase letters, in order toprevent possible mismatches when performing case-sensitive comparisons.

rule: lower_nodeThe lower_node rule runs upon receipt of potential network probable-cause eventsfrom the NetView component. This includes any TEC_ITS_NODE_STATUS eventwith nodestatus equal to MARGINAL or DOWN. This rule converts the value of thefqhostname attribute to all lowercase letters, in order to prevent possiblemismatches when performing case-sensitive comparisons.

Event association rules

rule: associate_wmq_wmqThe associate_wmq_wmq rule runs upon receipt of an effect event from a WebSphereMQ service and attempts to associate it with a cause event that matches a definedWMQ_DEPENDS_ON_WMQ dependency relationship. The following table shows the effectevents analyzed by this rule and the possible e-business cause events.

Table 3. Effect and cause events for the associate_wmq_wmq rule

Effect event Possible e-business cause events

WebSphere_MQ_ChannelNotActivated WebSphere_MQ_QueueManagerUnavailableWebSphere_MQ_ChannelNotTransmittingWebSphere_MQ_ChannelStartupError

WebSphere_MQ_ChannelThroughputProblem WebSphere_MQ_QueueFilling

WebSphere_MQ_ChannelNotTransmitting WebSphere_MQ_QueueManagerUnavailableWebSphere_MQ_ChannelNotActivated

WebSphere_MQ_ChannelStartupError WebSphere_MQ_QueueManagerUnavailableWebSphere_MQ_ChannelNotActivated

If no e-business cause event is found, the rule attempts to find a network(TEC_ITS_NODE_SERVICE_IMPACT) or maintenance (TEC_Maintenance) causeevent. If no cause event is found, but informational events are enabled, the rulethen attempts to find a probable cause event. See “How events are analyzed” onpage 14 for more information.

rule: associate_was_db2The associate_was_db2 rule runs upon receipt of an effect event from a WebSphereApplication Server service and attempts to associate it with a cause event thatmatches a defined WAS_DEPENDS_ON_DB2 dependency relationship. The followingtable shows the effect events analyzed by this rule and the possible e-businesscause events.

Table 4. Effect and cause events for the associate_was_db2 rule


WebSphereAS_high_DBPool_faults DB2_Down_StatusDB2_High_ConnectionErrors

WebSphereAS_high_DBPool_avgWaitTime DB2_High_ConnWaitingForHostDB2_High_MostRecentConnectResponseDB2_High_DB2ApplicationAgent_TotUserCpuTimeDB2_High_ApplicationAgent_TotSystemCpuTime


Table 4. Effect and cause events for the associate_was_db2 rule (continued)


WebSphereAS_high_Transaction_avg_response_time DB2_High_HostTimePerStatementDB2_High_NetworkTimePerStatementDB2_High_TimePerStatementDB2_High_InstanceAgents_PctAgentsWaitingDB2_High_ApplicationAgents_WorkloadDB2_High_InstanceAgents_AgentCreationRatioDB2_High_DB2ApplicationAgent_TotUserCpuTimeDB2_High_ApplicationAgent_TotSystemCpuTime

WebSphereAS_high_Transaction_timeout_ratio DB2_Down_StatusDB2_High_HostTimePerStatementDB2_High_NetworkTimePerStatementDB2_High_TimePerStatementDB2_High_InstanceAgents_PctAgentsWaitingDB2_High_ApplicationAgents_WorkloadDB2_High_InstanceAgents_AgentCreationRatioDB2_High_DB2ApplicationAgent_TotUserCpuTimeDB2_High_ApplicationAgent_TotSystemCpuTime

WebSphereAS_high_DBPool_percentUsed DB2_High_PctConnectionsUsedDB2_High_CurrentConnections

If no e-business cause event is found, the rule attempts to find a network(TEC_ITS_NODE_SERVICE_IMPACT) or maintenance (TEC_Maintenance) causeevent. If no cause event is found, but informational events are enabled, the rulethen attempts to find a probable cause event. See “How events are analyzed” onpage 14 for more information.

rule: redo_its_wmqThe redo_its_wmq rule handles cases where network cause events and WebSphereMQ effect events arrive out of sequence. This rule runs upon receipt of anyTEC_ITS_NODE_SERVICE_IMPACT event specifying WebSphere MQ services.When this potential cause event is received, the rule uses the redo_analysispredicate to request reanalysis of possible WebSphere MQ effect events that mighthave arrived earlier in order to determine whether they are effects of the newlyreceived cause event. These effect events are those that are analyzed by theassociate_wmq_wmq rule.

rule: redo_its_wasThe redo_its_was rule handles cases where network cause events and WebSphereApplication Server effect events arrive out of sequence. This rule runs upon receiptof any TEC_ITS_NODE_SERVICE_IMPACT event specifying WebSphereApplication Server services. When this potential cause event is received, the ruleuses the redo_analysis predicate to request reanalysis of possible WebSphereApplication Server effect events that might have arrived earlier in order todetermine whether they are effects of the newly received cause event. These effectevents are those analyzed by the associate_was_db2 rule.

rule: redo_wmq_wmqThe redo_wmq_wmq rule handles cases where WebSphere MQ cause events andWebSphere MQ effect events arrive out of sequence. This rule runs upon receipt ofa WebSphere MQ event that is a potential cause event. When this event is received,the rule uses the redo_analysis predicate to request reanalysis of possibleWebSphere MQ effect events that might have arrived earlier in order to determinewhether they are effects of the newly received cause event. The cause and effectevents are those analyzed by the associate_wmq_wmq rule.


rule: redo_db2_wasThe redo_db2_was rule handles cases where DB2 cause events and WebSphereApplication Server effect events arrive out of sequence. This rule runs upon receiptof a DB2 event that is a potential cause event. When this event is received, the ruleuses the redo_analysis predicate to request reanalysis of possible WebSphereApplication Server effect events that might have arrived earlier in order todetermine whether they are effects of the newly received cause event. The causeand effect events are those analyzed by the associate_was_db2 rule.


Escalation rule set (escalate.rls)

OverviewThe escalation rule set contains rules that can increase the severity of events thathave not been handled within a specified period of time. When used along withthe notification rule set, the escalation rules also trigger automatic e-mail or pagernotification of event escalation. (See “Notification rule set (notify.rls)” on page 59for more information about the notification rule set.)

UsageThe escalation rule set is not activated in the default rule base. Before you can usethis rule set, you must activate it. See “Modifying the rule base” on page 2 formore information on activating rule sets.

Note: If activated, the escalation rule set should be listed near the end of therule_sets file (following the correlation rule set, if that rule set is active). Inaddition, the notification rule set (notify.rls) provides required support fore-mail notification. If you want the escalation rules to trigger e-mailnotification, notify.rls must also be active. See “Rule set sequencing anddependencies” on page 3 for more information.

Optional configurationThe escalation rule set is preconfigured and ready to use. By default, this rule set isconfigured only to trigger e-mail or pager notification for FATAL events that requireescalation; this function requires that the notification rule set (notify.rls) also beconfigured and active. (Severities are not increased because FATAL events arealready at their maximum severity.) If you want to escalate events with severitiesother than FATAL, you must customize the rule set by modifying the statements inthe escalate_parameters action of the escalate_configure rule.

The following options are configurable:v Administrator name. You can specify the administrator name to use when

changing event severity. The default administrator name is escalate.rls. Tochange the administrator name, modify the statement that sets the_escalate_admin parameter as follows:_escalate_admin = admin,

admin is the administrator name to use, enclosed in single quotation marks.v Escalation check frequency. You can specify how frequently you want the

escalation rules to check the event cache for events that need to be escalated.The default frequency is every 60 seconds. To change this frequency, modify thestatement that sets the _escalate_timer parameter as follows:_escalate_timer = seconds,

seconds is the length of time (in seconds) you want to elapse between escalationchecks.

v Latency. You can specify how far back in the event cache you want to search forevents to escalate. The default is 30 days. To change the latency, modify thestatement that sets the _esc_search_time parameter as follows:


_escalate_search_time = seconds,

seconds is the number of seconds representing how far backward you want tosearch the cache for events.

v Housekeeping frequency. You can specify how frequently you want theescalation rules to remove references to escalated events that are no longer in theevent cache. When an event is escalated, the rules assert an escalation fact in theknowledge base. The housekeeping rule periodically checks to ensure that eachescalation fact refers to an event that is still in the event cache. When an event isremoved from the cache because of its age or because of space limitations, thehousekeeping rule removes the associated escalation fact from the knowledgebase. The default housekeeping frequency is 86 400 seconds (24 hours). Tochange this frequency, modify the statement that sets the _esc_housekeeping_timerparameter as follows:_esc_housekeeping_timer = seconds,

seconds is the length of time (in seconds) you want to elapse betweenhousekeeping checks.

v Whether to increase event severity. You can specify whether you want the rulesto automatically increase the event severity when an event is to be escalated. Ifthis option is disabled, the escalation rules do not change event severity, but stilltrigger notification by the notification rules (if notify.rls is active). By default, theescalation rules do not change event severity. To change this behavior, modifythe statement that sets the _escalate_increase_severity parameter as follows:_escalate_increase_severity = flag,

flag is either ’true’ or ’false’.v Classes to escalate. You can specify that you want only certain classes of events

to be escalated. By default, the escalation rules are applied only to TEC_Errorand TEC_DB events. If you want to add other classes, modify the statement thatsets the _escalate_class_list parameter as follows:rerecord(escalate_class_list,[

ev_classes]

)

ev_classes is a list of event classes, each enclosed in single quotation marks,separated by commas. If you want to apply the escalation rules to all classes,comment out this line and leave _escalate_class_list undefined.

v Escalation time limits. You can specify the amount of time events should beallowed to remain in ACK or OPEN status at each level of severity. For each levelof severity at which you want escalation to take place, include the followingstatement:assert(escalate_severity_timers(severity, open_ack_time, ack_close_time)),

severity is the severity level enclosed in single quotation marks, open_ack_time isthe number of seconds to allow an event to remain open before escalation, andack_close_time is the number of seconds to allow an event to remainacknowledged before escalation. A value of zero for open_ack_time orack_close_time specifies no time limit. By default, the only severity level forwhich escalation time limits are defined is FATAL:assert(escalate_severity_timers(’FATAL’, 43200, 0),

This statement specifies that FATAL events are allowed to remain in OPEN state for12 hours and in ACK status indefinitely. To change these time limits, modify the


statement accordingly. To specify escalation for additional severity levels,uncomment the corresponding statements and modify the time limits ifnecessary.

Rules

rule: escalate_configureThe escalate_configure rule is a configuration rule that runs upon receipt of theTEC_Start event, which is sent during initialization of the event server. Bycustomizing this rule, you can configure the behavior of the escalation rules. See“Usage” on page 23 for more information.

rule: check_cache_for_escalationThe check_cache_for_escalation rule runs upon receipt of the Escalate_eventevent, which is periodically generated by the escalate_old_events timer rule.When Escalate_event is received, the rule searches the event cache for any eventsthat have remained in ACK or OPEN status longer than the allowed period of time. Ifa class list is defined using the escalate_class_list configuration parameter, thissearch is limited to the classes specified in that list.

For each matching event, the rule first checks the knowledge base for acorresponding escalation fact (which indicates that the event has already beenescalated). If no escalation fact is found, a timer is set with a duration of onesecond, in order to trigger immediate escalation by the escalate_specific_eventtimer rule. An escalation fact is then asserted in the knowlege base for theescalated event, and the received Escalate_event event is dropped.

timer_rule: escalate_old_eventsThe escalate_old_events timer rule periodically generates Escalate_event events,which trigger the check_cache_for_escalation rule. The rule then resets theEscalate timer in order to trigger the next check. The duration of this timer isdetermined by the _escalate_timer parameter in the escalate_parametersconfiguration rule.

timer_rule: escalate_specific_eventThe escalate_specific_event rule handles escalation. This rule runs uponexpiration of any Escalate_open or Escalate_ack timer; this timer is set by thecheck_cache_for_escalation rule when an event is found that has remained in ACKor OPEN status too long. When the timer expires, the escalate_specific_event rulefirst checks to see if the event has been taken out of ACK or OPEN status since thetimer was set. If this has happened, the rule retracts the associated escalation factand then exits the rule.

If the event is still in ACK or OPEN status, the rule takes one of the following actions:v If the _escalate_increase_severity parameter is set to true, the severity of the event

is increased (unless it is already FATAL, in which case it is reset to FATAL).v If the _escalate_increase_severity paramter is set to false, the severity of the event

is reset to its current value.

In either case, because the severity is reset, the change rules in the notification ruleset are triggered, if that rule set is active.

Escalation rule set (escalate.rls) 25

timer_rule: escalate_housekeepingThe escalate_housekeeping rule runs upon expiration of theEscalate_housekeeping timer, which is set by the configuration rule based uponthe duration specified by the _esc_housekeeping_timer parameter. When the timerexpires, the escalate_housekeeping rule checks the event cache for each event forwhich an escalation fact exists in the knowledge base. If any escalated events areno longer in the event cache, the rule retracts the corresponding escalation factsfrom the knowledge base. It then resets the timer.


Event activity rule set (event_activity.rls)

OverviewThe event activity rule set contains rules that support the generation of eventactivity reports.

UsageThe event activity rule set is not activated in the default rule base. Before you canuse this rule set, you must activate it. See “Modifying the rule base” on page 2 formore information on activating rule sets.

Optional configurationThe event activity rule set is preconfigured and ready to use. However, you cancustomize this rule set by modifying statements in the event_activity_parametersaction of the event_activity_start configuration rule. These statements affect thebehavior of the rule set, including the arguments passed to theinit_event_activity predicate (see the IBM Tivoli Enterprise Console RuleDeveloper’s Guide for more information about this predicate and its arguments). Thefollowing options are configurable:v Reporting frequency. You can specify the frequency with which updates are

written to the event activity output file. The default frequency is every 20seconds. To change the frequency, modify the statement that sets the_reporting_frequency parameter as follows:_reporting_frequency = seconds,

seconds is the length of time, in seconds, you want to pass between updates tothe output file.

v Output file name. You can specify the name of the output file to which theevent activity report is written. This value is passed as the _file argument of theinit_event_activity predicate. The default output file is/tmp/event_activity.log. To change the file name, modify the statement thatsets the _reporting_file parameter as follows:_reporting_file = filename,

filename is the name of the output file you want to use, optionally including arelative or absolute path, and enclosed in single quotation marks.

v Classes to exclude. You can specify a list of event classes you do not want to beincluded in the event activity log. This value is passed as the _event_exclusionsargument of the init_event_activity predicate. The default behavior is toexclude TEC_Heartbeat and TEC_Maintenance events. To change this list,modify the statement that sets the _do_not_report_classes parameter as follows:_do_not_report_classes = exclude_list

exclude_list is a list of valid event classes, each enclosed in single quotationmarks, and separated by commas.

v Count threshold. The minimum attribute count to include in the activity report.This value is passed as the _threshold argument of the init_event_activitypredicate. The default threshold is 5. To change this value, modify the statementthat sets the _do_not_report_count parameter as follows:


_do_not_report_count = threshold,

threshold is the minimum count you want included in the activity report.v Reporting criteria. You can specify the list of event attributes whose values you

want to be counted for the event activity report. This value is passed as the_attribute_criteria argument of the init_event_activity predicate. The default listis:[source,hostname,severity,status,[hostname, severity],[class, hostname]]

To change this value, modify the statement that sets the _reporting_criteriaparameter as follows:_reporting_criteria = [criteria],

criteria is a list containing single attributes or multiple-attribute groups. For moreinformation on how to specify the attribute criteria, see the description of theinit_event_activity predicate in the IBM Tivoli Enterprise Console RuleDeveloper’s Guide.

Rules

Startup rule

rule: event_activity_configureThe event_activity_configure rule is a configuration rule that runs upon receiptof the TEC_Start event, which is sent during initialization of the event server. Bycustomizing this rule, you can configure the behavior of the escalation rules. See“Usage” on page 27 for more information.

Event activity rules

rule: update_event_activityThe update_event_activity rule runs upon receipt of any event. It collect eventactivity statistics based upon the criteria specified in the event_activity_configurerule.

timer_rule: reset_event_activityThe reset_event_activity timer rule periodically writes the event activity statisticsto the output file, based upon the frequency and file name specified in theevent_activity_configure rule. After the report has been written, all of thestatistics are reset to zero.


Event filtering rule set (event_filtering.rls)

OverviewThe event filtering rule set contains rules that filter out unwanted events based oncustomizable criteria. Filtered events do not appear at any console and are notstored in the event cache.

UsageThe event filtering rule set is not activated in the default rule base. Before you canuse this rule set, you must activate it. See “Modifying the rule base” on page 2 formore information on activating rule sets.

Note: If activated, the event filtering rule set should be listed near the beginningof the rule_sets file, preferably first. See “Rule set sequencing anddependencies” on page 3 for more information.

Before using this rule set, you should also modify the event_filtering_parametersaction of the event_filtering_configure rule to specify any additional eventcriteria you want to use to filter events. These criteria are defined using thecreate_event_criteria predicate (see the IBM Tivoli Enterprise Console RuleDeveloper’s Guide for more information about this predicate). Eachcreate_event_criteria statement defines a named filter specifying a class name,severity, attribute values, and other criteria; incoming events can be compared tothis filter in order to determine whether they should be dropped. As an example,two filtering criteria are defined in the rule set:

harmless_heartbeatEvents of class TEC_Heartbeat with severity HARMLESS

harmless_maintenanceEvents of class TEC_Maintenance with severity HARMLESS

To define additional criteria, add statements using the create_event_criteriapredicate.


Rules

Startup rule

rule: event_filtering_configureThe event_filtering_configure rule is a configuration rule that runs upon receiptof the TEC_Start event, which is sent during initialization of the event server. Thisrule uses the create_event_criteria predicate to define the criteria for eventfiltering. By customizing this rule, you can configure the behavior of the eventfiltering rules. See “Usage” for more information.


Event filtering rule

rule: filter_eventThe filter_event rule runs upon receipt of any event. When an event is received,the rule checks to see if the event matches any of the criteria defined in theevent_filtering_configure rule. Any matching event is dropped.


Event threshold rule set (event_thresholds.rls)

OverviewThe event threshold rule set contains rules that check for a certain number ofduplicate events within a specified length of time. If this count is exceeded, theseverity of the current event is increased.

UsageThe event threshold rule set is not activated in the default rule base. Before youcan use this rule set, you must activate it. See “Modifying the rule base” on page 2for more information on activating rule sets.

Before using this rule set, you should also modify theevent_thresholds_parameters action of the event_thresholds_configure rule todefine the thresholds used by the rule set. Each unique threshold requires threeseparate statements:v The create_event_criteria predicate defines a named filter specifying the kind

of event you want to check for. For more information, see the IBM TivoliEnterprise Console Rule Developer’s Guide.

v The create_cache_search_criteria predicate defines a named event-cachesearch, specifying the previously defined event criteria and other searchparameters. For more information, see the IBM Tivoli Enterprise Console RuleDeveloper’s Guide.

v The create_threshold predicate defines a threshold that, when exceeded,triggers an increase of the current event’s severity. The threshold specifies aperiod of time (in seconds) and an event threshold count; if more than thespecified number of matching events are received within the specified period oftime, the threshold is exceeded. For more information, see the IBM TivoliEnterprise Console Rule Developer’s Guide.

By default, the event_thresholds_configure rule configures two thresholds:v Five duplicate CRITICAL events within 60 seconds.v Ten duplicate MINOR events within 60 seconds.

To define additional thresholds, add statements to the event_thresholds_configurerule using the create_event_criteria, create_cache_search_criteria, andcreate_threshold predicates.


Rules

Startup rule

rule: event_thresholds_configureThe event_thresholds_configure rule is a configuration rule that runs upon receiptof the TEC_Start event, which is sent during initialization of the event server. This


rule defines the thresholds for the rule set. By customizing this rule, you canconfigure the behavior of the event threshold rules. See “Usage” on page 31 formore information.

Threshold rule

rule: threshold_ruleThe threshold_rule rule runs upon receipt of any event. When an event isreceived, the rule applies the threshold criteria defined in theevent_thresholds_configure configuration rule and, if a threshold is exceeded,increases the severity of the event. In addition, the rule updates the repeat_countattribute of the current event to reflect the number of duplicate events.


Forwarding rule set (forwarding.rls)

OverviewThe event forwarding rule set contains rules that implement automatic forwardingof events to another event server.

UsageThe event forwarding rule set is not activated in the default rule base. Before youcan use this rule set, you must activate it. See “Modifying the rule base” on page 2for more information on activating rule sets.

You must also define the location of the event server to which events areforwarded. The destination server for the event forwarding function is specified bythe tec_forward.conf configuration file. By default, this file specifies that the eventforwarding function should operate in test mode, which sends events to a file. Tospecify a server, you must modify the value of the ServerLocation keyword tospecify the destination server. You must also specify TestMode=NO or comment outthe TestMode keyword entirely. For more information about configuration filekeywords, see the IBM Tivoli Enterprise Console Event Integration Facility Reference.

You must also modify the forwarding_parameters action of theforwarding_configure rule to specify the event criteria you want to determinewhich events are forwarded. These criteria are defined using thecreate_event_criteria predicate (see the IBM Tivoli Enterprise Console RuleDeveloper’s Guide for more information about this predicate).

Each create_event_criteria statement defines a named filter specifying a classname, severity, attribute values, and other criteria; incoming events can becompared to this filter in order to determine whether they should be forwarded.As an example, two forwarding criteria are defined in the rule set:

ups_fatal_forwardingEvents of class upsDischarged with severity FATAL

temp_alarm_forwardingEvents of class chassisAlarmOffTempAlarm with severity WARNING or FATAL

To define your own criteria, add statements using the create_event_criteriapredicate.


Rules

Startup rule

rule: forwarding_configureThe forwarding_configure rule is a configuration rule that runs upon receipt of theTEC_Start event, which is sent during initialization of the event server. This ruleuses the create_event_criteria predicate to define the criteria for event


forwarding. By customizing this rule, you can configure the behavior of the eventforwarding rules. See “Usage” on page 33 for more information.

Event forwarding rule

rule: forwarding_eventsThe forwarding_events rule runs upon receipt of any event. When an event isreceived, the rule checks to see if the event matches any of the criteria defined inthe forwarding_configure rule. Any matching event is forwarded to the eventserver specified in the tec_forward.conf configuration file.


Heartbeat rule set (heartbeat.rls)

OverviewThe heartbeat rule set contains rules that support heartbeat monitoring. These rulesprocess incoming TEC_Heartbeat pulse events sent from monitored hosts. If anexpected pulse is missed, notification is sent to the console and also to anadministrator by e-mail.

Heartbeat monitoring for a given host begins upon receipt of the firstTEC_Heartbeat event from that host. There are five possible levels of heartbeatmonitoring; the level of monitoring for a particular host is determined by the valueof the level attribute of the TEC_Heartbeat events from that host. (This value is ofthe enumerated type HEARTBEAT_LEVEL, which is defined in the tec.baroc file.) Thelevel of monitoring controls how frequently heartbeats are expected, as well as theseverity of missed-heartbeat events. The possible levels are:

Table 5. Heartbeat monitoring levels

Level Pulse frequency Severity of missed pulse

ONE Every 60 seconds FATAL

TWO Every 5 minutes CRITICAL

THREE Every 10 minutes MINOR

FOUR Every 30 minutes WARNING

FIVE Every 60 minutes HARMLESS

You can change these values by modifying the heartbeat_configure rule.

When an expected heartbeat pulse is received from a monitored host, the eventserver records the time of the pulse and drops the event. As long as no heartbeatsare missed, no events are routed to the console.

If an expected heartbeat pulse is not received from a monitored host, the rulesgenerate a TEC_Heartbeat_missed event whose whose msg attribute indicates that apulse has been missed, using the severity indicated by the monitoring levelcurrently in effect for the monitored host. Because this event is not dropped, theyappear at the console, notifying the operator that a monitored system might bedown. In addition, an e-mail notification is sent to the administrator specified inthe configuration rule. Heartbeat monitoring for the specified host is thendiscontinued until another heartbeat pulse is received.

When the monitored system is back up again, the first TEC_Heartbeat pulse eventreceived by the event server causes the previous TEC_Heartbeat_missed event tobe closed. In addition, an e-mail notification is sent to the administrator indicatingthat the monitored system is back up. Heartbeat monitoring for the system thenresumes.


UsageThe heartbeat rule set is already activated in the default rule base. If you make anychanges to this rule set, you must then recompile and reload the rule base. See“Modifying the rule base” on page 2 for more information.

Optional configurationThe heartbeat rule set is preconfigured and ready to use. However, you cancustomize this rule set by modifying statements in the heartbeat_parametersaction of the heartbeat_configure configuration rule.

Note: Although the heartbeat rule set can be used without any customization,e-mail notification does not function unless you set the administrator e-mailaddress using the admin_email parameter as described below.

The following options are configurable:v Monitoring levels. You can specify the pulse frequencies and missed-pulse

severities for the monitoring levels. The default values are described in“Overview” on page 35. To change the values for a monitoring level, modify thecorresponding rerecord statement as follows:rerecord(heartbeat, level, [ seconds, sev ]),

level is the name of one of the five monitoring levels enclosed in single quotationmarks, seconds is the interval between expected pulses, and sev is the severity touse for missed-heartbeat events. The five monitoring levels are ONE, TWO, THREE,FOUR, and FIVE. If you want to add additional monitoring levels, you must alsomodify the HEARTBEAT_LEVEL enumeration in tec.baroc.

v Latency. You can specify the length of time to use when searching the eventcache to find events to clear when a monitored host comes back up. By default,if a received TEC_Heartbeat is a clearing event, the event server searches thecache for cleared events received within the previous 30 minutes. To change thisinterval, modify the statement that sets the heartbeat_timelag parameter asfollows:rerecord(heartbeat_timelag, seconds),

seconds is the number of seconds representing how far backward you want tosearch the cache for cleared events.

Note: This parameter sets an upper limit on how far back in time the search willgo, but it does not guarantee that events within that time period will stillbe available. If your event cache is too small, events might be discardedeven if they are more recent than the specified time. If this is happens,consider increasing the size of your event cache. (See the IBM TivoliEnterprise Console User’s Guide for more information.)

v Administrator name. You can specify the administrator name to use when theheartbeat rules automatically close events. The default administrator name isheartbeat.rls. To change the administrator name, modify the statement thatsets the heartbeat_admin parameter as follows:rerecord(heartbeat_admin, admin),

admin is the administrator name to use, enclosed in single quotation marks.v Administrator e-mail address. You can specify the e-mail address of the

administrator to notify in the event of missed heartbeat pulses. This address ispassed to the Send_Email task (see the IBM Tivoli Enterprise Console User’s Guide


for more information about this task). To specify the e-mail address, modify thestatement that sets the admin_email parameter as follows:rerecord(admin_email, email_addr),

email_addr is the e-mail address you want to use, enclosed in single quotationmarks.

Rules

Startup rule

rule: heartbeat_configureThe heartbeat_configure rule is a configuration rule that runs upon receipt of theTEC_Start event, which is sent during initialization of the event server. It alsostarts the timer used to detect missed heartbeats, and it defines TEC_Heartbeat as aclearing event for TEC_Heartbeat_missed when both events are from the same host.By customizing this rule, you can configure the behavior of the heartbeat rules. See“Usage” on page 36 for more information.

Heartbeat rules

rule: pulse_receivedThe pulse_received rule runs upon receipt of the TEC_Heartbeat event with themsg attribute equal to pulse, indicating an expected heartbeat pulse from amonitored host. When this event is received, the time of the heartbeat is recordedand the event is dropped. The monitoring level in use for the originating host isalso updated based on the value of the level attribute.

The rule then checks to see if the received heartbeat event is a clearing event forany previous TEC_Heartbeat_missed event (within the time period specified byheartbeat_timelag). If it is, the cleared event is closed.

timer_rule: check_heartbeatsThe check_heartbeats timer rule checks periodically for missed heartbeats, basedupon the time intervals specified for the heartbeat monitoring levels in theheartbeat_configure rule. It first checks the current system time and thencompares this time to the time of the most recent heartbeat pulse event from eachmonitored host. If the elapsed time is greater than the time period defined for themonitoring level in effect for that host, and the monitored system is not inmaintenance mode, the rule generates a TEC_Heartbeat missed event to alert theoperator and administrator. The msg attribute of the generated event is set to thefollowing:No Heartbeat received from host: hostname within seconds seconds.

hostname is the fully-qualified host name of the monitored host, and seconds is theelapsed time since the last received heartbeat pulse from the host. The severity ofthe event is set to the appropriate value for the monitoring level in effect for thehost.

Note: The elapsed time might be greater than the time period defined for themonitoring level. A missed heartbeat is not detected until the next time thetimer rule runs, which might be several seconds later than when theheartbeat was expected to arrive.

Heartbeat rule set (heartbeat.rls) 37

After these events are generated, monitoring for the host is discontinued until aheartbeat pulse is received.

rule: heartbeat_missedThe heartbeat_missed rule runs upon receipt of a TEC_Heartbeat_missed event,which is generated when an expected heartbeat pulse does not arrive. This ruleuses the Send_Email task to send an e-mail notification to the administratorspecified in the heartbeat_configure rule.

rule: heartbeat_restoredThe heartbeat_restored change rule runs when a TEC_Heartbeat_missed event isclosed. This happens when a new TEC_Heartbeat event is received, indicating thatthe monitored host is back up. This rule uses the Send_Email task to send ane-mail notification to the administrator specified in the heartbeat_configure ruleindicating that a heartbeat has been received.


Maintenance mode rule set (maintenance_mode.rls)

OverviewThe maintenance mode rule set provides automated event processing you can useto indicate that a monitored system is being placed into maintenance mode for aspecified period of time. Maintenance mode is the state of any system that isundergoing software updates, operating system restarts, or other maintenanceactivities that might generate events you do not want processed by the rule engine.

The initiation of maintenance mode is indicated by an event of classTEC_Maintenance whose current_mode attribute is equal to ON. This event is sentby the wstartmaint.sh script or the Start_Maintenance task. When this eventarrives, the rules record a maintenance fact in the knowledge base. This factrecords the following information:v The fully qualified host name of the system being placed in maintenance mode.

If the fqhostname attribute of the TEC_Maintenance event is equal to a singleasterisk (*), this indicates that all monitored systems (except the event server)are being placed in maintenance mode.

v The time maintenance started or is scheduled to start. If no start time isspecified, the current time is assumed.

v The maximum allowed duration of the maintenance window (the period of timeduring which the system is in maintenance mode).

If the start time for the maintenance window is the current time (or a time alreadyin the past), this indicates that the specified system is being placed in maintenancemode immediately. If the start time is in the future, this indicates that the system isscheduled for maintenance at some time in the future. In either case, the msgattribute of the generated TEC_Maintenance event indicates that a maintenancewindow has begun or has been scheduled.

During the maintenance window, any events received from the system (other thanTEC_Maintenance events) are ignored. These events are either closed or dropped,depending on how the rule set is configured. (See “Usage” on page 40 for moreinformation.)

When the maximum allowed duration of the maintenance window has elapsed(indicated by the maintenance timer), the monitored system is no longerconsidered in maintenance mode, and a message is sent to the console indicatingthat the maintenance window has ended.

If a TEC_Maintenance event is received with current_mode equal to OFF, thisindicates that a system has finished maintenance, or that a scheduled maintenancewindow has been canceled. This event might be generated by the maintenancemode rules if the maximum duration of a maintenance window has elapsed, or itmight be sent by the wstopmaint.sh script on the monitored system. The specifichandling of this event depends upon the value of the start_time attribute:v If the start time matches a maintenance window that is currently in progress, the

maintenance window is immediately ended.v If the start time matches a maintenance window that has not yet started, the

future maintenance window is canceled.


v If the start time is not specified, all current and future maintenance windows forthe system are canceled.

After a maintenance window ends (or is canceled), the relevant maintenance factremains in the knowledge base for a configurable period of time in order to allowfor processing of events that arrive late. Once this time period has elapsed, anymaintenance fact related to a maintenance window that has ended is retractedfrom the knowledge base.

UsageThe maintenance mode rule set is already activated in the default rule base. If youmake any changes to this rule set, you must then recompile and reload the rulebase. See “Modifying the rule base” on page 2 for more information.

Note: If activated, the mode rule set should be listed near the beginning of therule_sets file. See “Rule set sequencing and dependencies” on page 3 formore information.

Optional configurationThe maintenance mode rule set is preconfigured and ready to use. However, youcan customize this rule set by modifying statements in themaintenance_mode_configure configuration rule. The following options areconfigurable:v Latency. You can specify how long you want each maintenance fact to remain in

the knowledge base after the corresponding maintenance window has ended, inorder to allow for processing of events that were sent during a maintenancewindow but arrive late. The default latency is one hour. To change this interval,modify the statement that sets the _over_time variable as follows:_over_time = otime

otime is the length of time (in seconds) you want to keep maintenance facts inthe knowledge base after maintenance has ended.

v Maintenance event severity. You can specify the severity of TEC_Maintenanceevents generated by the maintenance mode rules. These events are generatedwhen a maintenance window has ended. The default severity is HARMLESS. Tochange the severity of generated TEC_Maintenance events, modify the statementthat sets the _severity variable as follows:_severity = msev

msev is a valid severity for the TEC_Maintenance event class.v Administrator name. You can specify the administrator name to use when

automatically acknowledging or closing received TEC_Maintenance events. Thedefault administrator name is maintenance_mode.rls. To change theadministrator name, modify the statement that sets the _maint_admin variable asfollows:_maint_admin = admin

admin is the administrator name to use.v Fact file name. You can specify the name of the file to use to store maintenance

facts in the knowledge base. You can either specify an absolute location for thefile or specify the file name only, in which case the file is created in the $DBDIRdirectory. The default file name is maintenance_mode.pro. To change the filename, modify the statement that sets the _maintenance_file variable as follows:


_maintenance_file = filename

filename is the name of the fact file you want to use, optionally including arelative or absolute path, and enclosed in single quotation marks.

v Event handling. You can specify how you want to handle events received froma system that is currently in maintenance mode. These events can be eitherclosed or dropped. The default action is to close them; to change this behavior,modify the statement that sets the _maint_action variable as follows:_maint_action = action

action is either ’CLOSE’ or ’DROP’.

Rules

Startup rule

rule: maintenance_mode_configureThe maintenance_mode_configure rule is a configuration rule that runs upon receiptof the TEC_Start event, which is sent during initialization of the event server. Bycustomizing this rule, you can configure the behavior of the maintenance_mode.rlsrule set. See “Usage” on page 40 for more information.

In addition to setting global parameters for the maintenance mode rules, themaintenance_mode_configure rule also restarts the maintenance timers for anypending or ongoing maintenance windows that were interrupted by a restart of theevent server.

Maintenance rules

rule: maintenance_receivedThe maintenance_received rule manages scheduled maintenance windows formonitored systems. When a TEC_Maintenance event is received with thecurrent_mode attribute set to ON, this rule records a maintenance fact specifying thestart time and duration for the maintenance window. (If the specified duration is 0,this rule generates an error message and closes the received TEC_Maintenanceevent without taking any additional action.) If the start time for the maintenancewindow is in the future, this rule starts a timer that expires when it is time for themaintenance window to start.

When a TEC_Maintenance event is received with current_mode set to OFF, this rulesearches the event cache for a matching TEC_Maintenance event specifying thesame system and the same start time. Any matching event is closed. Anymaintenance window currently in progress for the system is then canceled. If nostart time is specified by the received TEC_Maintenance event, all current andfuture maintenance windows for the specified system are canceled.

rule: check_maintenance_modeThe check_maintenance_mode rule runs upon receipt of any event. It checks to see ifthe system that generated the event is currently in maintenance mode (that is, thestart time of a maintenance window has passed, but the duration of themaintenance window has not yet elapsed). If the system is in maintenance mode,the received event is closed or dropped (depending upon the configuration)without any further action.

Maintenance mode rule set (maintenance_mode.rls) 41

Note: This rule does not drop or close events from the event server. The eventserver cannot be placed in maintenance mode.

Timer rules

timer_rule: check_maintenance_timeoutThe check_maintenance_timeout timer rule checks periodically to determinewhether any system has been in maintenance mode longer than the maximumallowed period of time for the maintenance window. If the maximum duration ofthe maintenance window has elapsed and the system is still in maintenance mode,this rule ends the maintenance window and generates a message indicating thatthis happened. In addition, it generates a TEC_Maintenance event withcurrent_mode set to OFF.

timer_rule: start_maintenance_timerThe start_maintenance_timer timer rule checks to see if the start time for anyscheduled maintenance window has arrived. This rule is triggered by theexpiration of a maintenance timer set by the maintenance_received rule; this timeris set upon receipt of a TEC_Maintenance event specifying a maintenance windowin the future. If any system is scheduled to start a maintenance window, thestart_maintenance_timer rule generates a message that the specified system hasentered maintenance mode and starts a timer that expires when the maximumduration of the maintenance window has elapsed.

timer_rule: check_overtime_timerThe check_overtime_timer timer rule checks to see if it is time to retract anymaintenance facts from the knowledge base. Maintenance facts are kept in theknowledge base for a configurable period of time after the maintenance windowends, in order to allow for handling of related events that arrive late. This intervalis determined by the _over_time parameter in the maintenance_mode_configureconfiguration rule. When the specified amount of time has elapsed since the end ofthe maintenance window, the check_overtime_timer rule retracts the relevantmaintenance fact from the knowledge base.


NetView rule set (netview.rls)

OverviewThe NetView rule set contains rules that handle events from the NetViewcomponent. These rules correlate related NetView events and manage thesynchronization of the event server with the NetView component.

The NetView rules can be divided into four major categories, each of whichperforms a different function:v Severity lowering rulesv Event clearing rulesv Synchronization rulesv Correlation rules

Severity adjustment rulesThe severity adjustment rules modify the severity of received events in order tomore accurately reflect whether they represent network problems. By default,events received from the NetView component have a severity of WARNING. However,some of these events are actually clearing events indicating the resolution of aproblem rather than a new problem. This includes various status events indicatinga status of UP as well as rearmed threshold events. In addition, some events areinformational and do not represent problems, such as ″added″ events indicatingthat monitoring has begun for a newly added network resource.

The severity adjustment rules in the NetView rule set detect these events andlower their severity to HARMLESS. In addition, these rules raise the severity of routerstatus events indicating a status of DOWN.

Event clearing rulesThe event clearing rules handle events that update previously received statusevents. In some cases, these are clearing events that indicate the resolution of aprevious problem. For example, a TEC_ITS_NODE_STATUS event with thenodestatus attribute equal to UP clears any previously receivedTEC_ITS_NODE_STATUS or TEC_ITS_NODE_SERVICE_IMPACT events from thesame node. In other cases, the newly received event might indicate thecontinuation of a previous problem, or it might indicate that a node or interfacehas been deleted or is no longer being monitored.

When one of these status events is received, the event clearing rules search for anypreviously received events cleared by the new event. Any cleared events aredowngraded to HARMLESS and closed, ensuring that only the most current statusevent remains open. If the new event indicates the continuation of a previousproblem, the severity of the new event is increased.

Synchronization rulesThe synchronization rules keep Tivoli Enterprise Console events synchronized withthe NetView component. These rules process changes in the status of certainNetView events and send SNMP synchronization traps to the NetView componentin order to keep the NetView console updated.


These rules are triggered when the status of a NetView node, router, or interfacestatus event changes to ACK or CLOSED, or changes from ACK to any other status.When this happens, the change is buffered for synchronization. Periodically, therules send synchronization traps to the NetView component in order tosynchronize the status of these events. You can customize the frequency of thesesynchronization traps; see “Usage” on page 45 for more information.

Correlation rulesThe correlation rules process network events in order to identify causalrelationships. When an event is found to be an effect of another event, the twoevents are linked using the link_effect_to_cause predicate. Depending upon thespecific classes of the cause and effect events, additional processing might also takeplace, such as downgrading and closing effect events or upgrading the severity ofcause events. In order for NetView events to be correlated, both events must befrom the same NetView server.

The events correlated by these rules fall into several broad categories:v Network service impact events. These events indicate network conditions that

affect services monitored by IBM Tivoli Monitoring.v Level 2 network events. These events indicate low-level network conditions

detected by the IBM Tivoli Switch Analyzer product.v Level 3 network events. These events indicate network conditions detected by

the NetView component.v Missed heartbeat events. These events indicate missed heartbeat pulses and are

generated by the heartbeat rule set (heartbeat.rls).

The following table summarizes the effect events and possible cause eventscorrelated by the NetView rule set.

Table 6.

Effect event Possible cause events

TEC_ITS_NODE_SERVICE_IMPACT v TEC_ITS_NODE_STATUS (nodestatus=DOWN, MARGINAL,or UNREACHABLE)

v TEC_ITS_ROUTER_STATUS (routerstatus=DOWN,MARGINAL, or UNREACHABLE)

TEC_ITS_SUBNET_SERVICE_IMPACT v TEC_ITS_SUBNET_CONNECTIVITY(reachability=UNREACHABLE)

TEC_ITS_SA_STATUS (sastatus=nodeDown, nodeMarginal,or ifDown)

v TEC_ITS_NODE_STATUS (nodestatus=DOWN, MARGINAL,or UNREACHABLE)


TEC_ITS_SA_STATUS (sastatus=nodeUp or ifUp) v TEC_ITS_NODE_STATUS (nodestatus=UP)v TEC_ITS_ROUTER_STATUS (routerstatus=UP)

TEC_ITS_L2_NODE_STATUS v TEC_ITS_SA_STATUS

TEC_ITS_SUBNET_CONNECTIVITY(reachability=UNREACHABLE)


TEC_ITS_INTERFACE_STATUS (ifstatus=DOWN,ADMIN_DOWN, or UNREACHABLE)

v TEC_ITS_ROUTER_STATUS (routerstatus=DOWN)v TEC_ITS_NODE_STATUS (nodestatus=DOWN, MARGINAL,

or UNREACHABLE)v TEC_ITS_L2_NODE_STATUS

TEC_ITS_ROUTER_STATUS (routerstatus=MARGINAL orUNREACHABLE)

v TEC_ITS_INTERFACE_STATUS (ifstatus=DOWN,ADMIN_DOWN, or UNREACHABLE)


Table 6. (continued)

Effect event Possible cause events

TEC_ITS_SUBNET_CONNECTIVITY(reachability=REACHABLE_AGAIN)

v TEC_ITS_ROUTER_STATUS (routerstatus=UP)

TEC_ITS_INTERFACE_STATUS (ifstatus=UP) v TEC_ITS_ROUTER_STATUS (routerstatus=UP)v TEC_ITS_NODE_STATUS (nodestatus=UP)

TEC_ITS_UNREACHABLE v TEC_ITS_SUBNET_CONNECTIVITY(reachability=UNREACHABLE)

TEC_Heartbeat_missed v TEC_ITS_SUBNET_CONNECTIVITY(reachability=UNREACHABLE)

v TEC_ITS_NODE_STATUS (nodestatus not UP)v TEC_ITS_ROUTER_STATUS (routerstatus not UP)

UsageThe NetView rule set is already activated in the default rule base. If you make anychanges to this rule set, you must then recompile and reload the rule base andrestart the event server. See “Modifying the rule base” on page 2 for moreinformation.

Optional configurationThe NetView rule set is preconfigured and ready to use. However, you cancustomize this rule set by modifying statements in the netview_rules_parms actionof the netview_configure configuration rule. The following options areconfigurable:v Administrator name. You can specify the administrator name to use when

automatically acknowledging or closing events. The default administrator nameis netview.rls. To change the administrator name, modify the statement in thenetview_rules_parms action that sets the netview_admin parameter:rerecord(netview_admin, admin),

admin is the administrator name to use, enclosed in single quotation marks.v Latency. You can specify the time range to be used when searching the event

cache for events. This time range, or latency, affects both backward and forwardevent searches. By default, searches are limited to ten minutes (600 seconds)backward or forward in the event cache. To change the latency, modify thestatement in the netview_rules_parms action that sets the nv_latency parameter:rerecord(nv_latency, seconds),



v Synchronization buffer timeout. You can specify the timeout value forsynchronizing batches of buffered NetView events. Events that need to besynchronized with the NetView component are buffered for synchronization inbatches. Periodically, the NetView rules send an SNMP trap to each affected

NetView rule set (netview.rls) 45

NetView host, triggering the synchronization. The default interval betweensynchronization batches is 30 seconds. To change this interval, modify thestatement in the netview_rules_parms action that sets the nvsync_timeoutparameter:rerecord(nvsync_timeout, seconds),

seconds is the length of time (in seconds) you want to buffer events before eachsynchronization batch.

v SNMP trap port. You can specify the TCP/IP port to use for sending SNMPtraps to the NetView component. The default port is 162. To change the SNMPport, modify the statement in the netview_rules_parms action that sets thenvsync_port parameter:rerecord(nvsync_port, port),

port is the port number to use.v Hosts per synchronization batch. You can specify the maximum number of

hosts to include in a single synchronization batch. Each synchronization batch ishandled by a single task with command-line arguments specfiying the hosts thatare being sent SNMP traps. Because some operating systems have limitations onthe length of command-line strings, you can limit the number of hosts that canbe included in a single batch. When an event is buffered for synchronization, therules check whether the maximum number of distinct hosts has been reached. Ifit has, the buffered events are immediately synchronized, even if thesynchronization timeout period has not yet elapsed since the lastsynchronization. The default maximum is 10 distinct hosts. To change thismaximum, modify the statement in the netview_rules_parms action that sets thenvsync_maxhosts parameter:rerecord(nvsync_maxhosts, hosts),

hosts is the maximum number of hosts.v Debug logging. You can specify whether you want debugging information

written to a log file. This can be useful if you are modifying the rule set. Thisfunction should always be disabled before the rule set is deployed in aproduction environment because it can affect performance. To enable debuggingmessages, modify the statement in the debug_setup action that sets thenetview_debug parameter:rerecord(netview_debug, ’yes’),

v Debugging log file name. You can specify the name of the log file used fordebugging messages. This file is only used if netview_debug is set to yes. You caneither specify an absolute location for the file or specify the file name only, inwhich case the file is created in the $DBDIR directory. The default value isnetview.log. To specify a different file, modify the statement in the debug_setupaction that sets the netview_logfile parameter:rerecord(netview_logfile, filename),

filename is the name of the log file you want to use, enclosed in single quotationmarks.


Rules


rule: netview_configureThe netview_configure rule is a configuration rule that runs upon receipt of theTEC_Start event, which is sent during intialization of the event server. This rulesets global parameters for the NetView rules, asserts auxiliary predicates forinternal use, and initializes the log files for the rule set.

By customizing this rule, you can configure the behavior of the netview.rls rule set.See “Usage” on page 45 for more information.

rule: shutdownThe shutdown rule runs upon receipt of the TEC_Stop event, which is sent whenthe event server shuts down. This rule finalizes any open log files for the rule set.

Severity adjustment rules

rule: router_raiseThe router_raise rule runs upon receipt of the TEC_ITS_ROUTER_STATUS event.If the routerstatus attribute of the received event is equal to DOWN, the severity ofthe event is set to CRITICAL.

rule: interface_lowerThe interface_lower rule runs upon receipt of the TEC_ITS_INTERFACE_STATUSevent. If the ifstatus attribute of the received event is equal to UP, the severity ofthe event is set to HARMLESS.

rule: isdn_lowerThe isdn_lower rule runs upon receipt of the TEC_ITS_ISDN_STATUS event. If theisdnstatus attribute of the received event is equal to ACTIVE, the severity of theevent is set to HARMLESS.

rule: snmp_lowerThe snmp_lower rule runs upon receipt of theTEC_ITS_SNMPCOLLECT_THRESHOLD event. If the snmpstatus attribute of thereceived event is equal to REARMED, the severity of the event is set to HARMLESS.

rule: node_lowerThe node_lower rule runs upon receipt of the TEC_ITS_NODE_STATUS event. Ifthe nodestatus attribute of the received event is equal to UP, the severity of theevent is set to HARMLESS.

rule: router_lowerThe router_lower rule runs upon receipt of the TEC_ITS_ROUTER_STATUS event.If the routerstatus attribute of the received event is equal to UP, the severity of theevent is set to HARMLESS.

rule: subnet_lowerThe subnet_lower rule runs upon receipt of theTEC_ITS_SUBNET_CONNECTIVITY event. If the reachability attribute of thereceived event is equal to REACHABLE_AGAIN, the severity of the event is set toHARMLESS.


rule: interface_added_lowerThe interface_added_lower rule runs upon receipt of theTEC_ITS_INTERFACE_ADDED event. If the action attribute of the received eventis equal to ADDED, the severity of the event is set to HARMLESS.

rule: interface_managed_lowerThe interface_managed_lower rule runs upon receipt of theTEC_ITS_INTERFACE_MANAGE event. If the manage attribute of the receivedevent is equal to MANAGE, the severity of the event is set to HARMLESS.

rule: node_added_lowerThe node_added_lower rule runs upon receipt of the TEC_ITS_NODE_ADDEDevent. If the action attribute of the received event is equal to ADDED, the severity ofthe event is set to HARMLESS.

rule: node_managed_lowerThe node_managed_lower rule runs upon receipt of the TEC_ITS_NODE_MANAGEevent. If the manage attribute of the received event is equal to MANAGE, the severityof the event is set to HARMLESS.

rule: sa_status_lowerThe sa_status_lower rule runs upon receipt of the TEC_ITS_SA_STATUS event. Ifthe sastatus attribute of the received event is equal to ifUp, nodeUp, ornodeResolved, the severity of the event is set to HARMLESS.

rule: l2_status_lowerThe l2_status_lower rule runs upon receipt of the TEC_ITS_L2_NODE_STATUSevent. If the l2status attribute of the received event is equal to UP, the severity ofthe event is set to HARMLESS.

Event clearing rules

rule: interface_clearingThe interface_clearing rule runs upon receipt of theTEC_ITS_INTERFACE_STATUS event. When this event is received, any previousstatus events for the same interface are downgraded to HARMLESS and closed.

rule: isdn_clearingThe isdn_clearing rule runs upon receipt of the TEC_ITS_ISDN_STATUS event.When this event is received, any previous status events for the same ISDN interfaceare downgraded to HARMLESS and closed.

rule: snmp_clearingThe snmp_clearing rule runs upon receipt of theTEC_ITS_SNMPCOLLECT_THRESHOLD event. When this event is received, anyprevious threshold events for the same SNMP collection daemon are downgraded toHARMLESS and closed.

rule: node_clearingThe node_clearing rule runs upon receipt of the TEC_ITS_NODE_STATUS event.When this event is received, any previous status events for the same node aredowngraded to HARMLESS and closed. If the nodestatus attribute of the receivedevent is equal to UP, any previous TEC_ITS_NODE_SERVICE_IMPACT events forthe same node are then downgraded to HARMLESS and closed.

rule: router_clearingThe router_clearing rule runs upon receipt of the TEC_ITS_ROUTER_STATUSevent. When this event is received, any previous status events for the same router


are downgraded to HARMLESS and closed. If the routerstatus attribute of thereceived event is equal to UP, any previous TEC_ITS_NODE_SERVICE_IMPACTevents for the same host are then downgraded to HARMLESS and closed.

rule: subnet_clearingThe subnet_clearing rule runs upon receipt of theTEC_ITS_SUBNET_CONNECTIVITY event. When this event is received, anyprevious connectivity events for the same subnet are downgraded to HARMLESSand closed. If the reachability attribute of the received event is equal toREACHABLE_AGAIN, any previous TEC_ITS_SUBNET_SERVICE_IMPACT events forthe same subnet are downgraded to HARMLESS and closed.

rule: l2_status_clearingThe l2_status_clearing rule runs upon receipt of theTEC_ITS_L2_NODE_STATUS event. When this event is received, any previous L2status events for the same node are downgraded to HARMLESS and closed.

rule: node_service_impact_clearingThe node_service_impact_clearing rule runs upon receipt of theTEC_ITS_NODE_SERVICE_IMPACT event. When this event is received, anyprevious service impact events for the same node and service are downgraded toHARMLESS and closed.

rule: subnet_service_impact_clearingThe subnet_service_impact_clearing rule runs upon receipt of theTEC_ITS_SUBNET_SERVICE_IMPACT event. When this event is received, anyprevious service impact events for the same subnet and service are downgraded toHARMLESS and closed.

rule: sa_status_clearingThe sa_status_clearing rule runs upon receipt of the TEC_ITS_SA_STATUS event.When this event is received, the event cache is searched for any previouslyreceived TE_ITS_SA_STATUS events for the same host and with the samesaticketnumber attribute value. If any matching events are found, they aredowngraded to HARMLESS and closed.

In addition, if the sastatus attributes of the previously received event is equal toifDown, nodeDown, or nodeMarginal, and the sastatus attribute of the new event isalso equal to ifDown, nodeDown, or nodeMarginal, the severity of the new event isincreased to CRITICAL.

rule: interface_deletedThe interface_deleted rule runs upon receipt of a TEC_ITS_INTERFACE_ADDEDevent with action equal to DELETED. When this event is received, this rule closesany previous status events from the same interface and then drops the receivedevent.

rule: interface_unmanagedThe interface_unmanaged rule runs upon receipt of aTEC_ITS_INTERFACE_MANAGE event with manage equal to UNMANAGE. When thisevent is received, this rule closes any previous status events from the sameinterface and then drops the received event.

rule: node_deletedThe node_deleted rule runs upon receipt of a TEC_ITS_NODE_ADDED event withaction equal to DELETED. When this event is received, this rule closes any previousnode status, router status, or interface status events from the same host and thendrops the received event.


rule: node_unmanagedThe node_unmanaged rule runs upon receipt of a TEC_ITS_NODE_MANAGE eventwith manage equal to UNMANAGE. When this event is received, this rule closes anyprevious node status, router status, or interface status events from the same hostand then drops the received event.

Synchronization rules

change_rule: interface_synchronizationThe interface_synchronization change rule runs when the status of aTEC_ITS_INTERFACE_STATUS event has changed. When this occurs, the event isbuffered for synchronization with the NetView component. Three types of changesare buffered:

acknowledgedstatus is now equal to ACK.

unacknowledgedstatus was previously equal to ACK, but has now been changed tosomething else (other than CLOSED).

closed status has changed to CLOSED.

timer_rule: flush_if_ackThe flush_if_ack timer rule periodically flushes acknowledged interface eventsand synchronizes them with the NetView component.

timer_rule: flush_if_unackThe flush_if_unack timer rule periodically flushes unacknowledged interfaceevents and synchronizes them with the NetView component.

timer_rule: flush_if_closeThe flush_if_close timer rule periodically flushes closed interface events andsynchronizes them with the NetView component.

change_rule: node_synchronizationThe node_synchronization change rule runs when the status of aTEC_ITS_NODE_STATUS or TEC_ITS_ROUTER_STATUS event has changed.When this occurs, the event is buffered for synchronization with the NetViewcomponent. Three types of changes are buffered:

acknowledgedstatus is now equal to ACK.

unacknowledgedstatus was previously equal to ACK, but has now been changed tosomething else (other than CLOSED).

closed status has changed to CLOSED.

timer_rule: flush_node_ackThe flush_node_ack timer rule periodically flushes acknowledged node or routerevents and synchronizes them with the NetView component.

timer_rule: flush_node_unackThe flush_node_unack timer rule periodically flushes unacknowledged node orrouter events and synchronizes them with the NetView component.

timer_rule: flush_node_closeThe flush_node_close timer rule periodically flushes closed node or router eventsand synchronizes them with the NetView component.


Correlation rules

rule: service_impact_link_nodeThe service_impact_link_node rule runs upon receipt of theTEC_ITS_NODE_SERVICE_IMPACT event. When this event is received, the rulesearches the event cache for a non-closed TEC_ITS_NODE_STATUS event for thesame node with nodestatus equal to DOWN, MARGINAL, or UNREACHABLE. Ifsuch a cause event is found, the two events are correlated using thelink_effect_to_cause predicate, and the effect event(TEC_ITS_NODE_SERVICE_IMPACT) is acknowledged. The severity of the causeevent (TEC_ITS_NODE_STATUS) is then upgraded. The new severity is FATAL ifIBM Tivoli Monitoring reported a service impact; otherwise it is CRITICAL. (If theseverity is already FATAL, it does not change.)

If the TEC_ITS_NODE_STATUS event is linked to a non-closed NetView causeevent, the new severity of the router event is propagated to its cause event.

rule: node_link_service_impactThe node_link_service_impact rule runs upon receipt of aTEC_ITS_NODE_STATUS event with nodestatus equal to DOWN, MARGINAL, orUNREACHABLE. When this event is received, the rule searches the event cachefor any non-closed TEC_ITS_NODE_SERVICE_IMPACT events for the same node.If any such effect events are found, they are correlated with the cause event usingthe link_effect_to_cause predicate and then acknowledged. The severity of thecause event (TEC_ITS_NODE_STATUS) is upgraded. The new severity is FATAL ifIBM Tivoli Monitoring reported a service impact; otherwise, it is CRITICAL. (If theseverity is already FATAL, it does not change.)

If the TEC_ITS_NODE_STATUS event is linked to a non-closed NetView causeevent, the new severity of the router event is propagated to its cause event.

rule: service_impact_link_routerThe service_impact_link_router rule runs upon receipt of theTEC_ITS_NODE_SERVICE_IMPACT event. When this event is received, the rulesearches the event cache for a non-closed TEC_ITS_ROUTER_STATUS event for thesame host with routerstatus equal to DOWN, MARGINAL, or UNREACHABLE.If such a cause event is found, the two events are correlated using thelink_effect_to_cause predicate, and the effect event(TEC_ITS_NODE_SERVICE_IMPACT) is acknowledged. The severity of the causeevent (TEC_ITS_ROUTER_STATUS) is then upgraded. The new severity is FATALif IBM Tivoli Monitoring reported a service impact; otherwise it is CRITICAL. (Ifthe severity is already FATAL, it does not change.)

If the routerstatus of the TEC_ITS_ROUTER_STATUS event is equal to MARGINALor UNREACHABLE and it is itself linked to a non-closed NetView cause event, the newseverity of the router event is propagated to its cause event.

rule: router_link_service_impactThe router_link_service_impact rule runs upon receipt of aTEC_ITS_ROUTER_STATUS event with nodestatus equal to DOWN, MARGINAL,or UNREACHABLE. When this event is received, the rule searches the event cachefor any non-closed TEC_ITS_NODE_SERVICE_IMPACT events for the same host. Ifany such effect events are found, they are correlated with the cause event using thelink_effect_to_cause predicate and acknowledged. The severity of the causeevent (TEC_ITS_ROUTER_STATUS) is then upgraded. The new severity is FATALif IBM Tivoli Monitoring reported a service impact; otherwise it is CRITICAL. (Ifthe severity is already FATAL, it does not change.)


If the routerstatus of the TEC_ITS_ROUTER_STATUS event is equal to MARGINALor UNREACHABLE, and the event is linked to a non-closed NetView cause event, thenew severity of the router event is propagated to its cause event.

rule: service_impact_link_subnetThe service_impact_link_subnet rule runs upon receipt of theTEC_ITS_SUBNET_SERVICE_IMPACT event. When this event is received, the rulesearches the event cache for a non-closed TEC_ITS_SUBNET_CONNECTIVITYevent for the same subnet with reachability equal to UNREACHABLE. If such acause event is found, the two events are correlated using the link_effect_to_causepredicate, and the effect event (TEC_ITS_NODE_SERVICE_IMPACT) isacknowledged. The severity of the cause event(TEC_ITS_SUBNET_CONNECTIVITY) is then upgraded. The new severity isFATAL if IBM Tivoli Monitoring reported a service impact; otherwise it isCRITICAL. (If the severity is already FATAL, it does not change.)

If the TEC_ITS_SUBNET_CONNECTIVITY event is itself linked to a non-closedNetView cause event, the new severity of the subnet event is propagated to itscause event. If that cause event is not closed and is linked to a root cause event,the new severity is propagated to the root cause event.

rule: subnet_link_service_impactThe subnet_link_service_impact rule runs upon receipt of aTEC_ITS_SUBNET_CONNECTIVITY event with reachability equal toUNREACHABLE. When this event is received, the rule searches the event cachefor any non-closed TEC_ITS_SUBNET_SERVICE_IMPACT events for the same host.If any such effect events are found, they are correlated with the cause event usingthe link_effect_to_cause predicate and acknowledged. The severity of the causeevent (TEC_ITS_SUBNET_CONNECTIVITY) is then upgraded. The new severity isFATAL if IBM Tivoli Monitoring reported a service impact; otherwise it isCRITICAL. (If the severity is already FATAL, it does not change.)

If the TEC_ITS_SUBNET_CONNECTIVITY event is itself linked to a non-closedNetView cause event, the new severity of the subnet event is propagated to itscause event. If that cause event is not closed and is linked to a root cause event,the new severity is propagated to the root cause event.

rule: node_correlate_saThe node_correlate_sa rule runs upon receipt of a TEC_ITS_NODE_STATUS eventwith nodestatus equal to DOWN, MARGINAL, or UNREACHABLE. When this event isreceived, the rule searches the event cache for a TEC_ITS_SA_STATUS event forthe same host with the sastatus attribute equal to nodeDown, nodeMarginal, orifDown. If such a cause event is found, the following actions are taken:v The received TEC_ITS_NODE_STATUS event is linked as an effect of the

TEC_ITS_SA_STATUS cause event using the link_effect_to_cause predicate.v If the sastatus attribute of the TEC_ITS_SA_STATUS cause event is equal to

nodeDown or nodeMarginal, the severity of the effect event(TEC_ITS_NODE_STATUS) is set to HARMLESS, and the status of the effect eventis set to RESPONSE. A timer is then set for delayed closing of the effect event afterall correlation is finished. (The duration of the timer is determined by the valueof the nv_latency global parameter.) This processing does not take place ifsastatus is equal to ifDown.

v The severity of the received TEC_ITS_NODE_STATUS effect event is propagatedto the TEC_ITS_SA_STATUS cause event.


rule: sa_correlate_nodeThe sa_correlate_node rule runs upon receipt of a TEC_ITS_SA_STATUS eventwith satatus equal to nodeDown, nodeMarginal, or ifDown. When this event isreceived, the rule searches the event cache for a TEC_ITS_NODE_STATUS eventfor the same host with nodestatus equal to DOWN, MARGINAL, or UNREACHABLE. If suchan effect event is found, the following actions are taken:v The TEC_ITS_NODE_STATUS effect event is linked to the TEC_ITS_SA_STATUS

cause event using the link_effect_to_cause predicate.v If the sastatus attribute of the TEC_ITS_SA_STATUS cause event is equal to

nodeDown or nodeMarginal, the severity of the effect event(TEC_ITS_NODE_STATUS) is set to HARMLESS, and the status of the effect eventis set to RESPONSE. A timer is then set for delayed closing of the effect event afterall correlation is finished. (The duration of the timer is determined by the valueof the nv_latency global parameter.) This processing does not take place ifsastatus is equal to ifDown.

v The severity of the received TEC_ITS_NODE_STATUS effect event is propagatedto the TEC_ITS_SA_STATUS cause event.

rule: node_up_correlate_saThe node_up_correlate_sa rule runs upon receipt of a TEC_ITS_NODE_STATUSevent with nodestatus equal to UP. When this event is received, the rule searchesfor any TEC_ITS_SA_STATUS events for the same host with the sastatus attributeequal to nodeUp or ifUp. If any such cause events are found, they are correlatedwith the effect event using the link_effect_to_cause predicate. The effect event isthen downgraded to HARMLESS, its status is set to RESPONSE, and a timer is set fordelayed closing of the event after all correlation is finished. (The duration of thetimer is determined by the value of the nv_latency global parameter.

rule: sa_correlate_node_upThe sa_correlate_node_up rule runs upon receipt of a TEC_ITS_SA_STATUS eventwith satatus equal to nodeUp or ifUp. When this event is received, the rulesearches the event cache for a non-closed TEC_ITS_NODE_STATUS event for thesame host with nodestatus equal to UP. If such an effect event is found, it iscorrelated with the cause event using the link_effect_to_cause predicate. Theeffect event is then downgraded to HARMLESS, its status is set to RESPONSE, and atimer is set for delayed closing of the event after all correlation is finished. (Theduration of the timer is determined by the value of the nv_latency global parameter.

rule: l2_correlate_saThe l2_correlate_sa rule runs upon receipt of the TEC_ITS_L2_NODE_STATUSevent. When this event is received, the event cache is searched for aTEC_ITS_SA_STATUS event for the same host. If such a cause event is found, thetwo events are correlated. In addition, one of the following actions is taken:v If the cause event has the sastatus attribute equal to ifDown, nodeDown, or

nodeMarginal, it is upgraded to CRITICAL.v If the cause event has the sastatus attribute equal to ifUp, nodeUp, or

nodeResolved, it is downgraded to HARMLESS.v If the cause event has the sastatus attribute equal to ifUnmanaged, ifDeleted,

nodeUnmanaged, or nodeDeleted, it is upgraded to WARNING.

The effect event (TEC_ITS_L2_NODE_STATUS) is then downgraded to HARMLESSand closed.


rule: sa_correlate_l2_1The sa_correlate_l2_1 rule runs upon receipt of a TEC_ITS_SA_STATUS eventwith the sastatus attribute equal to ifDown, nodeDown, or nodeMarginal. When thisevent is received, the event cache is searched for a TEC_ITS_L2_NODE_STATUSevent for the same host. If such an effect event is found, it is correlated with thecause event using the link_effect_to_cause predicate, downgraded to HARMLESS,and closed. The cause event (TEC_ITS_SA_STATUS) is then upgraded to CRITICAL.

rule: sa_correlate_l2_2The sa_correlate_l2_2 rule runs upon receipt of a TEC_ITS_SA_STATUS eventwith the sastatus attribute equal to ifUp, nodeUp, or nodeResolved. When thisevent is received, the event cache is searched for a TEC_ITS_L2_NODE_STATUSevent for the same host. If such an effect event is found, it is correlated with thecause event using the link_effect_to_cause predicate, downgraded to HARMLESS,and closed. The cause event (TEC_ITS_SA_STATUS) is then downgraded toHARMLESS.

rule: sa_correlate_l2_3The sa_correlate_l2_3 rule runs upon receipt of a TEC_ITS_SA_STATUS eventwith the sastatus attribute equal to ifUnmanaged, ifDeleted, nodeUnmanaged, ornodeDeleted. When this event is received, the event cache is searched for aTEC_ITS_L2_NODE_STATUS event for the same host. If such an effect event isfound, it is correlated with the cause event using the link_effect_to_causepredicate, downgraded to HARMLESS, and closed. The cause event(TEC_ITS_SA_STATUS) is then set to WARNING.

rule: router_correlate_saThe router_correlate_sa rule runs upon receipt of a TEC_ITS_ROUTER_STATUSevent with routerstatus equal to DOWN, MARGINAL, or UNREACHABLE. When this eventis received, the event cache is searched for any TEC_ITS_SA_STATUS events forthe same host with the sastatus attribute equal to nodeDown, nodeMarginal, orifDown. If any such effect events are found, they correlated, downgraded toHARMLESS, and closed.

rule: sa_correlate_routerThe sa_correlate_router rule runs upon receipt of a TEC_ITS_SA_STATUS eventwith the sastatus attribute equal to nodeDown, nodeMarginal, or ifDown. When thisevent is received, the event cache is searched for a TEC_ITS_ROUTER_STATUSevent for the same host with routerstatus equal to DOWN, MARGINAL, or UNREACHABLE.If such a cause event is found, the two events are correlated; the effect event(TEC_ITS_SA_STATUS) is downgraded to HARMLESS and closed.

rule: router_up_correlate_saThe router_up_correlate_sa rule runs upon receipt of aTEC_ITS_ROUTER_STATUS event with routerstatus equal to UP. When this eventis received, the event cache is searched for any TEC_ITS_SA_STATUS events forthe same host with the sastatus attribute equal to nodeUp or ifUp. If any sucheffect events are found, they are correlated with the cause event, downgraded toHARMLESS, and closed.

rule: sa_correlate_router_upThe sa_correlate_router rule runs upon receipt of a TEC_ITS_SA_STATUS eventwith the sastatus attribute equal to nodeUp or ifUp. When this event is received,the event cache is searched for a TEC_ITS_ROUTER_STATUS event for the samehost with routerstatus equal to UP. If such a cause event is found, the two eventsare correlated; the effect event (TEC_ITS_SA_STATUS) is downgraded to HARMLESSand closed.


rule: router_correlate_subnetThe router_correlate_subnet rule runs upon receipt of aTEC_ITS_ROUTER_STATUS event with routerstatus equal to DOWN, MARGINAL, orUNREACHABLE. When this event is received, the event cache is searched for anyTEC_ITS_SUBNET_CONNECTIVITY events with reachability equal toUNREACHABLE. If any such effect events are found, they are correlated using thelink_effect_to_cause predicate. The effect events(TEC_ITS_SUBNET_CONNECTIVITY) are then downgraded to HARMLESS, its statusis changed to RESPONSE, and a timer is set for delayed closing of the effect eventafter all correlation is finished. (The duration of the delay is determined by thevalue of the nv_latency global parameter.)

If the severity of the effect event was higher than that of theTEC_ITS_ROUTER_STATUS cause event, the higher severity is propagated to the causeevent. If routerstatus is equal to MARGINAL or UNREACHABLE and the router event islinked to a further NetView cause event, the severity is propagated to that causeevent.

rule: subnet_correlate_routerThe subnet_correlate_router rule runs upon receipt of aTEC_ITS_SUBNET_CONNECTIVITY event with reachability equal toUNREACHABLE. When this event is received, the event cache is searched for aTEC_ITS_ROUTER_STATUS with routerstatus equal to DOWN, MARGINAL, orUNREACHABLE. If such a cause event is found, the two events are correlated using thelink_effect_to_cause predicate. The effect event(TEC_ITS_SUBNET_CONNECTIVITY) is then downgraded to HARMLESS, its statusis changed to RESPONSE, and a timer is set for delayed closing of the effect eventafter all correlation is finished. (The duration of the delay is determined by thevalue of the nv_latency global parameter.)

If the severity of the effect event was higher than that of theTEC_ITS_ROUTER_STATUS cause event, the higher severity is propagated to thecause event. If routerstatus is equal to MARGINAL or UNREACHABLE and the routerevent is linked to a further NetView cause event, the severity is propagated to thatcause event.

rule: interface_correlate_routerThe interface_correlate_router rule runs upon receipt of aTEC_ITS_INTERFACE_STATUS event with ifstatus equal to DOWN, ADMIN_DOWN, orUNREACHABLE. When this event is received, the event cache is searched for aTEC_ITS_ROUTER_STATUS event from the same host. If such an event is found,one of the following actions is taken:v If the TEC_ITS_ROUTER_STATUS event has routerstatus equal to MARGINAL or

UNREACHABLE, it is correlated as an effect event using the link_effect_to_causepredicate, it is downgraded to HARMLESS, and its status is set to RESPONSE. A timeris then set for delayed closing of the effect event after all correlation is finished.(The duration of the delay is determined by the value of the nv_latency globalparameter.) If the severity of the effect event was higher than that of theTEC_ITS_INTERFACE_STATUS cause event, the higher severity is propagated tothe cause event.

v If the TEC_ITS_ROUTER_STATUS event has routerstatus equal to DOWN, it iscorrelated as a cause event using the link_effect_to_cause predicate. The effectevent (TEC_ITS_INTERFACE_STATUS) is then downgraded to HARMLESS andclosed.


rule: router_correlate_interfaceThe router_correlate_interface rule runs upon receipt of aTEC_ITS_ROUTER_STATUS event with routerstatus equal to DOWN, MARGINAL, orUNREACHABLE. When this event is received, one of the following actions is taken:v If the routerstatus is equal to DOWN, the event cache is searched for any

TEC_ITS_INTERFACE_STATUS events with ifstatus equal to DOWN, ADMIN_DOWN,or UNREACHABLE. If any are found, they are correlated as effect events using thelink_effect_to_cause predicate. These effect events are then downgraded toHARMLESS and closed.

v If the routerstatus is not equal to DOWN, the event cache is searched for aTEC_ITS_INTERFACE_STATUS event with ifstatus equal to DOWN, ADMIN_DOWN,or UNREACHABLE. If such an event is found, it is correlated as the cause eventusing the link_effect_to_cause predicate. The effect event(TEC_ITS_ROUTER_STATUS) is then downgraded to HARMLESS, its status ischanged to RESPONSE, and a timer is set for delayed closing of the effect eventafter all correlation is finished. (The duration of the delay is determined by thevalue of the nv_latency global parameter.) If the severity of the effect event washigher than that of the TEC_ITS_INTERFACE_STATUS cause event, the higherseverity is propagated to the cause event.

rule: interface_correlate_nodeThe interface_correlate_node rule runs upon receipt of aTEC_ITS_INTERFACE_STATUS event with ifstatus equal to DOWN, ADMIN_DOWN, orUNREACHABLE. When this event is received, the event cache is searched for aTEC_ITS_NODE_STATUS event for the same host with nodestatus equal to DOWN,MARGINAL, or UNREACHABLE. If such a cause event is found, the two events arecorrelated using the link_effect_to_cause predicate. The effect event(TEC_ITS_INTERFACE_STATUS) is then downgraded to HARMLESS and closed.

rule: node_correlate_interfaceThe node_correlate_interface rule runs upon receipt of aTEC_ITS_NODE_STATUS event with nodestatus equal to DOWN, MARGINAL, orUNREACHABLE. When this event is received, the event cache is searched for anyTEC_ITS_INTERFACE_STATUS events for the same host with ifstatus equal toDOWN, ADMIN_DOWN, or UNREACHABLE. If any such effect events are found, they arecorrelated using the link_effect_to_cause predicate, downgraded to HARMLESS,and closed.

rule: router_up_correlate_subnetThe router_up_correlate_subnet rule runs upon receipt of aTEC_ITS_ROUTER_STATUS event with routerstatus equal to UP. When this eventis received, the event cache is searched for anyTEC_ITS_SUBNET_CONNECTIVITY events with reachability equal toREACHABLE_AGAIN. If any such effect events are found, they are correlated using thelink_effect_to_cause predicate. The effect events(TEC_ITS_SUBNET_CONNECTIVITY) are then downgraded to HARMLESS andclosed.

rule: subnet_correlate_router_upThe subnet_correlate_router_up rule runs upon receipt of aTEC_ITS_SUBNET_CONNECTIVITY event with reachability equal toREACHABLE_AGAIN. When this event is received, the event cache is searched for aTEC_ITS_ROUTER_STATUS event with routerstatus equal to UP. If such a causeevent is found, the two events are correlated using the link_effect_to_causepredicate. The effect event (TEC_ITS_SUBNET_CONNECTIVITY) is thendowngraded to HARMLESS and closed.


rule: interface_up_correlate_router_upThe interface_up_correlate_router_up rule runs upon receipt of aTEC_ITS_INTERFACE_STATUS event with ifstatus equal to UP. When this eventis received, the event cache is searched for a TEC_ITS_ROUTER_STATUS event forthe same host with routerstatus equal to UP. If such a cause event is found, thetwo events are correlated using the link_effect_to_cause predicate. The effectevent is then downgraded to HARMLESS and closed.

rule: interface_up_correlate_node_upThe interface_up_correlate_node_up rule runs upon receipt of aTEC_ITS_INTERFACE_STATUS event with ifstatus equal to UP. When this eventis received, the event cache is searched for a TEC_ITS_NODE_STATUS event forthe same host with nodestatus equal to UP. If such a cause event is found, the twoevents are correlated using the link_effect_to_cause predicate. The effect event(TEC_ITS_INTERFACE_STATUS) is then downgraded to HARMLESS and closed.

rule: node_up_correlate_interface_upThe node_up_correlate_interface_up rule runs upon receipt of aTEC_ITS_NODE_STATUS event with nodestatus equal to UP. When this event isreceived, the event cache is searched for any TEC_ITS_INTERFACE_STATUSevents for the same host with ifstatus equal to UP. If any such effect events arefound, they are correlated using the link_effect_to_cause predicate, downgradedto HARMLESS, and closed.

rule: router_up_correlate_interface_upThe router_up_correlate_interface_up rule runs upon receipt of aTEC_ITS_ROUTER_STATUS event with routerstatus equal to UP. When this eventis received, the event cache is searched for any TEC_ITS_INTERFACE_STATUSevents for the same host with ifstatus equal to UP. If any such effect events arefound, they are correlated using the link_effect_to_cause predicate, downgradedto HARMLESS, and closed.

rule: subnet_correlate_unreachableThe subnet_correlate_unreachable rule runs upon receipt of aTEC_ITS_SUBNET_CONNECTIVITY event. When this event is received, thefollowing actions are taken:v If the reachability attribute of the received event is equal to UNREACHABLE, a

subnet-unreachable fact is asserted in the knowledge base. If reachability isequal to REACHABLE_AGAIN, the subnet-unreachable fact is retracted.

v If the reachability attribute of the received event is equal to UNREACHABLE, theevent cache is searched for any TEC_ITS_UNREACHABLE events from the samesubnet. If any such events are found, they are correlated as effect events,downgraded to HARMLESS, and closed.

v If the reachability attribute of the received event is equal to UNREACHABLE, theevent cache is searched for any TEC_Heartbeat_missed events from the samesubnet. If any such events are found, they are correlated as effect events,downgraded to HARMLESS, and closed.

rule: unreachable_correlate_subnetThe unreachable_correlate_subnet rule runs upon receipt of aTEC_ITS_UNREACHABLE event. When this event is received, the knowledge baseis checked for any subnet-unreachable facts related to the subnet of the IP addressthat is unreachable. If a subnet-unreachable fact is found, the event cache is thensearched for a TEC_ITS_SUBNET_CONNECTIVITY event related to the specifiedsubnet. If this cause event is found, it is correlated with the


TEC_ITS_UNREACHABLE effect event using the link_effect_to_cause predicate.The effect event is then downgraded to HARMLESS and closed.

rule: heartbeat_missed_link_subnetThe heartbeat_missed_link_subnet rule runs upon receipt of aTEC_Heartbeat_missed event. When this event is received, the knowledge base ischecked for any subnet-unreachable facts related to the subnet of the IP addressthat sent the event. If a subnet-unreachable fact is found, the event cache is thensearched for a TEC_ITS_SUBNET_CONNECTIVITY event related to the specifiedsubnet. If this cause event is found, it is associated with the TEC_Heartbeat_missedeffect event using the link_effect_to_cause predicate.

rule: node_link_heartbeat_missedThe node_link_heartbeat_missed rule runs upon receipt of aTEC_ITS_NODE_STATUS event with nodestatus equal to any value other than UP.When this event is received, the event cache is searched for anyTEC_Heartbeat_missed events for the same host. (If the TEC_ITS_NODE_STATUSevent does not have a value for the fqhostname attribute, the hostname attribute iscompared to the fqhostname attribute of the heartbeat event. This comparison isnot case sensitive.) If any such effect events are found, they are associated usingthe link_effect_to_cause predicate.

rule: heartbeat_missed_link_nodeThe heartbeat_missed_link_node rule runs upon receipt of aTEC_Heartbeat_missed event. When this event is received, the event cache issearched for a TEC_ITS_NODE_STATUS event for the same host with nodestatusequal to anything other than UP. (If the TEC_ITS_NODE_STATUS event does nothave a value for the fqhostname attribute, the hostname attribute is compared to thefqhostname attribute of the heartbeat event. This comparison is not case sensitive.)If such a cause event is found, the two events are associated using thelink_effect_to_cause predicate.

rule: router_link_heartbeat_missedThe router_link_heartbeat_missed rule runs upon receipt of aTEC_ITS_ROUTER_STATUS event with routerstatus equal to any value otherthan UP. When this event is received, the event cache is searched for anyTEC_Heartbeat_missed events for the same host. (If theTEC_ITS_ROUTER_STATUS event does not have a value for the fqhostnameattribute, the hostname attribute is compared to the fqhostname attribute of theheartbeat event. This comparison is not case sensitive.) If any such effect events arefound, they are associated using the link_effect_to_cause predicate.

rule: heartbeat_missed_link_routerThe heartbeat_missed_link_router rule runs upon receipt of aTEC_Heartbeat_missed event. When this event is received, the event cache issearched for a TEC_ITS_ROUTER_STATUS event for the same host withrouterstatus equal to anything other than UP. (If the TEC_ITS_ROUTER_STATUSevent does not have a value for the fqhostname attribute, the hostname attribute iscompared to the fqhostname attribute of the heartbeat event. This comparison isnot case sensitive.) If such a cause event is found, the two events are associatedusing the link_effect_to_cause predicate.

timer_rule: delayed_closeThe delayed_close timer rule downgrades to HARMLESS and closes any event thatwas scheduled for delayed closing pending the completion of correlation.


Notification rule set (notify.rls)

OverviewThe notification rule set contains rules that support sending notification to supportpersonnel about new or changed events.

UsageThe notification rule set is not activated in the default rule base. Before activatingthis rule set, you must configure it to specify the contact information (includinge-mail addresses or pager numbers) to use for notification. If you want to usepager notification, you must also customize the assert_notify predicate in thenotify.pro file to specify a script that implements paging. This file is located in$BINDIR/TME/TEC/default_rb/TEC_TEMPLATES. (E-mail notification isimplemented using the Send_Email task; see the IBM Tivoli Enterprise ConsoleUser’s Guide for more information about this task.) After you finish customizing therule set, you must then activate it; see “Modifying the rule base” on page 2 formore information on activating rule sets.

Note: If activated, the notification rule set should be listed near the end of therule_sets file, preferably last. See “Rule set sequencing and dependencies” onpage 3 for more information.

Specifying contact informationBy default, the notification rule set sends e-mail notification for any new eventwhose severity is FATAL, CRITICAL, or MINOR, and for any open event whose severityis changed to FATAL, CRITICAL, or MINOR. Before you can use this rule set, you mustmodify the notify_parameters action of the notify_configure rule to specify thecontact information and the type of notification to use (e-mail or pager). Thecontact information must be specified for each class of event for which you wantto trigger notification. Specify contact information as follows:rerecord(notify_list, class,

[notification,username,address]),

v class is the event class, enclosed in single quotation marks.v notification is the type of notification, either ’MAIL’ or ’PAGE’.v username is the user name of the person to notify, enclosed in single quotation

marks.v address is either the e-mail address or the pager number of the person to notify,

enclosed in single quotation marks.

Rules

Startup rule

rule: notify_configureThe notify_configure rule is a configuration rule that runs upon receipt of theTEC_Start event, which is sent during initialization of the event server. This rule


defines the event criteria that result in notification being sent to support personnel.See “Usage” on page 59 for more information about defining the event criteria.

Notification rules

rule: notify_for_fatal_eventsThe notify_for_fatal_events rule runs upon receipt of any event with FATALseverity. The rule first searches the event cache to see if the newly received event isa duplicate of a previously received open event; if it is, the new event is closed. Ifthe new event is not a duplicate, the assert_notify predicate is used to sendnotification to the appropriate recipient as defined by the notify_configure rule.

Note: Notification is always sent for FATAL events, even if no specific configurationinformation exists for the event class. If no contact information is availablefor the event, the information for the EVENT class is used.

rule: notify_for_new_eventsThe notify_for_new_events rule runs upon receipt of any event with MINOR orCRITICAL severity. The rule first searches the event cache to see if the newlyreceived event is a duplicate of a previously received open event; if it is, the newevent is closed. If the new event is not a duplicate, the assert_notify predicate isused to send notification to the appropriate recipient as defined by thenotify_configure rule.

change_rule: notify_for_change_fatalThe notify_for_change_fatal rule runs when the severity of any open event ischanged to FATAL, provided the event class is specified by the _notify_listparameter. When this happens, the assert_notify predicate is used to sendnotification to the appropriate recipient as defined by the notify_configure rule.

change_rule: notify_for_severity_changeThe notify_for_severity_change rule runs when the severity of an open event ischanged to MINOR or CRITICAL, provided the event class is specified by the_notify_list parameter. When this happens, the assert_notify predicate is used tosend notification to the appropriate recipient as defined by the notify_configurerule.

change_rule: notify_for_status_changeThe notify_for_status_change rule runs when the status of any event withseverity greater than WARNING is changed to OPEN. When this happens, theassert_notify predicate is used to send notification to the appropriate recipient asdefined by the notify_configure rule.


HP OpenView rule set (ov_default.rls)

OverviewThe HP OpenView rule set contains rules that process events from the HPOpenView adapter. These rules handle automatic closing of unimportant eventsand correlation of interface and node events.

UsageThe HP OpenView rule set is not activated in the default rule base. Before you canuse this rule set, you must activate it. See “Modifying the rule base” on page 2 formore information on activating rule sets.

Rules

Event closing rule

rule: phys_addrThe phys_addr rule runs upon receipt of any of the following events:v OV_Phys_Addr_Mismatchv OV_Phys_Addr_Chgv OV_Sys_Descr_Chgv OV_Sys_Contact_Chgv OV_Sys_Location_Chg

When one of these events is received, the rule sets a timer that expires in one hour.This timer is used by the timer_phys_addr timer rule to automatically close theevent if it is still open.

Correlation rules

rule: link_if_downThe link_if_down rule runs upon receipt of the OV_IF_Down event. When thisevent is received, the rule checks to see if it is a duplicate of any previouslyreceived open event. If it is, the repeat_count attribute of the previously receivedevent is incremented, and the newly received event is dropped. If the receivedevent is not a duplicate, the rule then repeats the analysis of any openOV_Node_Down events received from the same host within the previous tenminutes in order to identify possible effect events.

rule: link_if_node_downThe link_if_node_down rule runs upon receipt of the OV_Node_Down event.When this event is received, the rule checks to see if it is a duplicate of anypreviously received open event. If it is, the repeat_count attribute of the previouslyreceived event is incremented, and the newly received event is dropped. If thereceived event is not a duplicate, the rule then checks the event cache for an openOV_IF_Down event received from the same host within the previous ten minutes.If such a cause event is found, the two are associated using thelink_effect_to_cause predicate. The status of the received OV_Node_Down eventis then changed to match the status of the OV_IF_Down event, and the severity ofthe OV_IF_Down event is set to HARMLESS.


change_rule: change_status_if_downThe change_status_if_down change rule runs whenever there is a change in thestatus of an OV_Node_Down event. When this happens, the event cache issearched for any OV_IF_Down events that are associated with the received event.If any such events are found, the new status is propagated to these events also.

change_rule: change_status_node_downThe change_status_if_down change rule runs whenever there is a change in thestatus of an OV_IF_Down event. When this happens, the event cache is searchedfor any OV_Node_Down events that are associated with the received event. If anysuch events are found, the new status is propagated to these events also.

Timer rule

timer_rule: timer_phys_addrThe timer_phys_addr timer rule runs upon expiration of the timer set by thephys_addr rule. This rule closes any of the events specified in that rule if they arestill open after one hour.


NetView for z/OS event forwarding rule set(tecad_nv390fwd.rls)

OverviewThe NetView for z/OS event forwarding rule set contains rules that supportforwarding events from the NetView for z/OS message adapter or alert adapter toanother event server.

UsageThe Netview for z/OS event forwarding rule set is not activated in the default rulebase. Before you can use this rule set, you must configure the forwarding functionby defining the server to which events are to be forwarded. You must then activatethe rule set. See “Modifying the rule base” on page 2 for more information onactivating rule sets.

You must also define the location of the event server to which events areforwarded. The destination server for the event forwarding function is specified bythe tec_forward.conf configuration file. By default, this file specifies that the eventforwarding function should operate in test mode, which sends events to a file. Tospecify a server, you must modify the value of the ServerLocation keyword tospecify the destination server. You must also specify TestMode=NO or comment outthe TestMode keyword entirely. For more information about configuration filekeywords, see the IBM Tivoli Enterprise Console Event Integration Facility Reference.

Rules

Event forwarding rules

rule: fwd_to_nv390The fwd_to_nv390 rule runs upon receipt of any CRITICAL or FATAL event thatdid not originate from a NetView for z/OS adapter. When this event is received,the rule uses the forward_event predicate to forward the event to the serverspecified in the tec_forward.conf configuration file.

change_rule: fwd_closed_to_nv390The fwd_closed_to_nv390 change rule runs when a CRITICAL or FATAL event thatdid not originate from a NetView for z/OS adapter is closed. When this happens,the rule uses the forward_event predicate to forward the changed event to theserver specified in the tec_forward.conf configuration file.

change_rule: fwd_severity_to_nv390The fwd_severity_to_nv390 change rule runs whenever the status of an event thatdid not originate from a NetView for z/OS adapter is changed to CRITICAL orFATAL. When this happens, the rule uses the forward_event predicate to forwardthe event to the server specified in the tec_forward.conf configuration file.


NetView for z/OS message rule set (tecad_nv390msg.rls)

OverviewThe NetView for z/OS message rule set processes events from the NetView forz/OS Message Adapter.

UsageThe Netview for z/OS message rule set is not activated in the default rule base.Before you can use this rule set, you must activate it. See “Modifying the rulebase” on page 2 for more information on activating rule sets.

Rules

Duplicate detection rule

rule: nv390msg_dup_eventThe nv390msg_dup_event rule runs upon receipt of any event of classNV390MSG_EVENT. When this event is received, the rule checks to see if it is aduplicate of any previously received open event. If it is, the repeat_count attributeof the previously received event is incremented, and the newly received event isdropped.


SNA event rules tecad_snaevent.rls

OverviewThe SNA event rule set processes events related to SNA alerts. These events aresent by the Tivoli Enterprise Console AS/400® SNA Alert Adapter and NetView forz/OS Alert Adapter.

UsageThe SNA event rule set is not activated in the default rule base. Before you can usethis rule set, you must activate it. See “Modifying the rule base” on page 2 formore information on activating rule sets.

Rules

Correlation and duplicate detection rules

rule: sna_dup_eventThe sna_dup_event rule runs upon receipt of any event of class SNA_Event. Whenthis event is received, the rule checks to see if it is a duplicate of any previouslyreceived open event. If it is, the repeat_count attribute of the previously receivedevent is incremented, and the newly received event is dropped.

rule: sna_correlated_eventThe sna_correlated_event rule runs upon receipt of any event of class SNA_Eventwith event_correl equal to anything other than N/A. When this event is received,the rule checks to see if it is correlated with a previously received open SNA alertevent, as indicated by the SNA alert subvector 47 information in the event_correlattribute. If it is, the repeat_count attribute of the previously received event isincremented, and the newly received event is dropped. (See the IBM SNA Formatsbook for more information about subvector 47.)

Generic alert resolution rules

rule: sna_Mv0002_ResolutionThe sna_Mv0002_Resolution rule runs upon receipt of an event of class SNA_Eventwith arch_type equal to GENERIC_RESOLUTION and incident_correl not equal toN/A. This event indicates a SNA major vector 0002 resolution. When this event isreceived, the event cache is searched for any open events associated with SNAmajor vector 0000 generic alerts that are resolved by the specified resolution. If anysuch events are found, they are closed. (See the IBM SNA Formats book for moreinformation.)

rule: sna_Mv0000_Generic_AlertThe sna_Mv0000_Generic_Alert rule runs upon receipt of any SNA_Event eventwith arch_type equal to GENERIC_ALERT and incident_correl not equal to N/A,indicating a SNA Major Vector 0000 generic alert. When this event is received, theevent cache is searched for any previously received Major Vector 0002 genericresolution events that resolved the received newly received alert. If a resolutionevent is found, the rule requests reanalysis of the resolution event so the alertevent can be closed.


Trouble ticket rule set (troubleticket.rls)

OverviewThe trouble ticket rule set contains rules that support the integration of the TivoliEnterprise Console product with trouble ticket systems. These rules automaticallyopen trouble tickets for new events matching user-defined criteria, as well asassociating existing events with trouble tickets opened by the trouble ticket system.Once a trouble ticket is opened, the rules provide two-way synchronizationbetween the Tivoli Enterprise Console product and the external trouble ticketsystem. This synchronization includes the following:v If the status or severity of an event changes, any associated trouble ticket is

automatically updated to reflect the new information.v If an trouble ticket changes, any associated events are automatically updated to

reflect the new information.v If an event is closed, any associated trouble ticket is automatically closed.v If a trouble ticket is closed, any associated events are automatically closed.

See the IBM Tivoli Enterprise Console User’s Guide for more information aboutintegrating the Tivoli Enterprise Console product with trouble ticket systems.

UsageThe trouble ticket rule set is not activated in the default rule base. Before you canuse this rule set, you must configure it for your environment by defining the eventcriteria that are to be used for automatic opening of trouble tickets. You must thenactivate the rule set. See “Modifying the rule base” on page 2 for more informationon importing rule sets into the rule base.

Defining event criteriaThe tt_configure configuration rule defines the event criteria that trigger theautomatic opening of trouble tickets. These criteria are defined using a series ofassert_tt statements, each of which specifies the criteria for a type of event thatshould cause a trouble ticket to be automatically opened. The format of theassert_tt statement is as follows:assert_tt(ev_class,ev_sev,ev_host)

ev_class is the class of the event, ev_sev is the severity of the event, and ev_host isthe fully qualified host name of the originating host (specified by the fqhostnameattribute). Each value must be enclosed in single quotation marks. An underscore(_) represents any value. For example:assert_tt(’TEC_Error’,’FATAL’,_) % all FATAL TEC_Error events from any hostassert_tt(_,’CRITICAL’,_) % all CRITICAL events from any hostassert_tt(_,_,’myhost.raleigh.ibm.com’) % all events from myhost.raleigh.ibm.com

Add these assert_tt statements to the configure_knowledge_base action of thett_configure rule.


Optional configurationYou can customize the trouble ticket rule set by modifying statements in thett_parameters action of the tt_configure configuration rule. The following optionsare configurable:v Administrator name. You can specify the administrator name to use when

automatically acknowledging or closing events. The default administrator nameis troubleticket.rls. To change the administrator name, modify the statementthat sets the _tt_admin parameter as follows:_tt_admin = admin,

admin is the administrator name to use, enclosed in single quotation marks.v Error log file. You can specify the name of the file used for logging error

messages. The default value is /tmp/troubleticket.err. To specify a differentfile, modify the statement that sets the _tt_err_log parameter as follows:_tt_err_log = filename,


v Multiple-event trouble tickets. You can specify whether you want to allowmultiple events to be associated with a single trouble ticket. If this option isturned off, a new trouble ticket is opened for each event that matches definedcriteria for opening a trouble ticket, even if a similar trouble ticket is alreadyopen. By default, this option is turned on; to change this value, modify thestatement that sets the _assoc_flag parameter as follows:_assoc_flag = flag

flag is either ’ON’ or ’OFF’.v Fact file. You can specify the name of the file to use to store trouble ticket facts

in the knowledge base. You can either specify an absolute location for the file orspecify the file name only, in which case the file is created in the $DBDIRdirectory. The default file name is troubleticket.pro. To change the file name,modify the statement that sets the _kbase_file variable as follows:_kbase_file = filename

filename is the name of the fact file you want to use, optionally including arelative or absolute path, and enclosed in single quotation marks.

v Latency. You can specify the time range to be used when searching the eventcache for events associated with trouble tickets. This time range, or latency,affects both backward and forward event searches. By default, searches arelimited to one week (604 800 seconds) backward or forward in the event cache.To change the latency, modify the statement that sets the _tt_elapsed parameter asfollows:_tt_elapsed = seconds




Rules

Startup rule

rule: tt_configureThe tt_configure rule is a configuration rule that runs upon receipt of theTEC_Start event, which is sent during intialization of the event server. This rulesets global parameters for the trouble ticket rules and initializes the fact file for therule set. In addition, this rule asserts facts in the knowledge base that define theevent criteria used to automatically generate trouble tickets. You must configurethis rule before using the trouble ticket rule set; see “Usage” on page 69 for moreinformation.

Trouble ticket opening rules

rule: process_tt_task_completeThe process_tt_task_complete rule runs upon receipt of a TASK_COMPLETEevent with task_name equal to open_tt, which indicates that a trouble ticket hasbeen opened. When this event is received, the rule reads the results of the task inorder to identify the new trouble ticket ID and the event that led to the troubleticket. The ttid attribute of the associated event is then set to the new troubleticket ID.

rule: open_ttThe open_tt rule runs upon receipt of any event that satisfies defined criteria forautomatically opening a trouble ticket. These criteria are stored in the knowledgebase and are configured by the tt_configure configuration rule. When a matchingevent arrives, the rule performs one of the following actions:v If the _assoc_flag parameter is set to ON, the rule checks to see if an open trouble

ticket is already associated with another event of the same class, from the samehost and with the same severity. If such a trouble ticket already exists, the newlyreceived event is associated with the existing trouble ticket. The ttid attribute ofthe new event is set to the ID of the trouble ticket, and the TroubleTicket.shscript is used to add a message to the existing trouble ticket specifying the newevent.

v If no similar trouble ticket is already open, or if the _assoc_flag parameter is setto OFF, the TroubleTicket.sh script is used to open a new trouble ticket. The ttidattribute of the new event is set to the ID of the new trouble ticket.

rule: process_tt_open_eventThe process_tt_open_event rule runs upon receipt of a TT_Open_Event event,which is sent by the trouble ticket system to indicate that a trouble ticket has beenopened for an event. When TT_Open_Event is received, the ttid attribute of theassociated event is set to the ID of the specified trouble ticket. The receivedTT_Open_Event event is then dropped.

Trouble ticket synchronization rules

rule: process_tt_update_eventThe process_tt_update_event rule runs upon receipt of a TT_Update_Event event,which is sent by the trouble ticket system to indicate that a trouble ticket has beenupdated. If the TT_Update_Event event specifies an associated event, that event isupdated with the new information; otherwise, all events associated with thetrouble ticket are updated. The slotvector attribute of the received event contains

Trouble ticket rule set (troubleticket.rls) 71

name and value pairs that specify what changes should be made to the attributesof associated events. The received TT_Update_Event event is then dropped.

rule: process_tt_close_eventThe process_tt_close_event rule runs upon receipt of a TT_Close_Event event,which is sent by the trouble ticket system to indicate that a trouble ticket has beenclosed. When this event is received, any open events associated with the closedtrouble ticket are automatically closed. The received TT_Close_Event event is thendropped.

change_rule: update_status_ttThe update_status_tt change rule runs when the status of an event associatedwith a trouble ticket changes to any value other than CLOSED. When this happens,the TroubleTicket.sh script is used to update the trouble ticket to reflect thechanged status.

change_rule: update_severity_ttThe update_severity_tt change rule runs when there is a change in the severity ofany event that is associated with a trouble ticket. When this happens, theTroubleTicket.sh script is used to update the trouble ticket to reflect the changedseverity.

change_rule: close_ttThe close_tt change rule runs when an event associated with a trouble ticket isclosed. When this happens, the rule performs one of the following actions:v If the _assoc_flag global parameter is set to OFF, the associated trouble ticket is

closed.v If the _assoc_flag global parameter is set to ON, the event cache is searched for

other events associated with the same trouble ticket. If other associated eventsare found, the trouble ticket is updated to reflect the closed event. If no otherassociated events are found, the trouble ticket is closed.


Notices

This information was developed for products and services offered in the U.S.A.IBM may not offer the products, services, or features discussed in this document inother countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user’s responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not give youany license to these patents.You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785 U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBMIntellectual Property Department in your country or send inquiries, in writing, to:

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chome, Minato-kuTokyo 106, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION ″AS IS″ WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE.

Some states do not allow disclaimer of express or implied warranties in certaintransactions, therefore, this statement might not apply to you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of those Websites. The materials at those Web sites are not part of the materials for this IBMproduct and use of those Web sites is at your own risk.


IBM may use or distribute any of the information you supply in any way itbelieves appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758 U.S.A.

Such information may be available, subject to appropriate terms and conditions,including in some cases payment of a fee.

The licensed program described in this document and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement or any equivalent agreementbetween us.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurement may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

All statements regarding IBM’s future direction or intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.

This information contains sample application programs in source language, whichillustrate programming techniques on various operating platforms. You may copy,modify, and distribute these sample programs in any form without payment toIBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operatingplatform for which the sample programs are written. These examples have notbeen thoroughly tested under all conditions. IBM, therefore, cannot guarantee orimply reliability, serviceability, or function of these programs. You may copy,modify, and distribute these sample programs in any form without payment toIBM for the purposes of developing, using, marketing, or distributing applicationprograms conforming to IBM’s application programming interfaces.


If you are viewing this information in softcopy form, the photographs and colorillustrations might not appear.

TrademarksThe following terms are trademarks of International Business MachinesCorporation in the United States, other countries, or both:v IBMv IBM logov Tivoliv Tivoli logov DB2v IBMLinkv NetViewv Tivoli Enterprise Consolev TME

Java and all Java-based trademarks and logos are trademarks or registeredtrademarks of Sun Microsystems, Inc. in the United States, other countries,or both.

Microsoft and Windows NT are registered trademarks of Microsoft Corporation inthe United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registeredtrademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and othercountries.

Other company, product, and service names may be trademarks or service marksof others.

Notices 75

Index

Aactivity report 27activity.log file 27AS/400 SNA alert adapter 67

Bbooks

see publications v, vi

Ccanceling maintenance 39cleanup.rls 5clearing event 7conventions

typeface viiicorrelating events 44correlation.rls 3, 7customer support

see software support vii

Ddatabase cleanup 9DB_Cleanup_event event 9, 10db_cleanup.rls 9DB2 software

See IBM DB2 softwareDB2_Down_Status event 20DB2_High_ApplicationAgent_TotSystemCpuTime event 20DB2_High_ApplicationAgents_Workload event 20DB2_High_ConnectionErrors event 20DB2_High_ConnWaitingForHost event 20DB2_High_CurrentConnections event 20DB2_High_DB2ApplicationAgent_TotUserCpuTime event 20DB2_High_HostTimePerStatement event 20DB2_High_InstanceAgents_AgentCreationRatio event 20DB2_High_InstanceAgents_PctAgentsWaiting event 20DB2_High_MostRecentConnectResponse event 20DB2_High_NetworkTimePerStatement event 20DB2_High_PctConnectionsUsed event 20DB2_High_TimePerStatement event 20deactivating rule sets 3default rule base 1

directory 1defining dependency relationships 17deleting old closed events 9dependencies.pro file 11dependency relationship 11, 13

analyzing events based on 14correlating events based on 13defining 11, 13, 17types 13WAS_DEPENDS_ON_DB2 13WMQ_DEPENDS_ON_WMQ 13

dependency.log file 11dependency.rls 4, 11, 16directory names, notation ix

Ee-business cause event 15e-business services 13, 17

defining dependency relationships 17IBM DB2 software 13IBM WebSphere Application Server 13IBM WebSphere MQ 13

e-mail notification 23, 35, 36, 38, 59ebusiness.log file 16ebusiness.rls 4, 11, 13environment variables, notation ixEscalate_event event 25escalate.rls 4, 23event 5

activity report 27analyzing based on dependency relationships 14associating based on dependency relationships 13cause event 14clearing event 7closing old open events 5correlating 7, 44DB_Cleanup_event 9, 10DB2_Down_Status 20DB2_High_ApplicationAgent_TotSystemCpuTime 20DB2_High_ApplicationAgents_Workload 20DB2_High_ConnectionErrors 20DB2_High_ConnWaitingForHost 20DB2_High_CurrentConnections 20DB2_High_DB2ApplicationAgent_TotUserCpuTime 20DB2_High_HostTimePerStatement 20DB2_High_InstanceAgents_AgentCreationRatio 20DB2_High_InstanceAgents_PctAgentsWaiting 20DB2_High_MostRecentConnectResponse 20DB2_High_NetworkTimePerStatement 20DB2_High_PctConnectionsUsed 20DB2_High_TimePerStatement 20deleting old closed events 9e-business cause event 15Escalate_event 25escalating 23, 31event sequence 7forwarding to another event server 33, 63HeartBeat_DMAgentDown 19HeartBeat_EndpointUnreachable 19HeartBeat_Off 19HeartBeat_ResourceModelsInError 19increasing severity 23, 31informational 14maintenance cause event 15network cause event 15NV390MSG_EVENT 65OV_IF_Down 61, 62OV_Node_Down 61, 62OV_Phys_Addr_Chg 61OV_Phys_Addr_Mismatch 61OV_Sys_Contact_Chg 61OV_Sys_Descr_Chg 61OV_Sys_Location_Chg 61probable cause 15probable cause event 14service impact 15, 44


event (continued)SNA_Event 67TASK_COMPLETE 71TEC_Cleanup_event 6TEC_Dependency 11, 12TEC_Heartbeat 27, 29, 35, 37TEC_Heartbeat_missed 14, 19, 35, 37, 38, 44, 57, 58TEC_ITS_INTERFACE_ADDED 48, 49TEC_ITS_INTERFACE_MANAGE 48, 49TEC_ITS_INTERFACE_STATUS 44, 47, 48, 50, 55, 56, 57TEC_ITS_ISDN_STATUS 47, 48TEC_ITS_L2_NODE_STATUS 44, 48, 49, 53, 54TEC_ITS_NODE_ADDED 48, 49TEC_ITS_NODE_MANAGE 48, 50TEC_ITS_NODE_SERVICE_IMPACT 15, 19, 20, 21, 44, 48,

49, 51TEC_ITS_NODE_STATUS 15, 16, 20, 44, 47, 48, 50, 51, 52,

53, 56, 57, 58TEC_ITS_Not_Monitoring_eBusiness 15, 16TEC_ITS_ROUTER_STATUS 44, 47, 48, 50, 51, 54, 55, 56,

57, 58TEC_ITS_SA_STATUS 44, 48, 49, 52, 53, 54TEC_ITS_SNMPCOLLECT_THRESHOLD 47, 48TEC_ITS_SUBNET_CONNECTIVITY 44, 47, 49, 52, 55, 56,

57, 58TEC_ITS_SUBNET_SERVICE_IMPACT 44, 49, 52TEC_ITS_UNREACHABLE 44, 57TEC_Maintenance 15, 16, 20, 21, 27, 29, 39, 41, 42TEC_PROBABLE_EVENT_ASSOCIATION 15, 16TEC_Start 6, 8, 9, 12, 19, 25, 28, 29, 31, 33, 37, 41, 47, 59,

71TEC_Stop 12, 19, 47TT_Close_Event 72TT_Open_Event 71TT_Update_Event 71WebSphere_MQ_ChannelNotActivated 20WebSphere_MQ_ChannelNotTransmitting 20WebSphere_MQ_ChannelStartupError 20WebSphere_MQ_ChannelThroughputProblem 20WebSphere_MQ_QueueFilling 20WebSphere_MQ_QueueManagerUnavailable 20WebSphereAS_high_DBPool_avgWaitTime 20WebSphereAS_high_DBPool_faults 20WebSphereAS_high_DBPool_percentUsed 20WebSphereAS_high_Transaction_avg_response_time 20WebSphereAS_high_Transaction_timeout_ratio 20

event cache 5purging old open events 5

event_activity.rls 27event_filtering.rls 3, 29event_thresholds.rls 31

Fforwarding.rls 33

Hheartbeat 44heartbeat pulse 35, 37HeartBeat_DMAgentDown event 19HeartBeat_EndpointUnreachable event 19HEARTBEAT_LEVEL enumeration 35HeartBeat_Off event 19HeartBeat_ResourceModelsInError event 19heartbeat.rls 4, 35

HP OpenView adapter 61

IIBM DB2 software 13, 15, 20, 22IBM Tivoli Monitoring 14, 19IBM Tivoli Monitoring for Business Integration 14, 15IBM Tivoli Monitoring for Databases 14IBM Tivoli Monitoring for Web Infrastructure 14IBM WebSphere Application Server 13, 20, 22IBM WebSphere MQ 13, 15, 20, 21increasing event severity 23, 31informational event 14integrating with trouble ticket systems 69

LLevel 2 network event 44Level 3 network event 44

Mmaintenance cause event 15maintenance mode 15, 37, 39

entering 39exiting 39

maintenance_mode.pro file 40maintenance_mode.rls 3, 39manuals

see publications v, vimissed heartbeat 44monitoring heartbeats 35

NNetView component 15, 43

correlating events 44event clearing 43event severity 43Level 2 event 44Level 3 event 44sending SNMP traps to 43, 45, 46synchronizing with 43, 45, 46

NetView for z/OS alert adapter 63, 67NetView for z/OS message adapter 63, 65netview.log file 46netview.rls 4, 43network cause event 15newsgroups viinotation

environment variables ixpath names ixtypeface ix

notify.pro file 59notify.rls 4, 23, 59NV390MSG_EVENT event 65

Oonline publications

accessing viordering publications viiov_default.rls 61OV_IF_Down event 61, 62OV_Node_Down event 61, 62


OV_Phys_Addr_Chg event 61OV_Phys_Addr_Mismatch event 61OV_Sys_Contact_Chg event 61OV_Sys_Descr_Chg event 61OV_Sys_Location_Chg event 61

Ppager notification 23path names, notation ixprobable cause event 14, 15publications v

accessing online viordering vii

Rrule base 1

default 1modifying 2sequencing rule sets 3, 7, 16, 23, 29, 40, 59

rule set 1activating 1cleanup.rls 5configuration 1correlation.rls 3corrlation.rls 7db_cleanup.rls 9deactivating 3dependency.rls 11, 16ebusiness.rls 11, 13escalate.rls 4, 23event_activity.rls 27event_filtering.rls 3, 29event_thresholds.rls 31file location 1forwarding.rls 33heartbeat.rls 35maintenance_mode.rls 3, 39modifying 2netview.rls 43notify.rls 4, 23, 59ov_default.rls 61preconfigured 1sequencing 3, 7, 16, 23, 29, 40, 59tecad_nv390.rls 65tecad_nv390fwd.rls 63tecad_snaevent.rls 67troubleticket.rls 69

rule_sets file 3

Sscheduling maintenance 39sequencing of rule sets 3service impact event 15, 44SNA 67SNA_Event event 67SNMP trap 43, 45, 46software support

contacting viiStart_Maintenance task 39synchronizing with NetView component 43, 45, 46

TTASK_COMPLETE event 71TEC_Cleanup_event event 6TEC_Dependency event 11, 12tec_forward.conf file 33, 63TEC_Heartbeat event 27, 29, 35, 37TEC_Heartbeat_missed event 14, 19, 35, 37, 38, 44, 57, 58TEC_ITS_INTERFACE_ADDED event 48, 49TEC_ITS_INTERFACE_MANAGE event 48, 49TEC_ITS_INTERFACE_STATUS event 44, 47, 48, 50, 55, 56, 57TEC_ITS_ISDN_STATUS event 47, 48TEC_ITS_L2_NODE_STATUS event 44, 48, 49, 53, 54TEC_ITS_NODE_ADDED event 48, 49TEC_ITS_NODE_MANAGE event 50TEC_ITS_NODE_MANAGEevent 48TEC_ITS_NODE_SERVICE_IMPACT 51TEC_ITS_NODE_SERVICE_IMPACT event 15, 19, 20, 21, 44,

48, 49, 51TEC_ITS_NODE_STATUS 15TEC_ITS_NODE_STATUS event 16, 20, 44, 47, 48, 50, 51, 52,

53, 56, 57, 58TEC_ITS_Not_Monitoring_eBusiness event 15, 16TEC_ITS_ROUTER_STATUS event 44, 47, 48, 50, 51, 54, 55,

56, 57, 58TEC_ITS_ROUTER_STATUSevent 54TEC_ITS_SA_STATUS event 44, 48, 49, 52, 53, 54TEC_ITS_SNMPCOLLECT_THRESHOLD event 47, 48TEC_ITS_SUBNET_CONNECTIVITY event 44, 47, 49, 52, 55,

56, 57, 58TEC_ITS_SUBNET_SERVICE_IMPACT event 44, 49, 52TEC_ITS_UNREACHABLE event 44, 57TEC_Maintenance event 15, 16, 20, 21, 27, 29, 39, 41, 42TEC_PROBABLE_EVENT_ASSOCIATION event 15, 16TEC_Start event 6, 8, 9, 12, 19, 25, 28, 29, 31, 33, 37, 41, 47,

59, 71TEC_Stop event 12, 19, 47tecad_nv390fwd.rls 63tecad_nv390msg.rls 65tecad_snaevent.rls 67threshold, event 31Tivoli Monitoring

See IBM Tivoli MonitoringTivoli Software Information Center vitroubleticket.err file 70troubleticket.pro file 70troubleticket.rls 69TT_Close_Event event 72TT_Open_Event event 71TT_Update_Event event 71typeface conventions viii

Vvariables, notation for ix

WWebSphere Application Server

See IBM WebSphere Application ServerWebSphere MQ

See IBM WebSphere MQWebSphere_MQ_ChannelNotActivated event 20WebSphere_MQ_ChannelNotTransmitting event 20WebSphere_MQ_ChannelStartupError event 20WebSphere_MQ_ChannelThroughputProblem event 20WebSphere_MQ_QueueFilling event 20

Index 79

WebSphere_MQ_QueueManagerUnavailable event 20WebSphereAS_high_DBPool_avgWaitTime event 20WebSphereAS_high_DBPool_faults event 20WebSphereAS_high_DBPool_percentUsed event 20WebSphereAS_high_Transaction_avg_response_time event 20WebSphereAS_high_Transaction_timeout_ratio event 20wrb –deldp command 11, 12, 18wrb –imptdp command 11, 12, 18wstartmaint.sh script 39wstopmaint.sh script 39wtdbclear command 9


��

Printed in U.S.A.

SC32-1282-00