• No results found

IBM Tivoli Enterprise Console. Rule Set Reference SC

N/A
N/A
Protected

Academic year: 2021

Share "IBM Tivoli Enterprise Console. Rule Set Reference SC"

Copied!
94
0
0

Loading.... (view fulltext now)

Full text

(1)

IBM Tivoli Enterprise Console

Rule Set Reference

SC32-1282-00



(2)
(3)

IBM Tivoli Enterprise Console

Rule Set Reference

SC32-1282-00



(4)

Note

Before 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 all subsequent releases and modifications until otherwise indicated in new editions.

(5)

Contents

About this guide . . . v

Who should read this guide . . . v

Publications . . . v

IBM Tivoli Enterprise Console library . . . v

Related publications . . . vi

Accessing publications online . . . vi

Ordering publications . . . vii

Contacting software support . . . vii

Participating in newsgroups . . . vii

Conventions used in this guide . . . viii

Typeface conventions . . . viii

Operating system-dependent variables and paths ix

Introduction . . . 1

Modifying the rule base . . . 2

Activating and deactivating rule sets . . . 3

Rule 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 rule

set (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

. . . 73

Trademarks . . . 75

Index . . . 77

(6)
(7)

About this guide

The IBM®Tivoli Enterprise Console® product is a rule-based, event management application that integrates system, network, database, and application management to help ensure the optimal availability of an organization’s IT services. The IBM

Tivoli Enterprise Console Rule Set Reference provides information about the rule sets

provided for processing common application and infrastructure events.

Who should read this guide

This guide is for system administrators who need to deploy rules for automating management of Tivoli Enterprise Console events received by the Tivoli Enterprise Console event server.

Readers should be familiar with the following topics:

v The operating systems and e-business applications that your enterprise uses v The Tivoli®Management Framework

v The IBM Tivoli NetView®product

v The IBM Tivoli Enterprise Console product

Publications

This section lists publications in the IBM Tivoli Enterprise Console library and related documents. It also describes how to access Tivoli publications online and how to order Tivoli publications.

IBM Tivoli Enterprise Console library

The following documents are available in the IBM Tivoli Enterprise Console library:

v IBM Tivoli Enterprise Console Adapters Guide, SC32-1242

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

v IBM Tivoli Enterprise Console Command and Task Reference, SC32-1232

Provides details about IBM Tivoli Enterprise Console commands, predefined tasks that are shipped in the task library, and the environment variables that are available to tasks that run against an event.

v IBM Tivoli Enterprise Console Installation Guide, SC32-1233

Describes how to install, upgrade, and uninstall the IBM Tivoli Enterprise Console product.

v IBM Tivoli Enterprise Console Release Notes, SC32-1238

Provides release-specific information that is not available until just before the product is sent to market.

v IBM Tivoli Enterprise Console Rule Developer’s Guide, SC32-1234

Describes how to develop rules and integrate them for event correlation and automated event management.

v IBM Tivoli Enterprise Console Rule Set Reference, SC32-1282

Provides reference information about the IBM Tivoli Enterprise Console rule sets. v IBM Tivoli Enterprise Console User’s Guide, SC32-1235

(8)

Provides an overview of the IBM Tivoli Enterprise Console product and

describes how to configure and use the IBM Tivoli Enterprise Console product to manage events.

v IBM Tivoli Enterprise Console Warehouse Enablement Pack: Implementation Guide, SC32-1236

Describes how to install and configure the warehouse enablement pack for the IBM Tivoli Enterprise Console product and describes the data flow and structures that are used by the warehouse pack.

v Tivoli Event Integration Facility Reference, SC32-1241

Describes how to develop your own event adapters that are tailored to your network environment and the specific needs of your enterprise. This reference also describes how to filter events at the source.

Related publications

v IBM Tivoli Monitoring: User’s Guide, SH19-4569

v IBM Tivoli Monitoring for Business Integration: WebSphere® MQ: User’s Guide, GC23-4716

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

v IBM Tivoli Monitoring for Databases: DB2®: User’s Guide, SC23-4726 v IBM Tivoli Monitoring for Databases: DB2: Reference Guide, SC23-4727

v IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server: User’s

Guide, SC23-4705

v IBM Tivoli Monitoring for Web Infrastructure: Reference Guide, GC23-4720 The Tivoli Software Glossary includes definitions for many of the technical terms related to Tivoli software. TheTivoli Software Glossary is available, in English only, at the 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 Tivoli software library window.

Accessing publications online

The 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 on the CD for instructions on how to access the documentation.

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

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

Scroll down and click the Product manuals link. In the Tivoli Technical Product Documents Alphabetical Listing window, click the IBM Tivoli Enterprise Console link 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 to

(9)

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

Ordering publications

You 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-2755

v 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 support

If you have a problem with any Tivoli product, refer to the following IBM Software Support Web site:

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

If you want to contact software support, see the IBM Software Support Guide at the following 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 eligibility

v Telephone numbers and e-mail addresses, depending on the country in which you are located

v Information you must have before contacting IBM Software Support

Participating in newsgroups

User groups provide software professionals with a forum for communicating ideas, technical expertise, and experiences related to the product. They are located on the Internet and are available using standard news reader programs. These groups are primarily intended for user-to-user communication and are not a replacement for formal 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.

(10)

7. Cut and paste the newsgroup address of a product into the browser Address field, 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 guide

This guide uses several conventions for special terms and actions, operating system-dependent commands and paths, and margin graphics.

Typeface conventions

This guide uses the following typeface conventions:

Bold

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

v Interface controls (check boxes, push buttons, radio buttons, spin buttons, fields, folders, icons, list boxes, items inside list boxes,

multicolumn lists, containers, menu choices, menu names, tabs, property sheets), labels (such as Tip:, and Operating system considerations:) v Column headings in a table

v Keywords and parameters in text

Italic

v Citations (titles of books, diskettes, and CDs) v Words defined in text

v Emphasis of words (words as words) v Letters as letters

v New terms in text (except in a definition list) v Variables and values you must provide Monospace

v Examples and code examples

v File names, programming keywords, and other elements that are difficult to distinguish from surrounding text

(11)

v Message text and prompts addressed to the user v Text that the user must type

v Values for arguments or command options

Operating system-dependent variables and paths

This guide uses the UNIX convention for specifying environment variables and for directory notation.

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

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

(12)
(13)

Introduction

The Tivoli Enterprise Console rule engine processes events based on rules written in the Tivoli Enterprise Console rule language. A rule defines a set of actions that are taken when certain conditions are met; these conditions might include the arrival 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 Enterprise

Console Rule Developer’s Guide for more information about rules and the rule

language. A rule set is a file containing a group of logically related rules written in the rule language, while a rule base is a collection of compiled rule sets and supporting data (including class definitions and Prolog predicates) used by those rule sets.

The default rule base provided with the Tivoli Enterprise Console product includes a number of preconfigured rule sets that provide support for processing common application and infrastructure events. These rules provide powerful duplication detection, filtering, escalation, notification, and correlation capabilities without requiring any additional rule development. The rules included in the default rule base 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 relationships

v Scheduling of maintenance windows and discarding of events from systems currently undergoing maintenance

v Integration with external trouble ticket systems

v Heartbeat monitoring and detection of missed heartbeat pulses

Some of the rule sets in the default rule base are already activated, while others must be activated before use. In addition, some of the rule sets must be configured for your environment. In general, configuration requires only modification of global parameters defined in the configuration rule at the beginning of the rule set; other rule sets might require configuration of external files. The reference sections of 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 in the default rule base and indicates which are already activated, as well as which require configuration before use.

Table 1. Rule sets included in the default rule base

Rule set Description Activated Configuration

required

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-business rules

Yes No

ebusiness.rls Causal analysis of events from e-business applications

Yes Yes

escalate.rls Automatic severity escalation No No

(14)

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

Rule set Description Activated Configuration

required 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®

Message Adapter 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 base

You cannot directly modify the default rule base provided with the Tivoli Enterprise Console product. If you want to make any changes to this rule base (including activating or deactivating rule sets, modifying rule sets, or changing rule base 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 in the rule base and indicates which are active. (See “Activating and deactivating rule sets” on page 3 for more information.)

After you have made a copy of the default rule base, you can then make any changes you want to make to the copy. In general, follow these steps to modify the rule base:

1. Make the necessary changes, including any of the following:

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

v Editing rule set or BAROC files

v Creating or deleting rule base targets using the wrb –crttarget and wrb

–delrbtargetcommands

v Importing or deleting rule sets in rule base targets using the wrb –imptgtrule and wrb –deltgtrule commands

2. Compile the new rule base using the wrb –comprules command. 3. Load the new rule base using the wrb –loadrb command.

(15)

See the IBM Tivoli Enterprise Console Rule Developer’s Guide for more information about working with rule bases, and the IBM Tivoli Enterprise Console Command and

Task Reference for more information about the wrb command.

Activating and deactivating rule sets

The rule_sets file, located in the TEC_RULES subdirectory of each rule base, lists all of the rule sets included in that rule base. It also indicates which rule sets are active and which are inactive. All of the rule sets listed in rule_sets are considered part of the rule base and are included when the rule base is copied. However, only active rule sets can be imported into rule base targets.

The contents of the rule_sets file consist of a series of Prolog statements, each in the 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 one inactive:

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 make these changes directly to the default rule base; see “Modifying the rule base” on page 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 more information about the wrb command.

Rule set sequencing and dependencies

The rule engine processes the active rule sets in the order in which they are listed in 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 in mind:

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 that are to be filtered out by this rule set.

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

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 the

general-purpose correlation rules.

(16)

v The escalation rule set (escalate.rls) should be near the end of the sequence, and should come after correlation.rls. This ensures that event severities can be appropriately 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 sets that process events from e-business services monitored by IBM Tivoli Monitoring products.

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 event information.

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 use this 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 you want to use the e-business rules, both rule sets must be activated.

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

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

(17)

Cleanup rule set (cleanup.rls)

Overview

The cleanup rule set contains rules that are used to purge old open events from the event cache.

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

Usage

The cleanup rule set is already activated in the default rule base. If you make any 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.

Optional configuration

The cleanup rule set is preconfigured and ready to use. However, you can

customize this rule set by modifying statements in the cleanup_start configuration rule. 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 age limit 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 remain

open before being automatically closed.

v Cleanup frequency.You can specify how frequently you want the rules to check for old events to close. The default frequency is every 30 minutes. To change the cleanup frequency, modify the statement that sets the _cleanup_interval parameter as 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 default behavior is to close events with severities of HARMLESS or UNKNOWN. To change this value, 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.

(18)

v Administrator name.You can specify the administrator name to use when the cleanup rules automatically close events. The default administrator name is cleanup.rls. To change the administrator name, modify the statement that sets the 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_start

The cleanup_start rule is a configuration rule that runs upon receipt of the TEC_Start event, which is sent during intialization of the event server. This rule sets global parameters for the cleanup rules and then sets the Cleanup timer with the 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 for more information.

Cleanup rules

rule: do_the_cleanup

The 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 periodic cleanups. When this event is received, the event cache is searched for open events that match the cleanup criteria specified in the cleanup_start rule. Any matching events are closed. The received TEC_Cleanup_event event is then dropped.

timer_rule: cleanup_old_events

The cleanup_old_events timer rule runs upon expiration of the Cleanup timer. This rule generates a TEC_Cleanup_event event, which triggers the do_the_cleanup rule. It then resets the Cleanup timer with the duration specified by the

(19)

Correlation rule set (correlation.rls)

Overview

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

Clearing events

A clearing event is an event that resolves a previous problem event. For example, an event of class Su_Failure might be cleared by Su_Success from the same host and user.

Event sequences

An event sequence is a series of events that are linked by causal

relationships. In an event sequence, each event is an effect of the previous event. For example, the upsOnBattery event (indicating that an

uninterruptible power supply is operating on battery power) might be the root cause of an event sequence that also includes the lowBattery event and finally the upsDischarged event.

Usage

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

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

Before using this rule set, you might also need to modify the

correlation_parametersaction of the correlation_configure rule to define the clearing events and event sequences you want the rules to correlate. To define a clearing event, use the create_clearing_event predicate; to define an event sequence, use the create_event_sequence predicate. (See the IBM Tivoli Enterprise

Console 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 any other active rule set.

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

Optional configuration

You can customize the correlation rule set by modifying statements in the

correlation_parametersaction of the correlation_configure rule. The following options 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 ten minutes (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 to

search the cache for events.

(20)

Note: This parameter sets an upper limit on how far back in time the search will go, but it does not guarantee that events within that time period are still available. If your event cache is too small, events might be discarded even if they are more recent than the specified time. If this happens, consider increasing the size of your event cache. (See the IBM Tivoli Enterprise

Console User’s Guide for more information.)

v Administrator name.You can specify the administrator name to use when automatically acknowledging or closing events. The default administrator name is correlation.rls. To change the administrator name, modify the statement that 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_configure

The correlation_configure rule is a configuration rule that runs upon receipt of the TEC_Start event, which is sent during initialization of the event server. This rule defines the clearing events and event sequences that are correlated by the correlation rules; it also configures the _correlation_time_window parameter, which defines the latency used for event searches. By customizing this rule, you can configure the behavior of the correlation rules. See “Usage” on page 7 for more information.

Correlation rules

rule: clearing_event

The clearing_event rule runs upon receipt of any event. If the received event has been defined as a clearing event (using the create_clearing_event predicate), any cleared events in the event cache received within the time window defined by the

_correlation_time_window parameter are closed.

rule: correlate

The correlate rule runs upon receipt of any event. If the received event has been defined as part of an event sequence, the rule uses the first_related_event predicate to search the event cache for the a related event received within the time window defined by the _correlation_time_window parameter. If the received event is found to be an effect of a previously received cause event, it is correlated with the cause event using the link_effect_to_cause predicate. The received event is then acknowledged, 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_cause predicate. The effect event is then acknowledged, because it is now known to be an effect of the newly received cause event.

(21)

Database cleanup rule set (db_cleanup.rls)

Overview

The database cleanup rule set periodically deletes old closed events from the Tivoli Enterprise Console database. This rule set uses a timer rule to peridocally generate DB_Cleanup_event events. These events can also be sent from other sources if you want to explicitly trigger a database cleanup. When DB_Cleanup_event is received, the wtdbclear command is used to delete old closed events from the event

repository, task repository, extended event attribute table, and reception log. See the IBM Tivoli Enterprise Console Command and Task Reference for more information about the wtdbclear command.

Usage

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

Optional configuration

You can customize the database cleanup rule set by modifying the timer interval that determines how frequently the database cleanup takes place. The default interval is one hour (3600 seconds). To change this interval, modify the statement in 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 database

cleanups.

Rules

Startup rule

rule: db_cleanup_start

The db_cleanup_start rule runs upon receipt of the TEC_Start event, which is sent during initialization of the event server. This rule first sets the _cleanup_timer parameter and then starts the the DB_Cleanup timer, which is used to periodically generate DB_Cleanup_event events. By customizing this rule, you can configure the duration of the cleanup timer. See “Usage” for more information.

Database cleanup rules

rule: do_the_DB_cleanup

The 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 timer rule, and it can also be generated from other sources in order to trigger a database cleanup. When this event is received, the rule uses the following command to delete 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

(22)

seconds is the value of the _cleanup_timer parameter. The received

DB_Cleanup_event event is then closed.

timer_rule: time_to_cleanup_the_database

The time_to_cleanup_the_database timer rule runs when the DB_Cleanup timer expires. This rule generates a DB_Cleanup_event event in order to trigger the do_the_DB_cleanup rule. It then resets the timer.

(23)

Dependency rule set (dependency.rls)

Overview

The dependency rule set contains rules that support the definition of dependency relationships used by the e-business rule set (ebusiness.rls). These rules process TEC_Dependency events, which are sent by the wrb –imptdp and wrb –deldp commands. See “e-business rule set (ebusiness.rls)” on page 13 for more information about dependency relationships.

Usage

The dependency rule set is already activated in the default rule base. If you make any 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 set must also be active. In order to ensure correct functioning of the e-business rules, do not make any changes to this rule set apart from the optional configuration parameters described below.

Optional configuration

The dependency rule set is preconfigured and ready to use. However, you can customize this rule set by modifying statements in the setup action of the startup configuration 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 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 file name is dependencies.pro. To specify a different file name, modify the statement that defines the

_dependency_fileparameter as follows:

_dependency_file = filename,

filename is the name of the Prolog fact file you want to use, optionally including

a relative or absolute path, and enclosed in single quotation marks.

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. This function should always be disabled before the rule set is deployed in a production environment because it can affect performance. To change this behavior, modify the statement that sets the _dependency_debug parameter as follows:

_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. You can 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 is dependency.log. To specify a different file, modify the statement that sets the

dependency_logger parameter as follows:

(24)

_dependency_logger = filename,

filename is the name of the log file you want to use, optionally including a

relative or absolute path, and enclosed in single quotation marks.

Rules

Startup and shutdown rules

rule: startup

The startup rule is a configuration rule that runs upon receipt of the TEC_Start event, which is sent during intialization of the event server. This rule first loads the auxiliary predicates used by the dependency rules and any persistent dependency relationships previously defined; it then sets global parameters for the dependency rules 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: shutdown

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

Dependency processing rule

rule: process_op

The 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 updates the dependency knowledge base accordingly (asserting or retracting a dependency fact), and then it drops the event.

(25)

e-business rule set (ebusiness.rls)

Overview

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

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

WMQ_DEPENDS_ON_WMQ

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

WAS_DEPENDS_ON_DB2

Indicates that a WebSphere Application Server resource on one host is dependent upon a DB2 resource on another host, or on the same host. For example, suppose host appserver is running WebSphere Application Server services that depend upon DB2 services on host dbserver. In this case, you would define a dependency fact indicating a WAS_DEPENDS_ON_DB2 relationship between the two hosts. If the event server receives an event indicating a problem with the DB2 services on dbserver, and later receives an event indicating a database-availability problem with the WebSphere Application Server services on appserver, it is likely that the DB2 problem is the cause of the WebSphere Application Server problem. Because the knowledge base contains a dependency fact describing this

relationship, the event server can automatically associate the two events as causally related. Similarly, the event server can identify other cause events that might affect the availability of dbserver, such as service-impact network events and

maintenance events.

WAS DB2

appserver dbserver

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

(26)

In addition, the e-business rules can optionally generate probable-cause

informational events in cases where a likely causal relationship is found but cannot be matched to a defined dependency fact. This can happen if no dependency relationship is defined for the hosts involved, or if the NetView component is not configured 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” on page 19.)

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

Effect events Cause events

e-business network maintenance

WebSphere Application Server events

DB2 events

NetView node service impact events (DB2 services) TEC_Maintenance WebSphere MQ events WebSphere MQ events NetView node service impact events (WebSphere MQ services)

The e-business events analyzed by the e-business rules are generated by the following 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 these products.

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

How events are analyzed

The primary analysis of e-business events is handled by the rules in the ″Event Association″ section of the e-business rule set. These are the rules that identify causal relationships between e-business and network events based upon the dependency relationships you define.

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

WAS_DEPENDS_ON_DB2dependency fact; if the effect event is related to WebSphere MQ 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 host upon which the e-business service depends (the host providing the required DB2 or WebSphere MQ services). The rules then search the event cache for a cause

(27)

event originating from the specified host and affecting the relevant service. There are 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 a DB2 cause event sent by IBM Tivoli Monitoring for Databases: DB2 or a

WebSphere MQ cause event sent by IBM Tivoli Monitoring for Business

Integration: WebSphere MQ. The specific class of the cause event depends upon the class of the effect event and the type of dependency. If an e-business cause event is found, the effect event is associated with it using the

link_effect_to_causepredicate.

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

v A maintenance cause event.This event indicates that the specified host has entered maintenance mode. A maintenance cause event is a TEC_Maintenance event with current_mode equal to ON and specifying a host identified by a dependency fact. Because all other events from a host in maintenance mode are typically discarded, in this case the maintenance event itself is considered the cause event. If a maintenance cause event is found, the effect event is associated with it using the link_effect_to_cause predicate. (For more information about handling 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 rules can optionally continue searching for an indication of a probable cause event. (This function is enabled or disabled by the ebusiness_hints parameter; see “Usage” on page 16 for more information.) If this function is enabled, the rules continue searching for the following categories of probable cause events (in the following order):

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 or DOWNand originating from a host identified by a dependency fact. If this event is found, it indicates that there is a network problem with the specified host, but the NetView component is not configured to generate service impact events. Instead, the rules generate an informational TEC_ITS_Not_Monitoring_eBusiness event specifying the effect event and the probable network cause event. This event indicates that NetView needs to be configured to monitor the related e-business service.

v An e-business probable cause event.An e-business probable cause event is an event originating from the type of service identified by a dependency fact, but not from a matching host. This might indicate that the correct dependency relationships have not been defined. If an e-business probable cause event is found, the rules generate an informational

TEC_PROBABLE_EVENT_ASSOCIATION event specifying the effect event and the probable cause event. This event indicates that the defined dependency relationships may need to be updated.

(28)

In some situations, an effect event might arrive before the cause event. If this happens, the rules cannot identify the causal relationship when the effect event arrives, because the cause event is not yet in the event cache. In order to handle this situation, when a potential cause event arrives, the rules repeat the

dependency analysis for any possible effect events already in the event cache.

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

Usage

The e-business rule set is already activated in the default rule base. If you make any 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 the rule_sets file (following the NetView rule set, if that rule set is active). In addition, the dependency rule set (dependency.rls) provides required support for the e-business rule set. If the e-business rule set is active, the dependency rule set must also be active.

Configuration

The e-business rule set is preconfigured and ready to use. However, you can customize 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 and TEC_ITS_Not_Monitoring_eBusiness events. These events are generated in cases where a probable cause event is found, but there is insufficient information for a causal association. (See “How events are analyzed” on page 14 for more

information.) By default, this function is enabled; if you want to change this preference, modify the statement that sets the ebusiness_hints parameter as follows:

rerecord(ebusiness_hints, ’no’),

v Debug logging.You can specify whether you want debugging information written 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 a production environment because it can affect performance. To enable or disable debugging messages, modify the statement that sets the ebusiness_debug

parameter 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 can 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 is ebusiness.log. To specify a different file, modify the statement that sets the

ebusiness_logger parameter as follows:

(29)

filename is the name of the log file you want to use, optionally including a

relative or absolute path, and enclosed in single quotation marks.

v Administrator name.You can specify the administrator name to use when the e-business rules automatically acknowledge or close events. The default

administrator name is ebusiness.rls. To change the administrator name, modify the 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 forward event searches. By default, searches are limited to ten minutes (600 seconds) backward or forward in the event cache. To change the latency, modify the statement that sets the ebusiness_latency parameter as follows:

rerecord(ebusiness_latency, seconds),

seconds is the number of seconds representing how far backward or forward you

want to search the cache for events.

Note: This parameter sets an upper limit on how far back in time the search will go, but it does not guarantee that events within that time period will still be available. If your event cache is too small, events might be discarded even if they are more recent than the specified time. If this happens, consider increasing the size of your event cache. (See the IBM Tivoli

Enterprise Console User’s Guide for more information.)

Defining dependency relationships

Before using the e-business rule set, you must define the dependency relationships that apply to the e-business services and network resources in your environment. To define these relationships, create a text file containing a series of dependency statements, each of which will be converted into a dependency fact in the knowledge base. Each dependency statement is on a separate line, and each statement 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 another

host, dependency_type is the nature of the dependency, and host_b is the fully qualified name of the host upon which host_a depends. The following example shows three dependency statements:

mq1.raleigh.ibm.com WMQ_DEPENDS_ON_WMQ mq2.raleigh.ibm.com mq2.raleigh.ibm.com WMQ_DEPENDS_ON_WMQ mq1.raleigh.ibm.com appserver.raleigh.ibm.com WAS_DEPENDS_ON_DB2 appserver.raleigh.ibm.com

These statements define the following dependency relationships (see Figure 2 on page 18):

v The first statement indicates that WebSphere MQ services on mq1.raleigh.ibm.comdepend upon WebSphere MQ services on mq2.raleigh.ibm.com.

v The second statement indicates that WebSphere MQ services on mq2.raleigh.ibm.comdepend upon WebSphere MQ services on mq1.raleigh.ibm.com.

v The third statement indicates that WebSphere Application Server services on appserver.raleigh.ibm.comdepend upon the availability of DB2 services running on the same host.

(30)

Note: Each dependency fact represents a single, unidirectional dependency relationship. Therefore, if two interconnected hosts have mutual

dependencies on one another, you must define a separate dependency fact for each direction of the relationship. This is typically the case for

WMQ_DEPENDS_ON_WMQrelationships, 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 as dependency 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 to

remove from the knowledge base.

Note: Before using wrb –imptdp or wrb –deldp, make sure the event server is running, and that the dependency rule set (dependency.rls) is activated. Dependency facts are persistent, so you do not need to reload dependency relationships after stopping and restarting the event server.

For more information about the wrb –imptdp or wrb –deldp commands, see the

IBM 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

(31)

Rules

Startup and shutdown rules

rule: startup

The startup rule is a configuration rule that runs upon receipt of the TEC_Start event, which is sent during intialization of the event server. This rule first loads the auxiliary predicates used by the e-business rules; it then sets global parameters for the 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 rule set. See “Usage” on page 16 for more information.

rule: shutdown

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

Heartbeat rules

rule: generate_heartbeat_missed

The generate_heartbeat_missed rule generates a TEC_Heartbeat_missed event when one of the following heartbeat status events is received from the IBM Tivoli Monitoring product:

v HeartBeat_Off

v HeartBeat_EndpointUnreachable v HeartBeat_DMAgentDown

v HeartBeat_ResourceModelsInError

When one of these events is received, the rule generates a TEC_Heartbeat_missed event, duplicating the attribute values from the received event. (For more

information about heartbeat status events, refer to the IBM Tivoli Monitoring documentation.)

rule: link_heartbeat_missed

The link_heartbeat_missed rule associates the TEC_Heartbeat_missed effect events generated by the generate_heartbeat_missed rule with the cause events received from the IBM Tivoli Monitoring product. The effect events are associated with the cause events using the link_effect_to_cause predicate.

Case manipulation rules

rule: lower_itm

The lower_itm rule runs upon receipt of a potential e-business cause or effect event from an e-business service. This rule converts the value of the fqhostname attribute to all lowercase letters, in order to prevent mismatches when performing

case-sensitive comparisons.

rule: lower_its

The lower_its rule runs upon receipt of a potential network cause event from the NetView component. This includes any TEC_ITS_NODE_SERVICE_IMPACT event with sub_source equal to IBM_DB2 or IBM_WebSphere_MQ. This rule converts the value of the fqhostname attribute to all lowercase letters, in order to prevent possible mismatches when performing case-sensitive comparisons.

(32)

rule: lower_tec

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

rule: lower_node

The lower_node rule runs upon receipt of potential network probable-cause events from the NetView component. This includes any TEC_ITS_NODE_STATUS event with nodestatus equal to MARGINAL or DOWN. This rule converts the value of the fqhostnameattribute to all lowercase letters, in order to prevent possible mismatches when performing case-sensitive comparisons.

Event association rules

rule: associate_wmq_wmq

The associate_wmq_wmq rule runs upon receipt of an effect event from a WebSphere MQ service and attempts to associate it with a cause event that matches a defined WMQ_DEPENDS_ON_WMQdependency relationship. The following table shows the effect events 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_QueueManagerUnavailable WebSphere_MQ_ChannelNotTransmitting WebSphere_MQ_ChannelStartupError WebSphere_MQ_ChannelThroughputProblem WebSphere_MQ_QueueFilling WebSphere_MQ_ChannelNotTransmitting WebSphere_MQ_QueueManagerUnavailable WebSphere_MQ_ChannelNotActivated WebSphere_MQ_ChannelStartupError WebSphere_MQ_QueueManagerUnavailable WebSphere_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) cause event. If no cause event is found, but informational events are enabled, the rule then attempts to find a probable cause event. See “How events are analyzed” on page 14 for more information.

rule: associate_was_db2

The associate_was_db2 rule runs upon receipt of an effect event from a WebSphere Application Server service and attempts to associate it with a cause event that matches a defined WAS_DEPENDS_ON_DB2 dependency relationship. The following table shows the effect events analyzed by this rule and the possible e-business cause events.

Table 4. Effect and cause events for the associate_was_db2 rule

Effect event Possible e-business cause events

WebSphereAS_high_DBPool_faults DB2_Down_Status DB2_High_ConnectionErrors WebSphereAS_high_DBPool_avgWaitTime DB2_High_ConnWaitingForHost DB2_High_MostRecentConnectResponse DB2_High_DB2ApplicationAgent_TotUserCpuTime DB2_High_ApplicationAgent_TotSystemCpuTime

(33)

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

Effect event Possible e-business cause events

WebSphereAS_high_Transaction_avg_response_time DB2_High_HostTimePerStatement DB2_High_NetworkTimePerStatement DB2_High_TimePerStatement DB2_High_InstanceAgents_PctAgentsWaiting DB2_High_ApplicationAgents_Workload DB2_High_InstanceAgents_AgentCreationRatio DB2_High_DB2ApplicationAgent_TotUserCpuTime DB2_High_ApplicationAgent_TotSystemCpuTime WebSphereAS_high_Transaction_timeout_ratio DB2_Down_Status DB2_High_HostTimePerStatement DB2_High_NetworkTimePerStatement DB2_High_TimePerStatement DB2_High_InstanceAgents_PctAgentsWaiting DB2_High_ApplicationAgents_Workload DB2_High_InstanceAgents_AgentCreationRatio DB2_High_DB2ApplicationAgent_TotUserCpuTime DB2_High_ApplicationAgent_TotSystemCpuTime WebSphereAS_high_DBPool_percentUsed DB2_High_PctConnectionsUsed DB2_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) cause event. If no cause event is found, but informational events are enabled, the rule then attempts to find a probable cause event. See “How events are analyzed” on page 14 for more information.

rule: redo_its_wmq

The redo_its_wmq rule handles cases where network cause events and WebSphere MQ effect events arrive out of sequence. This rule runs upon receipt of any TEC_ITS_NODE_SERVICE_IMPACT event specifying WebSphere MQ services. When this potential cause event is received, the rule uses the redo_analysis predicate to request reanalysis of possible WebSphere MQ effect events that might have arrived earlier in order to determine whether they are effects of the newly received cause event. These effect events are those that are analyzed by the associate_wmq_wmq rule.

rule: redo_its_was

The redo_its_was rule handles cases where network cause events and WebSphere Application Server effect events arrive out of sequence. This rule runs upon receipt of any TEC_ITS_NODE_SERVICE_IMPACT event specifying WebSphere

Application Server services. When this potential cause event is received, the rule uses the redo_analysis predicate to request reanalysis of possible WebSphere Application Server effect events that might have arrived earlier in order to

determine whether they are effects of the newly received cause event. These effect events are those analyzed by the associate_was_db2 rule.

rule: redo_wmq_wmq

The redo_wmq_wmq rule handles cases where WebSphere MQ cause events and WebSphere MQ effect events arrive out of sequence. This rule runs upon receipt of a 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 possible

WebSphere MQ effect events that might have arrived earlier in order to determine whether they are effects of the newly received cause event. The cause and effect events are those analyzed by the associate_wmq_wmq rule.

(34)

rule: redo_db2_was

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

(35)

Escalation rule set (escalate.rls)

Overview

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

Usage

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

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

Optional configuration

The escalation rule set is preconfigured and ready to use. By default, this rule set is configured only to trigger e-mail or pager notification for FATAL events that require escalation; this function requires that the notification rule set (notify.rls) also be configured and active. (Severities are not increased because FATAL events are already at their maximum severity.) If you want to escalate events with severities other than FATAL, you must customize the rule set by modifying the statements in the 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. To change 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 the statement that sets the _escalate_timer parameter as follows:

_escalate_timer = seconds,

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

checks.

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

References

Related documents

Insurers often use the following characteristics in pricing: o Motor vehicle record (driver safety record).. o

Az olyan országok, mint Nagy-Britan- nia és az Egyesült Államok pedig azért lettek gazdag országok, mert polgáraik megbuktatták a hatalmat gyakorló elitet,

If you want the court to make an order dividing property between you and your former partner, or to make an order that your former partner pay you maintenance, you must apply to the

Preferred medication that all drugs tricare formulary for certain common vaccines may also a provider will cover the tricare plans, called the previous approval before your

Acetyl phosphate (AcP), an intermediate of the acetate fermentation pathway in E. coli, is one such metabolite that has been shown to non-enzymatically acetylate hundreds of

All the Turing Machines will appear in this list in the form of Description Numbers, and from the Description Number we can get the Standard Description, and then we can feed that

Exposure to in-school sex education is identified and duration- hazard models are estimated to assess its effects on initiation of sexual activity and use of contraception methods,

Scaling of deduplication processing with data size is achieved us- ing a RAM frugal chunk hash index and data partitioning – so that memory, CPU, and disk seek resources