patrol km for event management - bmc software · patrol® km ® for event management 3 customer...

PATROL® KM ® for Event Management

User Guide

Supporting

PATROL KM for Event Management 2.7PATROL Configuration Manager 1.6

January 2005

Contacting BMC Software

You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information about the company, its products, corporate offices, special events, and career opportunities.

United States and Canada

Address BMC SOFTWARE INC2101 CITYWEST BLVDHOUSTON TX 77042-2827 USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000

Copyright March 8, 2005 BMC Software, Inc., as an unpublished work. All rights reserved.

BMC Software, the BMC Software logos, and all other BMC Software product or service names are registered trademarks or trademarks of BMC Software, Inc.

IBM is a registered trademark of International Business Machines Corporation.

DB2 is a registered trademark of International Business Machines Corporation.

Oracle is a registered trademark, and the Oracle product names are registered trademarks or trademarks of Oracle Corporation.

All other trademarks belong to their respective companies.

BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted rights notices included in this documentation.

Restricted rights legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC SOFTWARE INC, 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA. Any contract notices should be sent to this address.

http://www.bmc.com

PATROL® KM ® for Event Management 3

Customer support

You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer Support by telephone or e-mail. To expedite your inquiry, please see “Before Contacting BMC Software.”

Support website

You can obtain technical support from BMC Software 24 hours a day, 7 days a week at http://www.bmc.com/support_home. From this website, you can

■ read overviews about support services and programs that BMC Software offers■ find the most current information about BMC Software products■ search a database for problems similar to yours and possible solutions■ order or download product documentation■ report a problem or ask a question■ subscribe to receive e-mail notices when new product versions are released■ find worldwide BMC Software support center locations and contact information, including e-mail addresses, fax

numbers, and telephone numbers

Support by telephone or e-mail

In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or send an e-mail message to [email protected]. Outside the United States and Canada, contact your local support center for assistance.

Before contacting BMC Software

Before you contact BMC Software, have the following information available so that Customer Support can begin working on your problem immediately:

■ product information

— product name— product version (release number)— license number and password (trial or permanent)

■ operating system and environment information

— machine type— operating system type, version, and service pack or other maintenance level such as PUT or PTF— system hardware configuration— serial numbers— related software (database, application, and communication) including type, version, and service pack or

maintenance level

■ sequence of events leading to the problem

■ commands and options that you used

■ messages received (and the time and date that you received them)

— product error messages— messages from the operating system, such as file system full— messages from related software

http://www.bmc.com/support_home

mailto:[email protected]

4 PATROL Knowledge Module for Event Management User Guide

ContentsChapter 1 Product Components and Capabilities 15

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Typical Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Rules Stored as Pconfig Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Sending Notification: Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Sending Alerts to an Enterprise Console: Process Flow . . . . . . . . . . . . . . . . . . . . . 20Sending Pages using AlarmPoint: Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Using the PATROL Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22PATROL Configuration Manager Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Usage Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Tasks that Must be Completed Using PATROL KM for Event Management . . . 22

Application Classes and Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Application Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Application InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Chapter 2 Installing and Migrating PATROL KM for Event Management 25

Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Virtual Machine Support Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Preparing for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Backing up the Notification Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Checking for Product Patches or Fixes Before Installing. . . . . . . . . . . . . . . . . . . . . 30Determining How to Install Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Installation Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Determining Where to Install the PATROL Agent. . . . . . . . . . . . . . . . . . . . . . . . . . 32Determining Where to Install KMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

PATROL Security Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Checking Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Assessing and Implementing a Different Security Level . . . . . . . . . . . . . . . . . . . . 34

Typical and Custom Installation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Installing into a PATROL 3.3.x or 3.4.x Unix Environment . . . . . . . . . . . . . . . . . . 36

First-Time Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Installing For the First Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Installing on AS/400 (iSeries) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Upgrading from an Earlier Version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5

Remove Customized KM Files From the PATROL_CACHE . . . . . . . . . . . . . . . . . 43Remove Existing Menu Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Considerations for Using Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Browser Version Required for Viewing PATROL Console for Unix Help . . . . . . 44Additional Considerations for Using Online Help for Unix . . . . . . . . . . . . . . . . . . 44

Uninstalling PATROL KM for Event Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Determining the Version of the Installation Utility . . . . . . . . . . . . . . . . . . . . . . . . . 47Uninstalling PATROL KM for Event Management on Windows . . . . . . . . . . . . . 47

Chapter 3 Using the PATROL KM for Event Management 49

Preparing to Use the PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . 51Loading and Preloading KMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Determining Which KMs to Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51KM Files Preloaded on Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Loading and Unloading KMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Loading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Verifying that PATROL KM for Event Management KM is Loaded . . . . . . . . . . . 55Unloading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Configuration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Defining Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Defining Notification Targets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Defining Availability Monitors and Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Deciding Where to Place Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Configuring Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Recommended Configuration Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Using Notification Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Testing Notification Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Configuring Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Configuring Remote Agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Configuring Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Rewording Notification Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Setting Notification Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Testing Notification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Disabling Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Configuring Availability Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Configuring an Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Configuring a Backup Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Configuring the Availability Monitor Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Specifying an Availability Monitoring Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Changing the Ping Command Used for Availability Monitoring . . . . . . . . . . . . . 93

Integrating with AlarmPoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94AlarmPoint Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Installing and Configuring AlarmPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Installing the AlarmPoint Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Configuring the AlarmPoint Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Testing the Java Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Using Action Scripts for AlarmPoint 5.2.01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98


Configuring Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Testing Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Managing Parameter Thresholds and Poll Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Benefits of Using the PATROL KM for Event Management. . . . . . . . . . . . . . . . . 104Setting Collector Poll times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Using Wildcards to Represent PATROL Instance Names. . . . . . . . . . . . . . . . . . . 107Activating and Deactivating Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Applying Thresholds and Poll Time Changes to the Agent . . . . . . . . . . . . . . . . . 111Disabling the use of PATROL KM for Event Management Thresholds and Poll

Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Specifying What to Monitor or Exclude from Monitoring . . . . . . . . . . . . . . . . . . . . . 112

Selecting Application Instances to Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Excluding Application Instances from Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 114

Configuring Blackout Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115About Notification Blackout Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Configuring Notification Blackouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Configuring Availability Blackouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Configuring Recovery Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120About Recovery Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Enabling PATROL KM for Event Management Recovery Actions . . . . . . . . . . . 121Specifying a Recovery Action Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Specifying a Recovery Action Command Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Using PSL Recovery Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Chapter 4 Usage Scenarios 127

Sending E-mail Notification When Disk Space is Low . . . . . . . . . . . . . . . . . . . . . . . . 128Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Selecting a Mail Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Loading the PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . . . . 130Defining the Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Configuring the Remote Agent NT1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Specifying an E-mail Target for Low Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . 135Rewording the Notification Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Testing Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Sending E-mail Notification for CPU Usage that Includes Parameter Annotations 140Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Overview of Annotated Data Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Enabling Recovery Actions and Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Creating Recovery Action Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Creating Notification Command Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Testing Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Configuring a Recovery Action that Runs Under a Specified Account. . . . . . . . . . . 144Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Testing Recovery Action Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Enabling Recovery Actions for ArchFreeSpace on Agent Computer . . . . . . . . . 146Defining the Recovery Action Type for Agent Computer . . . . . . . . . . . . . . . . . . 146

7

Storing the Encrypted Password as a Pconfig Variable . . . . . . . . . . . . . . . . . . . . . 147Configuring the PSL Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Summary of Rules Created. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Testing the Recovery Action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Chapter 5 Rules and Configuration Variables 151

PATROL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Example: PATROL Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Example: Rule Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Example: PATROL KM for Event Management E-mail Rule . . . . . . . . . . . . . . . . 154

NOTIFY_EVENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156How the NOTIFY_EVENT and REMOTE_NOTIFY_EVENT are Triggered . . . 156Event Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Order of Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Empty Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Using the Variable userdefined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Event Size Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157NOTIFY_EVENT Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Alert Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161arsAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161alertSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162allowOverrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163loginDeniedIgnoredUsers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164useEnvOnlyForCmds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164allowInfoRecoveryActions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165spoolDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165setParameterValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Local Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166alertResend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167alertLocalCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167arsCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168arsCmdType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168alertResetOnInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Remote Alert Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169NOTIFICATION_SERVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170RemoteAgentCommSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Notification Target Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171emailTargets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171pagerTargets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172customTargets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173ttTargets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Blackout Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174blackoutPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174__OVERRIDE__ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Notification Server Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175nsRemoteTargetSetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Custom Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176msgText . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176msgBody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177


CustomId1 and CustomId2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178allowOperator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180appClassSettingsStatusFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180disableNotifyAnnotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181maxEventsToReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182snmpSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182snmpOid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Primary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Blackout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183pingCmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184pingOkString . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184pingPacketSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185pingAttempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185pingArgs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185checkerAccount.defaultAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Parameter Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186THRESHOLDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188paramSettingsStatusFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188processWildcards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Instance Filtering Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190FilterList Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190FilterType Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Chapter 6 Parameters 191

Parameter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Parameter Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Chapter 7 Troubleshooting PATROL KM for Event Management 197

Configuration Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Cannot Send E-mail Notifications to Multiple Targets . . . . . . . . . . . . . . . . . . . . . 198Parameters are Unavailable or are Not Being Updated. . . . . . . . . . . . . . . . . . . . . 200Too Many E-mail Alerts Are Being Generated . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Parameters Show a Negative Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Parameter Annotations Show Incorrect Targets or Other Errors . . . . . . . . . . . . . 203AgentLoginDenied Parameter is in Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203The Availability Monitor is Not Pinging Frequently Enough . . . . . . . . . . . . . . . 205NOTIFY_EVENTS not Generated when Parameter is in Alarm . . . . . . . . . . . . . 205Parameters Setting Lost After Agent Restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Notification Message not Sent from OpenVMS Server . . . . . . . . . . . . . . . . . . . . . 207AS_AVAILABILITY Application Not Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . 207When Using event_trigger2() Statements, Notifications Sent to Wrong Target 207

Gathering Diagnostic Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Where to Find Diagnostic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

9

Installation Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Determining PATROL KM for Event Management Version Number. . . . . . . . . 209

Appendix A Accessing Menu Commands, InfoBoxes, and Online Help 211

Accessing KM Commands and InfoBoxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Accessing Online Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Index 215


FiguresTypical PATROL KM for Event Management Architecture . . . . . . . . . . . . . . . . . . . . . 17Select Products and Components to Install - Typical Install . . . . . . . . . . . . . . . . . . . . 39Quick Config - Notification Server Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Notification Server Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Primary Notification Server Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Selecting / to Represent all PATROL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Set Event Management Alert Variables/Rules Dialog Box . . . . . . . . . . . . . . . . . . . . . 81Selecting Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Selecting Application Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Selecting Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Set Event Management Alert Variables/Rules Dialog Box . . . . . . . . . . . . . . . . . . . . . 83What If Results Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Availability Monitor Add Target Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Choose Primary Monitor Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Rules to Apply to the Availability Checker Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Java Client Status Displayed in Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97SET EVENT MANAGEMENT VARIABLE:arsAction Dialog Box . . . . . . . . . . . . . . 101SET EVENT MANAGEMENT ALERT VARIABLES/RULES Dialog Box . . . . . . . . 102Configure Thresholds Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Choose the target classes Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Set Event Management Blackout Variables/Rules Dialog Box . . . . . . . . . . . . . . . . . 117Set Event Management Blackout Variables/Rules Dialog Box . . . . . . . . . . . . . . . . . 119Availability Monitor Add Target Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128QUICK CONFIG - NOTIFICATION SERVER Dialog Box . . . . . . . . . . . . . . . . . . . . . 131NOTIFICATION SERVER SETTINGS Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132EVENT MANAGEMENT ALERT VARIABLE:emailTargetsRemoteALARM Dialog

Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Message Rewording Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137SET EVENT MANAGEMENT VARIABLE: alertLocalCommand dialog box . . . . . 200

11

TablesE-mail Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Sending Alerts to Enterprise Console Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Sending Pages using AlarmPoint Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Application Classes and KM File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23AS_EVENTSPRING InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24AS_AVAILABILITY InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24System Requirements for Installing and Using PATROL KM for Event Management

26System Role Packages Available for Product Components . . . . . . . . . . . . . . . . . . . . . 38EVENT_MANAGEMENT.kml File and Associated KM Files) . . . . . . . . . . . . . . . . . . 53Notification Target Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Recommended Rule Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Recommended Configuration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Notification Script Location on Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Requirements for Using Scripts on Unix Notification Server . . . . . . . . . . . . . . . . . . . . 65Notification Script Location on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Requirements for Notification Server When Using Windows e-mail Clients . . . . . . 66Editing Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Notification Script Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Quick Config - Notification Server Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Notification Server Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75REMOTE AGENT COMMUNICATION SETTINGS dialog box . . . . . . . . . . . . . . . . . 79Message Length Limitations by Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Availability Target Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Threshold Setting Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Wildcard Usage in Threshold Rules: Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Blackout Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118PATROL KM for Event Management Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Sending E-mail Notification for Low Disk Space: Configuration Overview . . . . . . 129Sending E-mail Notification for Low Disk Space: Configuration Overview . . . . . . 145Rules Created: Oracle Recovery Action Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149PATROL Objects Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Example: PATROL Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Example: Rule Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154PATROL KM for Event Management Variable Definition . . . . . . . . . . . . . . . . . . . . . 155NOTIFY_EVENT Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Notification Server Message Replacement Variables . . . . . . . . . . . . . . . . . . . . . . . . . 160Notification Server Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161arsAction Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161alertSystem Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

13

Notification System Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163allowOverrides Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163LoginDeniedIgnoredUsers Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164useEnvOnlyForCmds Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164useEnvOnlyForCmds Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165SpoolDirectory Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165SetParameterValue Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166alertResend Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167alertLocalCommand Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167arsCommand Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168arsCmdType Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169alertResetOnInit Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Remote Alert Settings: Configure Notification Servers Configuration Variable . . . 170Remote Alert Settings: Configure Notification Servers Configuration Variable . . . 170Remote Alert Settings: Remote Communication Settings Configuration Variable . 170Notification Targets: Email Target Configuration Variable . . . . . . . . . . . . . . . . . . . . 172Notification Targets: Pager Target Configuration Variable . . . . . . . . . . . . . . . . . . . . 172Notification Targets: Custom Target Configuration Variable . . . . . . . . . . . . . . . . . . 173Notification Targets: TT Targets Configuration Variable . . . . . . . . . . . . . . . . . . . . . . 173Blackout Periods Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Overrides Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Notification Server Settings: Remote Target Setting Configuration Variable . . . . . 175msgText Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176msgBody Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Custom Configuration Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178allowOperator Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179active Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180appClassSettingsStatusFlag Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180disableNotifyAnnotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181disableNotifyAnnotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Add Target Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Add Target: Updated Flag Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Primary Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Blackout Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184PingCmd Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184pingOKString Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184pingPacketSize Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185pingAttempts Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185pingArgs Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Checker Account Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Parameter Settings: Thresholds Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Understanding the THRESHOLDS Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Parameter Settings: poll times Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Parameter Settings: Status Flags Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Parameter Settings: poll times Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Filter List Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Filter Type Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190PATROL KM for Event Management Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192PATROL KM for Event Management Parameter Defaults . . . . . . . . . . . . . . . . . . . . . 194


C h a p t e r 1
1 Product Components and Capabilities
This chapter provides an overview of the PATROL Knowledge Module for Event Management (also referred to as PATROL KM for Event Management).

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Typical Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Rules Stored as Pconfig Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Sending Notification: Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Sending Alerts to an Enterprise Console: Process Flow . . . . . . . . . . . . . . . . . . . . . 20Sending Pages using AlarmPoint: Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Using the PATROL Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22PATROL Configuration Manager Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Usage Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Tasks that Must be Completed Using PATROL KM for Event Management . . . 22

Application Classes and Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Application Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Application InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Chapter 1 15

Features

FeaturesPATROL KM for Event Management provides event notification, message rewording, and centralized alert management features. With the PATROL KM for Event Management, you can:

■ configure notification (e-mail, paging, trouble-ticket, or custom) for PATROL alerts

■ configure PATROL to send notifications to an enterprise console

■ configure recovery actions for PATROL alerts

■ reword notification messages and customize message content

■ configure PATROL to monitor the availability of hosts

■ manage PATROL parameter thresholds and polling schedules

■ configure blackout periods for notification and for availability monitoring

■ integrate with any command line e-mail client, paging solution, compiled executable, or script. Sample scripts are provided.

■ integrate with AlarmPoint enterprise notification software using provided scripts

ArchitectureThe PATROL KM for Event Management architecture consists of monitored hosts (remote agents) and notification servers. Notification servers collect and process events from monitored systems according to notification rules that you define. Notification rules specify:

■ who gets notified■ when they get notified■ the content of the notification message

Both the monitored hosts and the notification servers require a PATROL Agent and the PATROL KM for Event Management. Figure 1 on page 17 shows an PATROL KM for Event Management environment with several monitored hosts and two notifications servers (a primary and a backup).


Architecture

Typical Configuration

In the typical configuration, monitored hosts forward events to a primary notification server. The backup notification server is used only when the primary notification server is unavailable. Failover is automatic. If the primary and the backup notification servers are unavailable, the monitored host queues its events. When communication is restored, the monitored host forwards queued events to the notification servers.

Figure 1 Typical PATROL KM for Event Management Architecture

Notification Servers

BMC Software recommends the use of notification servers. The PATROL KM for Event Management architecture does not require a notification server to perform notifications. Any monitored host running the PATROL KM for Event Management can be configured to perform its own notifications, event filtering, and alert control. However, there are advantages to using a notification server. For more information, see “Why use a Notification Server?” on page 58.

Rules Stored as Pconfig Variables

PATROL KM for Event Management rules are stored in pconfig variables, not in the KM. Pconfig variables override KM settings. Thus, if you upgrade a KM, you don’t need to reconfigure the rules. The pconfig variable settings are retained.

Primary BackupNotification Server 1 Notification Server 2

Agent 1 Agent 2 Agent 3

Chapter 1 17

Notification Process

Notification Process The following diagrams show how notification occurs in the following configuration:

■ e-mail notification using a notification server■ alert notification using the PATROL Enterprise Manager (PEM)■ paging notification using AlarmPoint

The PATROL KM for Event Management rules that apply at each step are shown. For detailed rule descriptions, see Chapter 5, “Rules and Configuration Variables”.



Sending Notification: Process Flow

Table 1 shows how a notification is processed by the PATROL KM for Event Management when the notification server sends an e-mail notification. The same process applies to paging, trouble-ticket, or custom notification.

Table 1 E-mail Notification Process

Step Rule or Variable

1. Alert occurs on remote agent - parameter exceeds threshold and enters WARN/ALARM state, generating PATROL standard event 11 or 39.

NA

2. Recovery action initiated (if configured) arsActionarsCommandarsCmdType

3. The remote agent triggers a PATROL NOTIFY_EVENT (if arsAction = 4 or 6)

arsAction

4. CustomID values are set (if configured) customId1customId2

5. Notification message reworded (if configured)

msgTextmsgBody

6. PATROL determines if a blackout period applies. If so, NOTIFY_EVENT is not sent to the notification server.

blackoutPeriod

7. The alert is queued. alertResetOnInitalertResend

8. Determine whether notification is local or remote. If local, notification sent from remote agent. If remote, notification sent from notification server.

alertSystem

9. Determine the notification targets. emailTargets

10. Remote agent NotifiedEvent parameter is annotated with alert information.

NA

11. A REMOTE_NOTIFY_EVENT is sent to notification server (if arsAction = 4 or 6)

NA

12. The notification server parses REMOTE_NOTIFY_EVENT event details, which contains the same information as the original NOTIFY_EVENT.

NA

13. Repeat steps 4 through 10 on the notification server (except step 7).

Multiple. See steps 4 through 10.

14. The notification server executes the script to send e-mail message to targets.

emailTargetsalertLocalCommand

Chapter 1 19


Sending Alerts to an Enterprise Console: Process Flow

Table 2 shows how an alert processed by the PATROL KM for Event Management is sent to the PATROL Enterprise Manager (PEM). The PATROL KM for Event Management rules associated with each step are shown.

Table 2 Sending Alerts to Enterprise Console Process

Step Rule

1. Alert occurs on remote agent (parameter exceeds defined threshold and enters WARN or ALARM state, generating PATROL event 11 or 39)

NA

2. Notification processing occurs on the remote agent as previously discussed in Table 1 on page 19.

The message rewording (msgText) must be done on the remote agent so that when the PATROL Event Translator (PET) pulls the event, the event contains the host specific information.

arsActionarsCommandmsgTextmsgBodyblackoutPeriodalertResetOnInitalertResendalertSystem

3. The NOTIFY_EVENT is sent to the notification server.

NA

4. The notification server process the REMOTE_NOTIFY_EVENT as previously discussed in Table 1 on page 19.

arsActionarsCommandblackoutPeriodalertSystem

5. PATROL Event Translator (PET) pulls REMOTE_NOTIFY_EVENT from the notification server

NA

6. The PET processes the REMOTE_NOTIFY_EVENT and sends it to the PATROL Enterprise Manager.

You can also send events to third-party enterprise consoles, such as Tivoli.

NA

7. The event is received by the PATROL Enterprise Manager.

NA



Sending Pages using AlarmPoint: Process Flow

The following diagram shows how a page is processed by the PATROL KM for Event Management. This process assumes the use of the enterprise notification software AlarmPoint. However, you can use any third-party paging software that has a command-line interface. The PATROL KM for Event Management rules associated with each step are shown

Table 3 Sending Pages using AlarmPoint Process

Step Rule

1. Alert occurs on remote agent (parameter exceeds defined threshold and enters WARN or ALARM state, generating PATROL standard event 11 or 39)

NA

2. Notification processing occurs on the remote agent as previously discussed in Table 1 on page 19.

arsActionarsCommandmsgTextblackoutPeriodalertResetOnInitalertResendalertSystemcustomTargets

3. The NOTIFY_EVENT is sent to the notification server.

4. The notification server process the REMOTE_NOTIFY_EVENT as previously discussed in Table 1 on page 19.

arsActionarsCommandblackoutPeriodalertSystemcustomTargets

5. The notification server executes the script that calls the AlarmPoint Java client.

6. The AlarmPoint java client sends the paging request to the AlarmPoint server.

7. The AlarmPoint server processes the paging request and sends the page request to the paging device. The paging device could be a paging server, the internet, or whatever your enterprise is using for paging.

8. The paging device sends the page to the defined target.

Chapter 1 21

Using the PATROL Configuration Manager

Using the PATROL Configuration ManagerThe PATROL KM for Event Management is designed to be used with the PATROL Configuration Manager, which allows you to manage and globally deploy agent configuration settings.

PATROL Configuration Manager Tasks

Usage Examples

For a brief example of how to use the PATROL Configuration Manager to copy settings, see “Sending E-mail Notification When Disk Space is Low” on page 128.

For detailed instructions on using PATROL Configuration Manager, see the PATROL Configuration Manager User Guide.

Tasks that Must be Completed Using PATROL KM for Event Management

Tasks that you must complete using the PATROL KM for Event Management, and cannot be completed using the PATROL Configuration Manager, are also noted. These tasks are listed below.

■ “Configuring Notification Servers” on page 71■ “Configuring Remote Agents” on page 73■ “Specifying an Availability Monitoring Account” on page 92

You can accomplish many of the tasks described in this manual using either the PATROL KM for Event Management or the PATROL Configuration Manager. In this manual, only the PATROL KM for Event Management method is described. However, for some tasks, the PATROL Configuration Manager method is more efficient. For example, configuring multiple agents at one time. Rather than configure each agent individually, you can configure one agent and then use the PATROL Configuration Manager to copy the agent settings to the other agents. Tasks such as these that are easier to accomplish with the PATROL Configuration Manager are denoted by an icon in the margin (shown at left).


Application Classes and Instances

Application Classes and InstancesThe PATROL KM for Event Management contains two application classes:

■ AS_EVENTSPRING■ AS_AVAILABILITY

Table 4 describes the PATROL KM for Event Management application classes, icons and KM files.

Application Class Hierarchy

The AS_EVENTSPRING application class icon resides at the application level beneath the computer icon. The AS_EVENTSPRING application class has only a single instance which is Event Management.

The AS_AVAILABILITY icon represents the Availability application class and resides at the application level beneath the computer icon. All monitored hosts appear beneath the Availability container and are accessed by double-clicking the AS_AVAILABILITY icon.

Table 4 Application Classes and KM File

Application Class KM File Description

AS_EVENTSPRING.km menu commands, parameters, and InfoBox items for managing and reporting on events managed by the KM

AS_AVAILABILITY.km instances, menu commands, parameters, and InfoBox items for monitored hosts and agents

NOTE The AS_AVAILABILITY application class icon is not displayed in the PATROL Console until availability targets are added.

Chapter 1 23

Application Classes and Instances

Application InfoBox Items

The status of an application instance can be reviewed by accessing the application instance InfoBox. To view an InfoBox, use the following procedure.

To View the InfoBox on the PATROL Console for Unix

1 Double click the application instance icon under the computer icon.

2 Using the middle mouse button, click the instance icon.

To View the InfoBox on the PATROL Console for Windows

1 Double click the application instance icon under the computer icon.

2 Right-click the instance icon to display a pop-up menu.

3 Choose InfoBox.

Table 5 shows the InfoBox items for the AS_EVENTSPRING application class.

Table 6 shows the InfoBox items for the AS_AVAILABILITY application instances.

Table 5 AS_EVENTSPRING InfoBox Items

Item Description

KM Version the version of the PATROL KM for Event Management

Spool Directory

directory used to store output files generated by parameter reports and recovery actions executed by the PATROL KM for Event Management

Table 6 AS_AVAILABILITY InfoBox Items

Item Description

Primary Monitor agent with primary responsibility for performing availability monitoring

Ping Command command used to perform ping checks

Ping Host (ICMP)? whether the host is being pinged using the ICMP protocol

Ping PATROLAgent?

whether the PATROL Agent is being monitored for availability

Ping SNMP Agent? whether the SNMP agent is being monitoring for availability

Blacked Out? indicates whether the selected instance is currently being blacked out

KM Version the version of the PATROL KM for Event Management


C h a p t e r 2
2 Installing and Migrating PATROL KM for Event Management
This chapter provides the information that you need to install PATROL KM for Event Management. For additional information about the PATROL installation process, see the PATROL Installation Reference Manual or the PATROL for Microsoft Windows Servers Getting Started. The following topics are discussed in this chapter:

Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Virtual Machine Support Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Preparing for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Backing up the Notification Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Checking for Product Patches or Fixes Before Installing. . . . . . . . . . . . . . . . . . . . . 30Determining How to Install Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Installation Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Determining Where to Install the PATROL Agent. . . . . . . . . . . . . . . . . . . . . . . . . . 32Determining Where to Install KMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

PATROL Security Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Checking Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Assessing and Implementing a Different Security Level . . . . . . . . . . . . . . . . . . . . 34

Typical and Custom Installation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Installing into a PATROL 3.3.x or 3.4.x Unix Environment . . . . . . . . . . . . . . . . . . 36

First-Time Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Installing For the First Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Installing on AS/400 (iSeries) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Upgrading from an Earlier Version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Remove Customized KM Files From the PATROL_CACHE . . . . . . . . . . . . . . . . . 43Remove Existing Menu Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Considerations for Using Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Browser Version Required for Viewing PATROL Console for Unix Help . . . . . . 44Additional Considerations for Using Online Help for Unix. . . . . . . . . . . . . . . . . . 44

Uninstalling PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Determining the Version of the Installation Utility . . . . . . . . . . . . . . . . . . . . . . . . . 47Uninstalling PATROL KM for Event Management on Windows . . . . . . . . . . . . . 47

Chapter 2 25

Installation Overview

Installation OverviewThis chapter contains instructions for installing PATROL KM for Event Management. For additional installation instructions, see the following documents:

System Requirements

Before installing the PATROL KM for Event Management, verify

■ the target computer meets the system requirements noted in Table 7 on page 26, including supported OS platforms and PATROL product versions.

■ the account that you use to install the product has sufficient privileges

Information Document

You are installing the PATROL KM for Event Management along with many other PATROL components and you need information about migrating customizations or using the Distribution Server (DS).

■ PATROL for Microsoft Windows Servers Getting Started

■ PATROL for Unix Getting Started ■ PATROL for OpenVMS Installation Guide■ PATROL for AS/400 Getting Started

You need more technical details about how to use the installation program.

PATROL Installation Reference Manual

You need more information on distributing the PATROL KM for Event Management or other PATROL components using the Distribution Server.

Distribution Server Getting Started Guide

NOTE For a current list of the supported operating systems, see the release notes for the PATROL solution. For example, the PATROL for Microsoft Windows Servers Release Notes.

Table 7 System Requirements for Installing and Using PATROL KM for Event Management (Part 1 of 2)

Resource Requirements Comments

operating systems

For a current list of the supported operating systems, see the release notes for the PATROL solution. For example, the PATROL for Microsoft Windows Servers Release Notes.

PATROL products

For a current list of the supported PATROL products, see the release notes for the PATROL solution. For example, the PATROL for Microsoft Windows Servers Release Notes.



Accounts

This section describes how to set up a PATROL installation account for Windows and Unix platforms.

Windows Environment

PATROL requires a dedicated user account, known as the PATROL default account, in the Windows environment. The PATROL default account must be created before you install PATROL. The PATROL default account can be either a local or a domain account:

security levels For information on security, see “PATROL Security Levels” on page 34.

The PATROL Security Level is set during the installation of the PATROL infrastructure components. If your product contains the PATROL Agent, you have an opportunity to select the security level. Make sure that the level that you select/accept is compatible with the rest of your enterprise’s PATROL installation.

On iSeries, only security levels 0 and 1 are supported.

license You must have a valid demonstration license (typically good for 30 days) or a permanent license to run your PATROL products. If you do not have a permanent license, contact your BMC Software sales representative or the BMC Software Contract Administration department.

ports If you are installing an agent or console with PATROL KM for Event Management, you must specify the port number to connect to all the agent computers.

The default port number is 3181 for agents.

(Unix only)browser to support online Help for PATROL for Unix Console

Use Netscape Navigator version 3.01–4.78 to use online Help with PATROL for Unix.

“Browser Version Required for Viewing PATROL Console for Unix Help” on page 44

browser This product uses Common Installer 7.5.20, which requires a browser. For a list of supported browser, see the PATROL Installation Reference Manual.

Table 7 System Requirements for Installing and Using PATROL KM for Event Management (Part 2 of 2)

Resource Requirements Comments

Chapter 2 27


■ Stand-alone workgroup servers must use a local user account as a PATROL default account.

■ Servers that are trusted members of a domain may use either a local or domain account.

■ PATROL default accounts on domain controllers should be only domain accounts.

Administrative Rights

BMC Software recommends that you make the PATROL default account a member of the local Administrators group of the computer where the agent will reside. On a domain controller, BMC Software recommends that you make the account a member of the domain Administrators group. However, you can choose to remove the PATROL default account from the Administrators group. If you do so, the PATROL Agent may not be able to perform all of its administrative tasks. For example, the PATROL Agent may not be able to execute recovery actions or perform other activities that requires administrative rights on the monitored machine.

Creating a Separate Account

Although you can use an existing Windows user account, BMC Software recommends that you create a separate Windows user account for PATROL.

Console Connection Accounts

BMC Software recommends that you create a separate account, in addition to the PATROL default account, for PATROL console operators who don’t need administrative privileges. Operators can use this account to connect the console to the agent. To configure KMs from the console, however, you need to give the console connection account administrative rights.

Unix Environments

BMC Software recommends that if you require a Unix account, the account that you create should meet the following conditions:

WARNING Do not use a built-in Windows domain or local Administrator account as the PATROL default account. Such account usage causes files created by PATROL to be owned by the Administrator, which could result in security or file access problems.



■ The account .login, .profile, .cshrc, and .kshrc files should contain as little user customization as possible. Specifically, be sure that the account has no aliases and that no commands in these files can change the unmask setting. The recommended umask setting for the installation account is 022. In addition, verify that the prompt is set to the default.

■ Do not use the root account to install PATROL products because this may create security risks.

■ Ensure that the account has permission to create directories in the directory where you will install PATROL products.

■ Ensure that the computers on which you want to install PATROL have ftp and telnet enabled.

PATROL configuration requires permissions usually reserved for the system administrator. These permissions include access to a root account on the computer where you want to install PATROL.

BMC Software recommends that you install PATROL on local partitions, not on NFS-mounted partitions. If you do install PATROL on NFS-mounted partitions, the root account must have been granted root access permissions on the NFS server.

The account that you use to install PATROL must have permission to write the installation logs to the $HOME and /tmp directories on the computer where you are installing products.

Your PATROL product may have other restrictions with regard to the logon accounts and the default PATROL account. Check with your developers for text that more fully describes the logon and PATROL account requirements for your product. Many products require, for example, that the default PATROL account have the same rights as the third-party product that your KM monitors.

Virtual Machine Support Limitation

VMware provides technology that creates virtual infrastructures by providing a layer of abstraction between the computing, storage, and networking hardware, and the software that runs on it. This technology enables customers to run additional operating systems in multiple windows called virtual machines.

BMC Software does not anticipate problems with the PATROL product families in virtual infrastructure implementations, but these products have not been specifically tested in this scenario. Therefore, BMC Software will provide support only for problems that are reproducible without these complementary technologies.

Chapter 2 29

Preparing for Installation

Preparing for InstallationBMC Software recommends that you first install PATROL KM for Event Management on a limited number of development or test machines, then configure and test PATROL KM for Event Management before installing it onto production machines.

Before you install, you must

■ back up the notification script, if upgrading (see page 30)■ check for product patches (see page 30)■ determine how to install products (see page 31)■ ensure you are using the appropriate version of the installation utility (see page 31)■ understand where to install the PATROL Agent and KMs (see page 32)■ choose between Typical and Custom installation options (see page 35)■ understand PATROL security options (page 34)

Backing up the Notification Script

If you are upgrading, make sure you have copied your notification script to a directory outside of the installation directory. This action prevents the script from being overwritten during a new install or upgrade.

Checking for Product Patches or Fixes Before Installing

Product fixes or patches are often available through the BMC Software Web site. Patches correct problems that are found after a product is released. BMC Software recommends that you check the PATROL for Microsoft Windows Servers product page on the BMC Software Customer Support Web site to determine whether a patch is available before you begin installing a product.



Determining How to Install Products

You can install products on the computer on which you are running the installation utility (local installation), or you can create an installable image of products so that you can install them at a later time using the Distribution Server (remote installation functionality). An installable image is a fully configured product image that you can use to install products to multiple computers. With an installable image, you can create one product image with one pass through the installation utility and then use that image to install to remote computers in your environment.

Local Installation

If you install locally, you must install PATROL KM for Event Management and a PATROL Agent on each computer that you want to monitor, and PATROL KM for Event Management and a PATROL Console for Windows or Unix on each computer from which you want to view results. If you install locally in a PATROL 7.x environment, you must install PATROL KM for Event Management on the computer that hosts the PATROL Console Server.

Details for installing products locally are contained in this chapter.

Remote Installation

If you create an installable image, the product configuration information that you enter, such as the BMC Software products installation directory, account names, passwords, PATROL Agent port number, and security options, must be the same for all computers on which the image is to be installed. To specify different settings for different computers, you must either create a separate image for each set of values that you want to implement or edit the variables in the image’s control file by using the ctltool.

For more information about creating, distributing, and installing installable images, and about using the ctltool, see the PATROL Installation Reference Manual.

Installation Utility

The installation instructions contained in this book pertain to version 7.5.20 of the installation utility. This version of the installation utility might be different from the version included on another product CD or from a version that you downloaded from the BMC Software Electronic Product Download (EPD) site. If you use a version of the installation utility other than version 7.5.20, the instructions in this book may not accurately describe what you see on your screen.

Chapter 2 31


Determining Where to Install the PATROL Agent

Install the PATROL Agent on each computer that you want to monitor.

When installing the PATROL Agent, select Managed System as the system role during the installation.

Determining Where to Install KMs

Where KMs are installed depends on which system roles you have assigned to a computer and which PATROL infrastructure components are installed on that computer.

This section explains where KMs must be installed.

PATROL 3.x

In a PATROL 3.x environment, you must install KMs on the following computers:

■ Computers hosting the PATROL Agent—Select Managed Systems as the System Role in the installation utility when installing KMs. This selection installs KM files that run on the PATROL Agent.

■ Computers hosting the PATROL Console for Windows or PATROL Console for Unix—Select Console Systems as the System Role in the installation utility when installing KMs on computers hosting the PATROL Console for Windows or PATROL Console for Unix. This selection installs KM files for use by the console.

PATROL 7.x

In a PATROL 7.x environment, you must install KMs on the following computers:

■ Computers hosting the PATROL Console Server—Select Common Services Systems as the System Role in the installation utility. This selection installs KM icons, Help files, and resource files used by PATROL Central Operator – Microsoft Windows Edition and PATROL Central Operator – Web Edition.

NOTE If you do not install each KM on the computer hosting the PATROL Console Server and select Common Services Systems as the System Role in the installation utility, no KM icons or KM Help files will be available in either PATROL Central Operator – Microsoft Windows Edition or PATROL Central Operator – Web Edition.



■ Computers hosting the PATROL Agent—Select Managed Systems as the System Role in the installation utility. This selection installs KM files that run on the PATROL Agent.

When using PATROL Central Operator – Web Edition, install KMs on computers hosting the PATROL Console Server using the Common Services Systems role and computers hosting the PATROL Agent using the Managed Systems role.

If you are using older versions of the following components:

■ PATROL Console Server prior to version 7.2.36■ PATROL Central Operator – Web Edition prior to version 7.1.10

You must also install KMs on the computer hosting the PATROL Central Operator – Web Edition web server using the Common Services Systems role.

For more information about the PATROL 7.x architecture, see the PATROL Infrastructure Planning Guide.

Additional Information

For more information about the PATROL consoles and PATROL Console Server or RTserver, see the product’s respective online help systems and the following documents:

■ PATROL Central Operator - Web Edition Getting Started■ PATROL Central Operator - Microsoft Windows Edition Getting Started■ PATROL Console Server and RTserver Getting Started■ PATROL Configuration Manager User Guide■ PATROL Console for Microsoft Windows User Guide - Understanding the Basics of

PATROL, Volume 1■ PATROL Console for Unix User Guide

Chapter 2 33

PATROL Security Levels

PATROL Security LevelsYou can secure the data passed between PATROL components and restrict unauthorized users from accessing your data by implementing PATROL security. You can select from five security levels when you install PATROL.

Checking Security Levels

To check the security level of a previously installed agent, console server, or console, perform the following steps:

1 From the command line switch to the path on the computer that you want to check:

%BMC_ROOT\..\common\security\bin\OS

2 Run the following command to display the security policy of the current machine:

The security level is displayed in the “security level” field of the output.

Assessing and Implementing a Different Security Level

Review the security level definitions in the PATROL Security User Guide before installing PATROL to determine the appropriate security level for your components. To implement a new security level after having previously installed PATROL security, see the PATROL Security User Guide for instructions.

WARNING The PATROL Agent, console server, and consoles must operate at the same security level to communicate with each other. When you install agents, console servers, or consoles that need to communicate with previously installed versions of these components, check the security level of the previously installed components and be sure to install the new ones at the same level.

esstool policy -a


Typical and Custom Installation Types

Typical and Custom Installation TypesThe installation utility may prompt you to select one of the following installation types:

■ The Typical installation type uses defaults values for all optional configuration information. It prompts you only for mandatory configuration information. This type is for any or all of the following situations:

— You are new to the PATROL product that you are installing and you have an agent or console already installed in the default directories.

— You are performing a first-time installation (you are not upgrading), and you are installing into the default product installation directories.

■ With the Custom installation type, you can install individual components of the product. It requires that you specify all configuration information. This type is for any or all of the following situations:

— You want to install individual components rather than the entire product.— You want to specify

■ the port numbers that components use to communicate with each other■ a security level greater than basic security■ any other product settings that a user might want to change

— You are upgrading PATROL KM for Event Management from a previously installed version.

— You are installing into an existing PATROL environment that is not in the default installation directory.

The Custom installation type installs the KMs that you select.

With each installation type, you can deselect any components that you don’t want to install.

NOTE If you are installing PATROL KM for Event Management to an existing PATROL Agent or Console environment that is not in the default installation directory, use Custom. Do not use Typical. Typical will automatically install the agent or console with PATROL KM for Event Management and overwrite your existing installation.

NOTE If you choose the typical installation type, the PATROL KM for Event Management is automatically installed when you select the operating system KM. For example, if you select the PATROL KM for Windows Operating System, the PATROL KM for Event Management is automatically installed.

Chapter 2 35

Typical and Custom Installation Types

Installing into a PATROL 3.3.x or 3.4.x Unix Environment

If you are installing PATROL KM for Event Management into a Unix environment that has PATROL 3.3.x or PATROL 3.4.x installed, you must launch the installation utility from the command line using the -releaseversion option as described in “Upgrading from an Earlier Version” on page 43.

If you have a PATROL Agent installed on the computer where you are installing PATROL KM for Event Management–Preload component, the installation script designates PATROL KM for Event Management as a preloaded KM in the agent configuration file. When a KM is designated as a preloaded KM on a PATROL Agent, it automatically loads and begins to monitor resources and applications whenever the agent is started.

If you have a PATROL Console installed on the computer where you are installing the PATROL KM for Event Management–Preload component, the installation script loads the PATROL KM for Event Management into the console.

For more information about preloading, see the PATROL Agent Reference Manual.


First-Time Installation

First-Time InstallationThe installation utility offers two types of installations: Typical and Custom. For a description of the two types of installations, see “Typical and Custom Installation Types” on page 35.

If you are installing on AS/400 (iSeries), see “Installing on AS/400 (iSeries)” on page 42.

Installing For the First Time

You can install PATROL KM for Event Management using either the Typical or Custom installation type. Regardless of the type of installation you choose, you must repeat this installation process for each computer on which you want to install PATROL KM for Event Management.

Before You Begin

■ You first should install on a limited number of computers in the test environment, test the installation thoroughly, and then install in your production environment.

■ You must have created the PATROL default account.

To Install Using the Typical Installation Type

1 Close the Service Control Manager window and the Control Panel window.

2 From the PATROL for Microsoft Windows Servers CD or from an installation image that has been electronically downloaded from an EPD site and extracted, run setup.exe.

3 In the Welcome to the Installation Utility window, click Next to begin your installation.

4 Review the license agreement, select Accept, and click Next to continue.

NOTE By default, the Typical installation type configures the PATROL Agent to connect through port 3181. To connect the agent from a different port, you must use the Custom installation type.

Chapter 2 37


5 In the Select Installation Option window, select I want to install products on this computer now and click Next to continue.

6 In the Select Type of Installation window, select Typical and click Next to continue.

7 In the Specify Installation Directory window, accept the default directory and click Next to continue.

8 In the Select System Roles window, select any or all of the following roles to indicate the components that you want to install and click Next:

■ If you are installing to a computer that hosts or will host a (Windows only) PATROL Console for Window (Unix only) PATROL Console for Unix, select Console Systems.

■ If you are installing to a computer that hosts or will host a PATROL Agent, select Managed Systems.

■ If you are installing to a computer that hosts or will host the PATROL Central Operator – Web Edition (PATROL 7.x architecture) Web server, the PATROL Console Servers, or the RTservers, select Common Services.

Fore more information, see “Determining Where to Install the PATROL Agent” on page 32.

Table 8 System Role Packages Available for Product Components

Product Component/Selectable Entity

System Role to Select

Console System Managed System

Common Servicesa

aPATROL Central Operator – Web Edition. This console is available when you select the common services role.

PCO-Winb

bPATROL Central Operator – Microsoft Windows Edition. This console is available when you select the console system role.

PATROL 3c

cPATROL Console for Windows and PATROL Console for Unix are PATROL 3 console systems. They are available when you select the console system role.

PATROL Knowledge Module for Event Management

no yes yes yes



9 From the Select Products and Components to Install window, select components that you want to install (see Figure 2 on page 39) and click Next.

Figure 2 Select Products and Components to Install - Typical Install

10 In the PATROL Default Account Properties window, enter the user name and password that you want to use for your PATROL default account and click Next. You should have created this account manually before you began to install PATROL. (For more information about the PATROL account, see “Accounts” on page 27.) This window is displayed only when you are installing a product that requires a PATROL logon.

11 In the Confirm BMC Product Startup Information window, specify whether to restart the PATROL Agent after installation. This window is displayed only if you are installing to a PATROL Agent system.

NOTE If you choose the typical installation type, the PATROL KM for Event Management is automatically installed when you select the operating system KM. For example, if you select the PATROL KM for Windows Operating System, the PATROL KM for Event Management is automatically installed.

NOTE The actual selectable components may be different that what is shown in Figure 2. For example, components that you are installing with the PATROL KM for Event Management will also be shown.

Chapter 2 39


12 In the Review Selections and Install window, review the selections carefully to ensure that they are correct:

■ To change your selections, click Back and make those changes. ■ If the selections are correct, click Start Install to start installing.

A status window opens that contains current messages, current milestones, and percentage complete.

13 When the status window reports that the installation is 100% complete, click Next to view the results window. (Next does not appear until the installation is 100% complete.)

14 Click Finish to close the installation utility.

To Install Using the Custom Installation Type

1 Close the Service Control Manager window and the Control Panel window.

2 From the PATROL for Microsoft Windows Servers CD or from an installation image that has been electronically downloaded from an EPD site and extracted, run setup.exe.

3 In the Welcome to the Installation Utility window, click Next to begin your installation.

4 In the Review License Agreement window, review the license agreement, select Accept, and click Next to continue.

5 In the Select Installation Option window, select I want to install products on this computer now and click Next to continue.

6 From the Select Type of Installation Window, select Custom and click Next.

7 In the Specify Installation Directory window, enter the directory where the products you select will be installed and click Next.

The PATROL product directory is appended to the path that you enter in this step. You will specify the PATROL product directory in step 10 on page 41.

8 In the Select System Roles window, select any or all of the following roles to indicate the components that you want to install and click Next:

■ If you are installing to a computer that hosts or will host a PATROL Console, select Console System.



■ If you are installing to a computer that hosts or will host a PATROL Agent, select Managed System.

■ If you are installing to a computer that hosts or will host the PATROL Central Operator – Web Edition (PATROL 7.x architecture) Web server, the PATROL Console Servers, or the RTservers, select Common Services.

For more information, see “Determining Where to Install the PATROL Agent” on page 32.

For more information about the PATROL consoles and PATROL Console Server or RTserver, see the following documents:

■ PATROL Central Operator – Web Edition Getting Started■ PATROL Central Operator – Microsoft Windows Edition Getting Started■ PATROL Console Server and RTserver Getting Started

9 From the Select Products and Components to Install window, select the items that you want to install and click Next.

10 In the Provide the PATROL 3.x Product Directory window, enter in the PATROL 3.x Product Directory field the directory in which you want to install PATROL KM for Event Management as appropriate for your installation scenario. For more information, see the instructions displayed on the PATROL 3.x Product Directory window.

This directory is appended to the base directory path that is shown in the BMC Products Installation Directory field. The installation directory was entered in step 7 on page 40.

11 If the PATROL Default Account Properties window appears, enter the user name and password that you want to use for your PATROL default account and click Next. You should have created this account manually before you began to install PATROL. (For more information about the PATROL Account, see “Accounts” on page 27.) This window is displayed only when you are installing a product that requires a PATROL logon.

12 If the Complete the Confirm BMC Startup Information window appears, perform the following steps:

A In the Specify the Current Agent Port Number field, enter the port number that you want the PATROL Agent to use. The default is 3181.

NOTE If your previous installation used a different port number, change the default to the current port number for the PATROL Agent.

Chapter 2 41


B In the Restart the PATROL agent automatically? field, select the appropriate option:

■ If you want the installation utility to restart the PATROL Agent after the installation is complete, select Yes.

■ To restart the PATROL Agent manually after the installation is complete, select No.

■ This window may not be displayed if you are not installing into a managed system.

13 In the Review Selections and Start Install window, review the selections carefully to ensure that they are correct:

■ To change your selections, click Back and make those changes.

■ If the selections are correct, click Start Install to start installing.

A status window opens that contains current messages, current milestones, and percentage complete.

14 When the status window reports that the installation is 100% complete, click Next to view the results window. (Next does not appear until the installation is 100% complete.)

15 Click Exit to close the installation utility.

Installing on AS/400 (iSeries)

On AS/400 (iSeries), the PATROL KM for Event Management is installed with the PATROL Agent. For more information about installing the PATROL Agent on AS/400 (iSeries), see the PATROL for AS/400 Getting Started.


Upgrading from an Earlier Version

Upgrading from an Earlier VersionThe PATROL KM for Event Management 2.7 has no migration path from versions prior to 2.7. Migration of the PATROL KM for Event Management is not required because the configuration information is stored in the PATROL Agent configuration database. If you have customized .kml or PSL files or created KMs in previous versions of the PATROL KM for Event Management and you want to migrate those to the new version, see the migration instructions in the PATROL for Microsoft Windows Getting Started.

While there is no migration for the PATROL KM for Event Management, there are some steps you must take if you install version 2.7 on a system that had a previous version of the KM. The following sections describe the actions that you must perform to upgrade from a previous version of PATROL KM for Event Management.

Remove Customized KM Files From the PATROL_CACHE

Before upgrading from a previous version of this KM, you must backup and remove all Event Management and PATROL KM for Event Management customized files from the PATROL_CACHE (including the StdEvent.ctg file).

Remove Existing Menu Commands

Before upgrading from a previous version of this KM, you must remove existing menu commands that are installed in the ALL_COMPUTERS.KM.

Windows Consoles

1 From the PATROL Classic Developer Console main window, select the KM tab.

2 Expand the following folders in the KM tree view:

Knowledge Module => Computer Classes => ALL_COMPUTERS => Global => Menu Commands

3 Right-click EVENTSPRING or Event Management.

4 Select Delete.

5 When asked to confirm the deletion, click Yes.

6 Save your changes before you exit the PATROL Console.

Chapter 2 43

Considerations for Using Online Help

Considerations for Using Online HelpIf you plan to install the Unix version of PATROL KM for Event Management on a PATROL Console for Unix, you must install the supported version of the Help browser separately if it is not already installed.

Browser Version Required for Viewing PATROL Console for Unix Help

The appropriate one of the following browsers is required to view PATROL Help in PATROL version 3.x:

■ Unix: Netscape Navigator version 3.01 through 4.78

■ Red Hat Linux: Netscape Navigator version 4.x

PATROL Help does not support Netscape Navigator 6.0.

Installation Requirement

You must install Netscape Navigator on the computer where the PATROL console resides. You can install Netscape anywhere on your Unix computer as long as the binary is in the path.

Download Location

Netscape Navigator is supplied by Netscape Communications Corp. You can locate the browser at http://home.netscape.com/download.

Additional Considerations for Using Online Help for Unix

When you select Help from the PATROL Console for Unix, it may take a few seconds for the Help browser to launch. Two windows will be displayed. First, the Netscape Navigator window is displayed as an icon, and then a browser window that contains the Help is displayed.

In addition, you must be aware of the following restrictions:



■ Netscape Navigator displays warning messages when it is invoked multiple times within the same user account because of its file-locking mechanism. It will, however, continue functioning.

■ By default, when Netscape Navigator starts, it uses a private color map. As a result, you might experience color flashing on your workstation. If so, you can set the value of PATROL_BROWSER so that the colormap option is not specified. However, some subsequent color requests might fail and the online Help will be improperly displayed.

■ The Exceed for Windows NT X Window Server product by Hummingbird Communication Ltd. may not always display the Help files properly.

Consult your Netscape Navigator documentation for specific platform requirements and restrictions.

Required Environment Variables Settings for the Browser

The LANG, PATH, and PATROL_BROWSER environment variables must be set for the Help browser to run properly. The following sections describe these variables.

LANG Variable

The Unix LANG environment variable must be set to C so that Netscape Navigator will work properly. Otherwise, you might experience product failures.

PATH Variable

The PATROL user account PATH variable must contain the location of the directory containing the Netscape files. If the directory containing the Netscape files is not in the path, add the directory to the PATROL user account path.

This requirement applies only to the PATROL user account on the PATROL console computer.

Type of Shell Export Command for LANG Variable

Bourne LANG=Cexport LANG

Korn export LANG=C

C setenv LANG=C

Chapter 2 45


PATROL_BROWSER Variable

When PATROL starts the Help browser, it uses the command in the PATROL_BROWSER environment variable. As a default, the PATROL_BROWSER environment variable contains the following command:

To use different arguments, set the value of PATROL_BROWSER to the appropriate string.

Example

For a Korn shell, use the following command:

Type of Shell Export Command for PATH Variable

Bourne PATH=$PATH:/netscape_locationexport PATH

Korn export PATH=$PATH:/netscape_location

C setenv PATH=$PATH:/netscape_location

Type of Shell Export Command for PATROL_BROWSER Variable

Bourne PATROL_BROWSER=netscape -display $DISPLAY -install -iconicexport LANG

Korn export PATROL_BROWSER=netscape -display $DISPLAY -install -iconic

C setenv PATROL_BROWSER=netscape -display $DISPLAY -install -iconic

export PATROL_BROWSER=/usr/local/bin/netscape -raise


Uninstalling PATROL KM for Event Management

Uninstalling PATROL KM for Event Management

To uninstall PATROL KM for Event Management you must use the same version of the installation utility that you used to install the product. Run the installation utility in uninstall mode to uninstall PATROL KM for Event Management from your system.

Determining the Version of the Installation Utility

To determine the version of the installer, perform the following procedure.

1 Access a command prompt and navigate to the appropriate location:

(Windows) BMC_ROOT\Uninstall

(Unix) BMC_ROOT/Uninstall

2 Type the following command and press ENTER.

(Windows) uninstall.exe -v

(Unix) ./uninstall.sh -v

Uninstalling PATROL KM for Event Management on Windows

You can use the option that is appropriate for what you want to uninstall to uninstall PATROL KM for Event Management. The following procedures describe how to uninstall products from a Windows environment and all related log files.

WARNING If you use a different version of the installation program to uninstall, you might remove files needed to perform uninstallation of other BMC Software products.

Chapter 2 47

Where to Go from Here

To Uninstall Individual Products

1 From the Uninstall directory in your BMC Software product installation directory, double-click uninstall.exe to launch the installation utility in uninstall mode.

2 Select the installation directory from which you want to remove a product, and click Next.

3 Select the product or products that you want to uninstall, and click Next.

4 Review your selections and click Uninstall.

After the uninstallation is complete, a window is displayed that tells you whether the uninstallation was successful.

For more information about advanced uninstallation options, such as uninstalling the KM but retaining log files, which contain history for future analysis and configuration files for redeployment, see the PATROL Installation Reference Manual.

Where to Go from HereThe following table lists other topics and where you can find them:

NOTE As an option, you can launch the installation utility in uninstall mode by choosing Start => Settings => Control Panel => Add/Remove Programs and double-clicking BMC Software Tools in the Add/Remove Programs Properties dialog box.

Topic Source of Information

overview of the PATROL KM for Event Management features

Chapter 1, “Product Components and Capabilities.”

setting up and configuring PATROL KM for Event Management

Chapter 3, “Using the PATROL KM for Event Management.”

information on usage scenarios Chapter 4, “Usage Scenarios.”

information about PATROL KM for Event Management configuration variables

Chapter 5, “Rules and Configuration Variables.”

parameter descriptions Chapter 6, “Parameters.”

troubleshooting information Chapter 7, “Troubleshooting PATROL KM for Event Management,”

step-by-step procedures and detailed descriptions of the applications, menu commands, parameters, and InfoBoxes

PATROL KM for Event Management component online Help


C h a p t e r 3
3 Using the PATROL KM for Event Management
This chapter provides information on using the PATROL KM for Event Management to perform notification, availability checking, and parameter threshold management.

Preparing to Use the PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . 51Loading and Preloading KMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Determining Which KMs to Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51KM Files Preloaded on Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Loading and Unloading KMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Loading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Verifying that PATROL KM for Event Management KM is Loaded. . . . . . . . . . . 55Unloading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Configuration Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Defining Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Defining Notification Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Defining Availability Monitors and Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Deciding Where to Place Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Configuring Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Recommended Configuration Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Using Notification Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Testing Notification Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Configuring Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Configuring Remote Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Configuring Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Rewording Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Setting Notification Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Testing Notification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Disabling Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Configuring Availability Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Configuring an Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Configuring a Backup Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Configuring the Availability Monitor Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Specifying an Availability Monitoring Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Changing the Ping Command Used for Availability Monitoring . . . . . . . . . . . . . 93

Chapter 3 49

Integrating with AlarmPoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94AlarmPoint Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Installing and Configuring AlarmPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Installing the AlarmPoint Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Configuring the AlarmPoint Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Testing the Java Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Using Action Scripts for AlarmPoint 5.2.01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Configuring Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Testing Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Managing Parameter Thresholds and Poll Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Benefits of Using the PATROL KM for Event Management . . . . . . . . . . . . . . . . . 104Setting Collector Poll times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Using Wildcards to Represent PATROL Instance Names . . . . . . . . . . . . . . . . . . . 107Activating and Deactivating Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Applying Thresholds and Poll Time Changes to the Agent . . . . . . . . . . . . . . . . . 111Disabling the use of PATROL KM for Event Management Thresholds and Poll

Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Specifying What to Monitor or Exclude from Monitoring . . . . . . . . . . . . . . . . . . . . . . 112

Selecting Application Instances to Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Excluding Application Instances from Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 114

Configuring Blackout Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115About Notification Blackout Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Configuring Notification Blackouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Configuring Availability Blackouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Configuring Recovery Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120About Recovery Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Enabling PATROL KM for Event Management Recovery Actions . . . . . . . . . . . 121Specifying a Recovery Action Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Specifying a Recovery Action Command Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Using PSL Recovery Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124


Preparing to Use the PATROL KM for Event Management

Preparing to Use the PATROL KM for Event Management

Before configuring the PATROL KM for Event Management, verify that the following requirements are met:

■ The PATROL console version 3.4.x or later and the PATROL KM for Event Management are installed on the computer that you want to use for the PATROL console.

■ The PATROL Agent version 3.4.x or later and the PATROL KM for Event Management are installed on the computer that you want to monitor and manage.

■ If you are using PATROL Central Operator – Microsoft Windows Edition or PATROL Central Operator – Web Edition, the PATROL KM for Event Management must be installed on the computer hosting the PATROL Console Server.

Loading and Preloading KMsWhen you load a KM from the PATROL console, the KM files are loaded on all the PATROL Agents to which your console is connected. The KM icons appear in your console, usually under each agent icon, during discovery. Each PATROL Agent then collects data based on the instructions defined in the KM.

Preloading KMs is a PATROL Agent feature that causes KM files to continue to run on the agent when no consoles are connected. KMs that are not preloaded collect data only while a PATROL console is connected to the PATROL Agent.

Determining Which KMs to Load

Before you can use the KMs that you have installed, the KM files must be loaded into the PATROL console so that the product’s applications, commands, and parameters appear in the PATROL console. Table 9 on page 53 lists the KML and KM files in this product that you can load. You can find the steps for loading KM files in “Loading Knowledge Modules” on page 52.

Chapter 3 51

Loading and Unloading KMs

KM Files Preloaded on Agent

The following PATROL KM for Event Management KM files are automatically preloaded on the PATROL Agent as part of the installation process. They are added to the preloadedKMs agent configuration variable.

■ AS_EVENTSPRING.km■ AS_AVAILABILITY.km■ AS_EVENTSPRING_ALL_COMPUTERS.km

Preloaded KMs collect data as long as the PATROL Agent runs, even when no PATROL console is connected. When you view a preloaded KM’s data collection history, you do not see any gaps that would otherwise occur (because of the console’s absence).

Loading and Unloading KMsInstalling PATROL KM for Event Management places the application files into the PATROL directory. You can load the files into the PATROL console so that the PATROL KM for Event Management applications, commands, and parameters appear in the PATROL console.

If you no longer want to use an application class that you previously loaded, you can use the unload instructions to unload the .km file so that its application class no longer appears in your console.

Loading Knowledge Modules

Before you can begin using Knowledge Modules (KMs) that you have installed, you must first load them with a PATROL Console. In this section, follow the instructions that apply to your console.

To Load KMs with PATROL Central - Windows Edition

PATROL Central - Windows Edition has a Loading KMs wizard that enables you to control which KMs are loaded on which computers.

1 On the Common Tasks tab of the taskpad, click the Load Knowledge Modules icon.

PATROL Central - Windows Edition displays the wizard.

2 Click Next to start the wizard.



The wizard lists each computer on which a PATROL Agent has been installed.

3 Select the check boxes for the computers on which you want to load KMs, and click Next.

The wizard displays a list of available .kml files for each computer selected in the previous step. Each .kml file is listed once for each computer. You can display .km files by changing the filter.

The KMs available in this product are listed in Table 9.

4 Select the check boxes for the KM and computer pair that you want to load.

5 Click Next and click Finish.

PATROL loads the selected KMs on the selected computers.

To Load KMs with PATROL Central - Web Edition

PATROL Central - Web Edition has a Loading KMs feature that enables you to control which KMs are loaded on which computers.

NOTE Unless you are an advanced PATROL user, use the .kml files to load product component files. Loading individual .km files can break the interdependencies between the .km files, while loading .kml files preserves these dependencies.

Table 9 EVENT_MANAGEMENT.kml File and Associated KM Files)

Product (.kml file) Components (KM files) Description

EVENT_MANAGEMENT.kml AS_AVAILABILITY The AS_AVAILABILITY application class icon is not displayed in the PATROL Console until availability targets are added.

AS_EVENTSPRING When loaded, this KM is displayed on the console as Event Management.

AS_EVENTSPRING_ALL_COMPUTERS

This KM file never appears on the console as a loaded KM; it is merged with the ALL_COMPUTERS.

Chapter 3 53


1 From the Monitored Systems page, click the Load/Unload KMs button.

The Load KMs page opens, listing each computer on which a PATROL Agent has been installed.

2 Select the computers on which you want to load KMs, and click Next.

The Load KMs page displays a list of available .km and .kml files.

If you selected more than one computer, the only .km and .kml files that are listed are the ones that have been installed on all of the selected computers. If a particular .km or .kml file was installed only on one computer, you must choose that computer by itself to load the file.

The KMs available in this product are listed in Table 9 on page 53.

3 Select the .km or .kml files that you want to load.

4 Click Finish.

PATROL loads the selected KMs on the selected computers.

To Load KMs with the PATROL Console for Windows

1 From the PATROL Console for Windows menu bar, choose File => Load KM.

The Load KMs dialog box displays a list of available .kml files. The KMs available in this product are listed in Table 9 on page 53.

2 Select one or more of the .kml files, and click Open.


NOTE To load a .km or .kml file that was not listed in Step 2, ensure that the KM is installed on the appropriate computer and select only that computer in Step 2.




PATROL loads the selected KMs on all of the computers listed under PATROLMainMap.

To Load KMs with the PATROL Console for Unix

1 From the PATROL Console for Unix menu bar, choose File => Load KM.

The Load KMs dialog box displays a list of available .kml files. The KMs available in this product are listed in Table 9 on page 53.

2 Select one or more of the .kml files and click Open.

PATROL loads the selected KMs on all of the computers to which your console is connected.

Verifying that PATROL KM for Event Management KM is Loaded

To verify that the PATROL KM for Event Management application is loaded on the managed systems, ensure that each managed system displays the Event Management application class icon when viewed with a PATROL Console that has the PATROL KM for Event Management loaded.

Unloading Knowledge Modules

If you no longer want to use an application class that you previously loaded, you can unload the .km file so that its application class no longer appears in your console. In some consoles, unloading is referred to as deleting. When you unload or delete a .km file using a console, the file is not deleted from the patrol\knowledge directories on the PATROL Console or the PATROL Agent computers.


NOTE The AS_AVAILABILITY application class icon is not displayed in the PATROL Console until availability targets are added.

Chapter 3 55


To Unload KMs with PATROL Central - Windows Edition

PATROL Central - Windows Edition has a wizard that enables you to unload specified .km files from specified computers.

1 On the Common Tasks tab of the taskpad, click the Unload Knowledge Modules icon.

PATROL Central - Windows Edition displays the wizard.

2 Click Next to start the wizard.

The wizard lists each computer on which a PATROL Agent has been installed.

3 Select the check boxes for the computers from which you want to unload .km files, and click Next.

The wizard displays a list of application class names (that correspond to .km file names) for each computer selected. Each application class name is listed once for each computer.

4 Select the check boxes for the .km and computer pair that you want to unload, and click Next.

5 Click Finish.

The console removes the selected .km files from the current management profile.

To Unload KMs with PATROL Central - Web Edition

PATROL Central - Web Edition has a feature that enables you to unload specified .km files from specified computers.

1 From the Managed Systems page, click Unload Knowledge Modules.

The Unload Knowledge Module Wizard starts.

2 Select the computers from which you want to unload .km files, and click Next.

The Load KMs page displays a list of .km files. Currently loaded .km files are highlighted in the list.

3 Select the .km files that you want to unload and click Next.

4 Click Finish.

The console removes the .km files that you specified. These .km files are no longer in the current management profile.



To Unload KMs with the PATROL Console for Windows

Unloading a KM is also referred to as deleting a KM in the PATROL Console for Windows.

1 From the KM tab of the tree view, right-click the application class name that you want to delete and choose Delete from the pop-up menu.

The console displays a dialog box that asks if you want to delete the selected application.

2 Click Yes to delete the application class.

The application class is removed from your cache directory and your console session file.

3 Repeat Step 1 and Step 2 until you have deleted all of the application classes associated with the KM that you want to delete.

4 From the console menu bar, choose File => Save KM to save your changes.

To Unload KMs with the PATROL Console for Unix

Unloading a KM is also referred to as deleting a KM in the PATROL Console for Unix.

1 From the PATROL Main window, choose Attributes => Application Classes.

2 Click the name of the application class that you want to delete.

The console highlights the application class name.

3 From the List of Application Classes menu bar, choose Edit => Delete.

The application class is removed from your cache Directory and your console session file. The PATROL Console for Unix removes the application class name from the List of Application Classes.

4 Repeat Step 2 and Step 3 until you have deleted all of the application classes associated with the KM that you want to delete.

5 From the List of Application Classes menu bar, choose File => Save KM to save your changes.

Chapter 3 57

Configuration Planning

Configuration PlanningBefore you can use PATROL KM for Event Management, you must gather information and plan your configuration. You should gather the following information:

■ the servers that will send notifications (act as notification servers)■ to whom e-mail or paging notifications are sent (targets)■ the servers that will monitor the notification servers for availability■ the notification servers that will be monitored for availability■ where to place notification rules (notification server or monitored agent)

Defining Notification Servers

A notification server is the managed system that performs notification and event collection on behalf of other PATROL Agents.

Why use a Notification Server?

With a notification server, you can centrally manage your event filtering and notification rules. For example, if you need to modify a notification script or change notification rules, you make the change only on the notification servers and not on each agent. For more information on the advantages and disadvantages of locating notification rules on the notification server, see “Deciding Where to Place Rules” on page 61.

Notification servers also provide redundancy when you use a primary and backup notification server.

Using Primary and Backup Notification Servers

To ensure availability, you should assign both a primary and a backup notification for each remote agent. A notification server could be a primary notification server for some remote agents and a backup notification server for other remote agents. Hence, a server that acts as a backup notification server does not need to be idle.

What Happens During Failover?

When a primary notification server fails and a backup notification server takes its place, an alert is generated on the remote agent that sent the event to the notification server. In addition, a message is displayed in the console system output window.



To assure availability in critical environments, the backup notification server should be on a separate machine and network segment.

Using Enterprise Consoles to Send Notifications

If you are using an enterprise console, such as PATROL Enterprise Manager (PEM) or Tivoli, to send e-mail messages or pages, you can configure the notification server to route notification events to the enterprise console. Even though the notification server does not actually perform notification, you must still configure each remote agent to send notification events to a notification server and configure the notification server to route those events to the enterprise console. For a process flow that describes this scenario, see “Sending Alerts to an Enterprise Console: Process Flow” on page 20.

Notification Server Connectivity

When identifying a notification server, make certain that there are no connectivity problems between the notification server and the agents that it serves.

Providing Security

To improve security, create an operating system account on the notification server systems to be used specifically for remote notification. This configuration enables you to avoid using the more commonly used PATROL account. You can configure the notification server so that it is unable to fully login to the notification server system by using the operating system. For example, on Unix, give the notification server login an invalid login shell, such as /bin/false.

Configuring a Notification Server

For more information on configuring a notification server, see “Configuring Notification Servers” on page 71.

Once you have configured a primary and backup notification server, you can use the PATROL Configuration Manager to copy the settings to the other notification servers. If you use this method, make sure that you use the same notification script file name and directory path on all notification servers.

NOTE You must install the PATROL Agent and the PATROL KM for Event Management on the notification server system.

Chapter 3 59


Defining Notification Targets

For alert notifications, you define a default e-mail account that is the default target for all PATROL objects that do not have a specific target defined. This e-mail account receives notification messages when the PATROL objects generate alerts.

To further configure and customize the PATROL KM for Event Management, you can specify e-mail targets for each PATROL object. For example, you may want Unix related alerts to go to your Unix administrator and Windows related alerts to go to your Windows administrator.

Create a notification table similar to the one in Table 10 to identify who to notify for each type of alert. For more information, see “Setting Notification Targets” on page 82.

Defining Availability Monitors and Targets

You can monitor the PATROL Agents to verify that they are up and running by using the availability monitoring feature. You must specify the servers that monitor and the notification servers that are monitored. The following section provides some guidelines on availability monitoring.

Providing Redundancy

You should configure both a primary and a backup availability monitor. The backup availability monitor monitors only the availability of the primary availability monitor. If the primary availability monitor becomes unavailable, the backup availability monitor assumes monitoring until the primary availability monitor is available.

Using Availability Monitors to Monitor Notification Servers

Do not make a notification server an availability monitor. The availability monitor should be a separate agent that only monitors the notification servers. In this arrangement, the notification server is considered an availability-monitoring target, which means that it is being monitored for availability.

Table 10 Notification Target Configuration Information

PATROL Object E--mail Target Paging Target

/ [email protected] none

/CPU [email protected] unixadmin

/NT_CPU [email protected] ntadmin



Dedicated Computer Not Required

While the PATROL agent running on the availability monitoring machine should be dedicated to availability monitoring, the availability monitoring machine can perform other functions.

Maximum Number of Agents to Monitor

An availability monitor can monitor a maximum of 100 agents. If the availability monitor monitors more than 100 agents, it may not be able to ping with the frequency specified by the parameter AvailabilityMonitorColl.

Improving Performance

To improve the availability monitor performance, you should apply certain agent rules to the availability monitor. For more information, see“Configuring the Availability Monitor Agent” on page 91.

Grouping Targets Logically

When setting up availability monitoring in your enterprise, group availability monitoring targets and monitors in a logical fashion. For example, you may want to group targets by geographical location so that when the availability monitor detects that a notification server is unavailable, you know immediately which servers are affected.

For more information about configuring availability monitoring, see “Configuring Availability Monitoring” on page 87.

Deciding Where to Place Rules

The PATROL KM for Event Management rules specify parameter and notification settings. Rules can exist on either the remote agents you are monitoring or the notification server or on both. Some rules must exist only in one place. Table 11 on page 62 discusses the advantages and disadvantages of rule locations.

TIP Availability checkers perform best on Unix machines and allow easier management of multiple agents running availability checkers on one machine.

Chapter 3 61


Table 11 Recommended Rule Location (Part 1 of 2)

Rule TypeRecommended Location Advantage Disadvantage

Targets (notification recipients)

notification server

■ Easier to manage

■ Less processing at managed nodes reduces PATROL resource consumption

More processing is performed at the notification server

Alert Messages (wording and content of notification messages)

remote agent ■ Reduces the number of rules at the notification server

■ Since messages are reworded before arriving at the notification server, you don’t need a second level of notification servers to properly send messages to an enterprise console.

More difficult to manage the rules on multiple remote agents

Blackouts remote agent ■ Reduces network traffic

■ Reduces processing at the notification server

More difficult to manage the rules on multiple remote agents

Alert Action (what to do when an alert occurs)

remote agent only

The alert action must be defined on the remote agent where PATROL alerts are generated.

Parameter Settings (thresholds and poll times)

remote agent only

The parameter settings must be defined on the remote agent where PATROL alerts are generated.

Alert Resend (whether to resend outstanding alerts)

remote agent only

The alert resend settings must be defined on the remote agent where the PATROL alerts are generated.

Notification Command (the script used to send notifications)

notification server only

The notification script must be defined on a notification server that sends notifications.

If you are not using notification servers, the remote agent, in effect, acts as the notification server. In this case, the notification command rule resides on the remote agent.

Send Reset on Init (whether to close old events when agent restarts)

remote agent only

The Send Reset on Init setting must be defined on the remote agent where PATROL alerts are generated.


Configuring Notification

Configuring NotificationThis sections describes how to configure the PATROL KM for Event Management to perform notification.

Recommended Configuration Order

When using the PATROL KM for Event Management to configure notification and availability checking, use the order suggested in Table 12.

Custom Identifiers remote agent only

Custom identifiers must be defined on the remote agent where message rewording is taking place.

Recovery Actions remote agent only

Recovery actions settings must be defined on the remote agent where PATROL events are generated and where you expect the recovery action to occur.

Table 12 Recommended Configuration Process (Part 1 of 2)

Step Configuration Task Topic(s) Page

1 Identify, edit, and test the notification script.

“Using Notification Scripts” 64

“Testing Notification Scripts” 70

2 Configure a notification server. “Configuring Notification Servers” 71

3 Reword default notification message for the notification server.

“Rewording Notification Messages” 79

4 Use PATROL Configuration Manager to copy the notification server settings (rules) to the other notification servers.

For an example of how to use the PATROL Configuration Manager, see “To Assign Notification Servers for NT2 and NT3.” For more detailed instructions on using the PATROL Configuration Manager, see the PATROL Configuration Manager User Guide.

134

5 Configure remote agents to use a notification server.

“Configuring Remote Agents” 73

Table 11 Recommended Rule Location (Part 2 of 2)

Rule TypeRecommended Location Advantage Disadvantage

Chapter 3 63


Using Notification Scripts

The PATROL KM for Event Management provides sample notification scripts that call command-line utilities to initiate notification (such as e-mail and page). This section describes the sample scripts, their locations, requirements for use, and editing guidelines. Editing is required on most platforms.

Unix and Linux Scripts

On Unix and Linux, the following script options are available:

■ a Unix shell script that sends e-mail notification using mailx (Unix) or mail (Linux)■ a Perl script that sends e-mail notification using mailx (Unix) or mail (Linux)

6 Use PATROL Configuration Manager to copy agent notification server rules to other like agents.

For example, copying the settings to other agents that use the same notification server.

For an example of how to use the PATROL Configuration Manager, see “To Assign Notification Servers for NT2 and NT3” on page 134. For more detailed instructions on using the PATROL Configuration Manager, see the PATROL Configuration Manager User Guide.

134

7 Configure notification rules and parameter settings for the agents.

“Setting Notification Targets” 82

“Managing Parameter Thresholds and Poll Times”

104

“Configuring Alert Settings” 76

8 Use PATROL Configuration Manager to copy agent notification rules and parameter settings to other like agents.

For example, you may want to set up a notification rule for a parameter related to Oracle. You would then copy that rule to all other agents that are monitoring Oracle.

For an example of how to use the PATROL Configuration Manager, see “To Assign Notification Servers for NT2 and NT3” on page 134. For more detailed instructions on using the PATROL Configuration Manager, see the PATROL Configuration Manager User Guide.

134

9 Configure availability monitoring. “Configuring Availability Monitoring” 87

NOTE The PATROL KM for Event Management Perl script has been tested with Perl 5.

Table 12 Recommended Configuration Process (Part 2 of 2)




Default Location on Unix

The scripts that run on Unix, shown in Table 13, are located in $PATROL_HOME$/lib/psl

Unix Requirements

To use the Unix scripts, the server sending the notification must meet the requirements shown in Table 14.

Windows Scripts

On Windows, the following script options are available:

■ a Windows batch file that you must edit before use, which can send any of the following types of notification:

— SMTP e-mail message by means of a Visual Basic (VB) script (provided)— MAPI e-mail message by means of a VB script (provided)— SMTP e-mail message by means of Blat (not provided)

Blat is a free command-line e-mail client, that you can download from the Web. You can also use any other SMTP-based, command-line e-mail client if you edit the batch file accordingly. For more information, see “Editing Scripts” on page 67.

■ a Perl script that sends e-mail notification by means of Blat

Table 13 Notification Script Location on Unix

Script Name

Unix Script AS_EVSLocalAlertNotify.sh

Perl Script AS_EVSLocalAlertNotify.pl

Table 14 Requirements for Using Scripts on Unix Notification Server

Script Requirements

Unix If mailx is installed in a directory other than /usr/bin/mailx, you must move mailx to this directory or edit AS_EVSLocalAlertNotify.sh to execute mailx from the directory where it is installed.

On Linux, you must edit the script and change any mailx references to mail.

Perl Associate the .pl extension with Perl. Otherwise, you must call the script using the syntax shown below:

perl PATROL3-4/lib/psl/AS_EVSLocalAlertNotify.pl

On Linux, you must edit the script and change any mailx references to mail.

Chapter 3 65


Default Location on Windows

The Windows scripts are located in the %PATROL_HOME%\lib\psl\ directory and are named as shown in Table 15.

Windows Requirements

To use these Windows scripts, the server sending the notification must meet the requirements shown in Table 16.

NOTE The PATROL KM for Event Management has been tested with Blat version 1.7.

Table 15 Notification Script Location on Windows

Script Name

Batch File Script AS_EVSLocalAlertNotify.bat

SMTP VB Script sendmail.vbs

This VB script is called from AS_EVSLocalAlertNotify.bat. This script uses an ActiveX control.

MAPI VB Script send_mapi.vbs

This VB script is called from AS_EVSLocalAlertNotify.bat. This script uses an ActiveX control.

Perl Script AS_EVSLocalAlertNotify.pl

Table 16 Requirements for Notification Server When Using Windows e-mail Clients

Script Requirement

Batch File Script If Blat is installed in a directory other than C:\Blat, you must move Blat to this directory or edit AS_EVSLocalAlertNotify.bat to execute Blat from the directory where it is installed.

Perl Script The Perl script assumes the use of Blat. If Blat is installed in a directory other than C:\Blat, you must move Blat to this directory or edit the Perl script, AS_EVSLocalAlertNotify.pl, to execute Blat from the directory where it is installed.

Associate the .pl extension with Perl. Otherwise, you must call the script using the following syntax:

perl C:\PATROL3-4\lib\psl\AS_EVSLocalAlertNotify.pl



AS/400 (iSeries) Scripts

On AS/400 (iSeries), the script AS_EVSLocalAlertNotify is provided. By default, this script sends e-mail notifications using the AS/400 SNDDST (Send Distribution) utility. If you use this mail utility, no script modifications are required.

OpenVMS Scripts

On OpenVMS, the script AS_EVSLocalAlertNotify.com is provided. By default, this script sends e-mail notifications using the native OpenVMS utility MAIL. If you use this mail utility, no script modifications are required.

Editing Scripts

Before using the sample scripts, you may have to edit them, as described in Table 17 on page 68.

SMTP VB Script The SMTP service must be running.

This VB script is not supported on Windows NT Workstation.

MAPI VB Script Microsoft Outlook must be installed.

This VB script is not supported on Windows NT Workstation.

Table 16 Requirements for Notification Server When Using Windows e-mail Clients

Script Requirement

Chapter 3 67


.

Editing the Windows Batch File

If you use AS_EVSLocalAlertNotify.bat, remove the REM comments from the mail client that you want to use. The script provides sections for MAPI-based e-mail, SMTP-based e-mail, and Blat. For example, to use Blat, in the script shown below, remove the REM comments beginning with the line that starts with set and ending with the line that reads goto BYE.

Table 17 Editing Scripts

Script Platform Editing Required

Unix If you use Linux, you must change any mailx references to mail.

If you use mailx and mailx is not installed in the /usr/bin/mailx directory, you must edit the script to indicate the appropriate path.

Windows If you use AS_EVSLocalAlertNotify.bat, you must remove the REM comments from the mail client that you want to use. For more information, see “Editing the Windows Batch File” on page 68.

If you use the Perl script, minor editing is needed. For details, see “Editing Perl Script for use on Windows” on page 69.

If you use Blat and Blat is not installed in the C:\Blat directory, you must edit the script to indicate the appropriate path.

If you use the SMTP VB script, you must edit the script to indicate the name of your mail server and the SMTP port number. For more information, see “Editing the SMTP VB Script” on page 3-69.

AS/400 (iSeries)

No edits required if using native mail utility. If you use a different mail utility, you must edit the script to call the desired utility.

OpenVMS No edits required if using native mail utility. If you use a different mail utility, you must edit the script to call the desired utility.

:EMAILrem --rem -- BLAT based eMailrem --rem set email_file=c:\blat\mtext%AS_PARAMETER_NAME%_%AS_SSTIME%.txtrem if ."%AS_USERDEFINED%"==."" echo "%nmsg%" > %email_file%rem if not ."%AS_USERDEFINED%"==."" echo "%AS_USERDEFINED%" > %email_file%rem if .%email_file%==. set email_file=c:\blat\default.txtrem if exist c:\blat\blat.exe c:\blat\blat %email_file% -t %ntargets% -s %nmsg%rem goto BYE



If you use a third-party command-line e-mail client or if you want to use the script to perform other types of notification, such as paging or trouble tickets, you must add the code to the script that calls the e-mail client or appropriate notification utility.

Editing Perl Script for use on Windows

On Windows, you must edit the Perl script before you can use it to send e-mail notifications with Blat. Find the following line in the Perl script and remove the comment (# ):

Editing the SMTP VB Script

To use the SMTP VB Script (sendmail.vbs), you must edit the script to add the following information:

■ name of the e-mail server■ the SMTP server port

Add this information in the script as shown below.

Backing up and Renaming the Notification Script

Before configuring notification servers, copy the notification script from the default installation location, %PATROL_HOME%\lib\psl\, to another location. This action prevents the script from being overwritten during a new installation or upgrade. Place the notification script in the same location on both the primary and backup notification servers.

Other Types of Notification

In addition to e-mail, the notification scripts that are included with the PATROL KM for Event Management can also be used to send the following types of notifications:

■ pages■ trouble tickets■ custom notifications

#system("c:\\blat\\blat.exe $email_file -t \"$ntargets\" -s \"$nmsg\"");

' Enter the Mail Server name [FQDN/IP Address] iConf.Fields("http://schemas.microsoft.com/cdo/configuration/smtpserver") ="mail.bmc.com"' Enter the SMTP Server Port numberiConf.Fields("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25

Chapter 3 69


The PATROL KM for Event Management notification scripts have clearly marked sections where you can add scripting to support these notification types.

Testing Notification Scripts

Before you continue configuring the PATROL KM for Event Management, you should test your notification script to verify that e-mail and any other notification services are properly initiated.

To perform a test, run the appropriate notification script as shown in the following example:

The notification script arguments are described in Table 18.

NOTE You must supply the notification software. For example, you can use the notification script to issue a trouble ticket notification, but to actually create a trouble ticket, you must have a trouble ticket application, such as Remedy.

AS_EVSLocalAlertNotify.ext type “targets” “message”

NOTE Replace ext with the file extension of your notification script (bat, sh, or pl).

Table 18 Notification Script Arguments

Argument Description

type The notification type that you are testing. The following notification types are supported:

■ email–sends an e-mail notification■ page–sends a page notification■ tt–sends a trouble ticket notification■ custom–sends a custom notification

If you use the page, tt, and custom notification types, you must customize the notification script.

targets A comma-separated list of notification message recipients (e-mail addresses, page numbers, trouble-ticket inboxes, or custom addresses). Spaces within the list are converted to commas by the notification script.

message the notification or test message that is sent to the targets



The following example shows a test of the AS_EVSLocalAlertNotify.bat script on Windows:

Configuring Notification Servers

This section describes the purpose of a notification server and describes how to configure a server as a notification server.

To Configure a Notification Server

1 From the PATROL console, access the managed system you are using as your notification server and display the KM menu commands as described in “Accessing KM Commands and InfoBoxes” on page 212.

2 Choose the KM menu command Event Management => Quick Config => Notification Server.

The Quick Config - Notification Server dialog box opens as shown in Figure 3.

Figure 3 Quick Config - Notification Server Dialog Box

AS_EVSLocalAlertNotify.bat email "[email protected]" "This is a test."

NOTE You must use the PATROL KM for Event Management to complete this task. This functionality is not available in PATROL Configuration Manager. However, once you configure one notification server, you can use the PATROL Configuration Manager to copy your configuration to other notification servers.

Chapter 3 71


Use the Quick Config - Notification Server dialog box to specify the notification server properties. The notification server properties are described in Table 19:

3 Define the notification server properties and click Accept.

4 Repeat this task for the server you are using as the backup notification server.

Specifying Where to Send Notifications From

You can send notifications from the local machine on which the alerts occur or you can send notifications from a notification server. This setting is stored in the rule alertSystem and can be specific for each PATROL object. For example, you could send notifications locally for one parameter, while for another parameter you could forward the event to a notification server and configure the notification server to send the notification message.

To Specify Where to Initiate Notifications

1 For the agent that you want to configure, access the KM menu commands as described in “Accessing KM Commands and InfoBoxes” on page 212.

2 Choose the KM menu command Event Management => Alert Settings => Notification System.

Table 19 Quick Config - Notification Server Properties

Property Description

Default Email Account the default e-mail address (notification target) that receives e-mails when an object goes into an alarm or warning state

All events for PATROL objects that do not have defined notification targets are sent to this e-mail address. See “Configuring Recovery Actions” on page 120 for information on setting notification targets.

If you don’t want any notifications sent until you configure notification for specific PATROL applications or parameters, enter NONE as your default e-mail account or leave this field empty.

Notification Command the complete path and filename of the notification script or command used to send notifications

Perform Alert Test specifies whether you want to perform an alert test after the changes are accepted

If this is your first time using the PATROL KM for Event Management, you should perform an alert test and verify that the notifications are received.



3 Select the PATROL object (application, class, and parameter) that you want to configure. To configure all PATROL objects, select Set For Classes and then select /.

4 Select the appropriate alert options as described in Table 40 on page 163.

5 To save your changes, click Accept.

Configuring Remote Agents

You should assign a notification server for each remote agent that will generate notifications. Assign both a primary and a backup notification server.

Before You Begin

You should configure and test the notification servers before configuring the remote PATROL Agents served by the notification servers.

To Assign Notification Servers to Remote Agents

1 From the PATROL console, access the remote agent menu commands, as described in “Accessing KM Commands and InfoBoxes,”.

2 Choose the KM menu command Event Management => Quick Config => Remote Agent.

The Notification Server Settings dialog box opens as shown in Figure 4 on page 74.

NOTE Notification servers are not required. Remote agents can send their own notifications. However, there are considerable benefits to using notification servers. For more information, see “Why use a Notification Server?” on page 58.

NOTE You must use the PATROL KM for Event Management to complete this task. This functionality is not available in PATROL Configuration Manager. However, once you configure one notification server, you can use the PATROL Configuration Manager to copy your configuration to other notification servers. The configuration settings are stored in the following variables:

■ AS/EVENTSPRING/NOTIFICATION_SERVER1.defaultAccount (primary)■ AS/EVENTSPRING/NOTIFICATION_SERVER2.defaultAccount (backup)■ AS/EVENTSPRING/NOTIFICATION_SERVER1 (primary)■ AS/EVENTSPRING/NOTIFICATION_SERVER2 (backup)

Chapter 3 73


Figure 4 Notification Server Settings Dialog Box.

3 Click PRIMARY NOTIFICATION SERVER SETTINGS.

The Primary Notification Server Settings (Figure 5) is displayed.

Figure 5 Primary Notification Server Settings Dialog Box



Use the Primary Notification Server Settings dialog box to specify the properties of the primary notification server for the managed system. The properties are described in Table 20:

4 Define the primary notification server properties, and click Accept.

5 Click BACKUP NOTIFICATION SERVER SETTINGS.

Use the Backup Notification Server Settings dialog box to specify the properties of the backup notification server for the managed system. The properties are described in Table 20 on page 75.

6 Enter the backup notification server properties, and click Accept.

Repeat this task for each remote agent.

Table 20 Notification Server Properties


Notification Server Hostname

the hostname or IP address of the primary notification server for the selected managed system

To avoid DNS resolution problems, use the IP address.

Notification Server Agent Port

the port number of the notification server that the selected managed system will use

Notification Server User Name

the user name that the selected managed system will use to connect to the notification server

Notification Server Password

the password that the selected managed system will use to connect to the notification server

Verify Password verify the password that the selected managed system will use to connect to the notification server

Make Connection Persistent

indicates that the remote agent maintains a persistent connection with the notification server agent so that the remote agent does not need to create a new connection each time it sends an event to the notification server

You use the PATROL Configuration Manager to quickly configure all remote agents at one time. See the PATROL Configuration Manager User Guide for more information on the PATROL Configuration Manager.

Chapter 3 75


Configuring Alert Settings

The following section describes how to configure alert settings and includes the following tasks.

Specifying Where to Initiate Notifications

You can send notifications from the local machine on which the alerts occur or you can send notifications from a notification server. This setting is stored in the rule alertSystem and can be specific for each PATROL object. For example, you could send notifications locally for one parameter, while for another parameter you could forward the event to a notification server that sends the notification. For more information, see “Deciding Where to Place Rules” on page 61.

To specify Where to Initiate Notifications

1 From the PATROL console, access the host KM menu commands as described in “Accessing KM Commands and InfoBoxes” on page 212.

2 Choose the KM menu command Event Management => Alert Settings => Notification System.

3 Select the PATROL object (application, class, and parameter) that you want to configure. To configure all PATROL objects, select the menu command Set For Classes and then select / as shown in Figure 6 on page 77.

Topic Page

Specifying Where to Initiate Notifications 76

Preventing False Alerts 77

Changing the Number of Times Alerts are Resent 78

Defining Agent-to-Notification Server Protocol Settings 79



Figure 6 Selecting / to Represent all PATROL Objects

4 From the SET EVENT MANAGEMENT VARIABLE: alertSystem dialog box, select the appropriate alert option, described in Table 40 on page 163.


Preventing False Alerts

This procedure describes how to reduce the number of false alerts sent from the notification server to an enterprise console after an agent restart. For more general information on reducing the number of alerts, see “Too Many E-mail Alerts Are Being Generated” on page 201.

Why False Alerts Occur upon an Agent Restart

If an agent or an agent machine goes down, there may be outstanding events open at the enterprise console. These events can be considered false alerts because after the agent or the agent machine restarts, these events are no longer relevant. You can configure PATROL to determine which events are no longer relevant and close those events upon an agent restart. The settings for this option are stored in the rule alertResetOnInit.

Chapter 3 77


To Prevent False Alerts upon an Agent Restart


2 Choose the KM menu command Event Management => Alert Settings => Local Alert Settings => Send Reset on Init.

3 From the SEND RESET NOTIFICATION ON AGENT INITIALIZATION dialog box, select Yes.


The value of the variable /AS/EVENTSPRING/ALERT/alertResetOnInit is set to 1, which indicates that alerts are sent to close the open events.

Changing the Number of Times Alerts are Resent

This procedure describes how to change the number of times that alerts are resent if they remain in a warning or alarm state in consecutive polling periods. As with other PATROL KM for Event Management variables, you can configure this setting at the PATROL object level (application, instance, or parameter). This setting is stored in the rule alertResend.

To Change the Number of Times Alerts are Resent


2 Choose the KM menu command Event Management => Alert Settings => Local Alert Settings => Alert Resend.

3 Select the PATROL object (application, instance, or parameter) that you want to configure.

The SET EVENT MANAGEMENT VARIABLE: alertResend dialog is displayed.

4 In the ALARM Resends and WARN Resends fields, enter the number of times alarm alerts and warning alerts are resent.

To resend alerts continuously until the PATROL object is no longer in a warning or alarm state, enter –1.


The variable /AS/EVENTSPRING/ALERT/object/alertResend is updated.



Defining Agent-to-Notification Server Protocol Settings

This procedure describes how to define the protocol settings used by remote agents when performing the following activities:

■ sending NOTIFY events to the notification server■ checking the notification server for availability

These protocol settings are stored in the variable RemoteAgentCommSettings.

To Define Protocol Settings


2 Choose the KM menu command Event Management =>Alert Settings => Remote Alert Settings => Remote Comm Settings.

3 From the REMOTE AGENT COMMUNICATION SETTINGS dialog box, select the appropriate protocol settings, described in Table 21.


The variable /AS/EVENTSPRING/RemoteAgentCommSettings is updated.

Rewording Notification Messages

You can use the PATROL KM for Event Management to customize or reword notification messages. You can reword the default message that is used for all notification messages or you can reword the notification messages for a specific PATROL object. You can reword the message subject line and the body text.

Table 21 REMOTE AGENT COMMUNICATION SETTINGS dialog box

Setting Explanation

TCP/UDP Protocol protocol used for agent to notification server communication

UDP Timeout (ms) when using the UDP protocol, the length of time in milliseconds to wait for a response before retrying

UDP Retries when using the UDP protocol, the number of times to retry a failed communication

Chapter 3 79


Where Reworded Messages are Displayed

When you reword a notification message, the reworded message is displayed in an e-mail, a page, in an event that is sent to an enterprise console, or in some other type of custom notification. The notification format depends on how you configure the notification server to process notification events.

Where to Reword Notification Messages

You can reword messages at the notification server or at the remote agent. However, BMC Software recommends that you reword messages at the remote agent because this practice reduces the number of rules on the notification server and makes it easier to properly send messages to an enterprise console. For more information, see “Deciding Where to Place Rules” on page 61.

Including Subject Line Only

To include only a subject line, and no body, in the notification message, edit the notification script and change the value of the Send_Body variable to 0. By default, it is set to 1, which includes the message body in the notification message.

Message Length Limitations

When you reword messages, verify that the message length is within the limitations noted in Table 22.

Table 22 Message Length Limitations by Platform

Platform Message Length Limitations

Unix Subject line is limited to 100 characters. No known limit on the message body.

Windows No known limit on the subject line. Message body is limited to 2035 characters.

If limits are exceeded, the message is truncated.

AS/400 (iSeries)

When using the native SNDDST mail utility, the subject line is limited to 44 characters and the message body is limited to 5000 characters.

OpenVMS Subject line is limited to 80 characters. The message body is limited to 255 characters.

If limits are exceeded, message is not sent.



To Reword the Default Notification Message

1 From the PATROL console, access the host you are rewording the message for as described in “Accessing KM Commands and InfoBoxes” on page 212. The host may be the notification server or a remote agent.

2 Choose the KM menu command Event Management => Alert Settings => Alert Messages => Default Message Format.

The Set Event Management Alert Variables/Rules dialog box opens as shown in Figure 7:

Figure 7 Set Event Management Alert Variables/Rules Dialog Box

3 Enter your reworded message subject line and message body and then click Accept.

You can use a mix of variables and text to create a reworded message. For a description of the available message replacement variables, click MESSAGE REWORDING OPTIONS. For a complete description of the message replacement variables that are provided, see “NOTIFY_EVENT Fields” on page 157

If a Problem Occurs

■ In OpenVMS, the subject line is limited to 80 characters and message body is limited to 255 characters. If you exceed these limits, messages may not be sent.

■ If you don’t specify message body text, the message text that you enter for the message subject is also used for the message body.

■ Back slashes may be replaced with a front slash or a space on some platforms.

Chapter 3 81


Setting Notification Targets

You should set up specific targets for the PATROL KM for Event Management notifications to ensure that the proper people are notified when alerts occur. The following procedure describes how to set the notification target for a parameter alert.

To Set Notification Targets

1 From the PATROL console, access the host KM menu commands, as described in “Accessing KM Commands and InfoBoxes” on page 212.

2 Choose the KM menu command Event Management => Alert Settings => Notification Targets => Email => Local Targets ANY STATUS => Set For Parameters.

The Set Event Management KM Variables/Rules dialog box opens as shown in Figure 8.

Figure 8 Selecting Applications

3 Select the application class of the parameter and click Accept.

The Set Event Management KM Variables/Rules dialog box opens as shown in Figure 9 on page 83.



Figure 9 Selecting Application Instances

4 Select the application instance of the parameter, and click Accept.


Figure 10 Selecting Parameters

5 Select the parameter and click Accept.


Figure 11 Set Event Management Alert Variables/Rules Dialog Box

6 Enter the e-mail address of the target for this alert and click Accept.

Chapter 3 83


You can set other notification targets using the same procedure, but you choose a different menu command in Step 2. For example, you may choose Paging instead of Email.

If a Problem Occurs

If you specify multiple targets but only the first target receives the e-mail message, see “Cannot Send E-mail Notifications to Multiple Targets” on page 198.

For other problems, see Chapter 7, “Troubleshooting PATROL KM for Event Management”.

Testing Notification Rules

Before You Begin

Before using the What If? feature to test your notification rules, configure the agent as desired. Then, from the PATROL Configuration Manager, perform a get on the agent to obtain the latest configuration.

To Test Rules Using the What If? Feature

1 From the left pane of the PATROL Configuration Manager, right-click the remote agent or notification server that you want to test and choose the menu command Event Management => What If.

2 From the What If dialog box, click Browse and then select the parameter that you want to test.

3 In the Status field, select the event that you want to test (INFORMATION, WARN, or ALARM).

4 If necessary, specify the day of the week and the time. This may be necessary if you have configured blackout periods when notification is disabled.

5 To perform the test, Click OK.

You can use the What If? feature of the PATROL Configuration Manager to determine which rules are triggered when a parameter enters a specified state, such as ALARM or WARN. You can use this information to determine whether you have configured the notification rules correctly.



The What If Results dialog box is displayed as shown in Figure 12. It shows the rules that would be triggered and their associated values.

Figure 12 What If Results Dialog Box

Disabling Notification

You can disable, turn off, or limit notification using the instructions provided below. To disable notification for a finite period only and then enable it, use the blackout feature. For more information, see “Configuring Blackout Periods” on page 115.

To Disable all Notification

To disable all notification, use the following rule on the remote agent that is generating events: /AS/EVENTSPRING/arsAction = 0. You can use the PATROL Configuration Manager to create this rule.

To Disable Notification for Specific PATROL Objects

To disable notification for certain PATROL objects, such as an application class, set the arsAction rule to 0 only for that application class. For example, to disable notification for all parameters in the NT_CPU application class, use the following rule on the remote agent generating events: /AS/EVENTSPRING/NT_CPU/arsAction = 0. You can use the PATROL Configuration Manager to create this rule.

Chapter 3 85


To Disable Notification at the Notification Server

To disable notification at the notification server, you can set the alertSystem rule to NONE and then set it to LOCAL for those parameters for which you want to receive notifications. For more information on configuring the alertSystem rule, see “Specifying Where to Send Notifications From” on page 72.

Limiting Notifications by Adjusting Parameter Settings

If you are receiving too many notifications, review your e-mail messages (or pages) and adjust the parameter settings to stop the alerts that you don’t want to receive. You can accomplish this by adjusting the thresholds, deactivating threshold ranges, or deactivating parameters.

Overriding Rules

You can also limit notification by overriding a rule. For example, if you don’t want a remote agents to generate notify events, you can disable the arsAction rule on that remote agent.

To Override Rules

1 Access the host KM menu commands as described in “Accessing KM Commands and InfoBoxes” on page 212.

2 Choose the KM menu command Event Management => Alert Settings => Overrides.

3 From the Rule Override dialog box, select the PATROL KM for Event Management rule that you want to override.

The rules listed are the rules that are currently configured on the agent. For more information about the PATROL KM for Event Management rules, see Chapter 5, “Rules and Configuration Variables”.

4 Click Accept.

If you use the PATROL KM for Event Management to make these changes, you can make the change on one agent and then deploy the changes to all of your agents using the PATROL Configuration Manager. For more information about deploying settings using the PATROL Configuration Manager, see the PATROL Configuration Manager User Guide.


Configuring Availability Monitoring

Configuring Availability MonitoringThis section describes how to configure PATROL to monitor the availability of your notification servers and alert you when a notification server is down.

Configuring an Availability Monitor

An availability target defines a managed system, such as a notification sever, that is monitored for availability. In this task you specify an availability target for an availability monitor.

Before You Begin

You should define the availability monitor machines and the managed systems that you want to monitor for availability. For more information, see “Defining Availability Monitors and Targets” on page 60.

To Configure an Availability Monitor

1 From the PATROL console, access the KM menu commands of the managed system that you want to use as an availability monitor.

2 Choose the KM menu command Event Management => Availability => Add Target.

The Availability Monitor Add Target dialog box opens as shown in Figure 13 on page 88:

Chapter 3 87


Figure 13 Availability Monitor Add Target Dialog Box

Use the Availability Monitor - Add Target dialog box to specify the properties of the agent that you want to monitor for availability. Table 23 describes the availability target properties.

Table 23 Availability Target Properties (Part 1 of 2)


Hostname the host name or IP address of the managed system you are monitoring

To avoid DNS resolution problems, use the IP address.

PATROL Agent Port the port number of the PATROL Agent on the managed system that you are monitoring

SNMP Port the SNMP port number of the PATROL Agent on the managed system that you are monitoring

If you are using SNMP to monitor a managed system, the HostPingFailures parameter is not used and remains grayed out. Instead, the SnmpPingFailure parameter is used.

SNMP Community the SNMP community string of the managed system you are monitoring



3 Define the availability target properties and click Accept.

4 Repeat this task for each managed system you want to monitor for availability. For example, if you are using the availability monitor to monitor multiple notification servers, repeat this task for all notification servers.

Configuring a Backup Availability Monitor

Configuring Availability Failover

This procedure describes how to specify which availability monitor is the backup availability monitor.

SNMP Timeout the SNMP connection timeout for the managed system you are monitoring

SNMP Retries the number of times the PATROL Agent tries to connect to the managed system that you are monitoring before it fails

SNMP Object ID the SNMP object ID on the managed system that you are monitoring for availability

PATROL uses the SNMP object ID only when checking the availability of the remote agent on the managed system. It uses the object ID when making an SNMP call to the agent and checking for a response. You can use the default object ID or provide any other valid SNMP object ID.

You use the PATROL Configuration Manager to copy the availability monitoring settings to the other managed systems. For more information on the PATROL Configuration Manager, see the PATROL Configuration Manager User Guide.

Be sure that the machine you are using as the backup availability monitor has the same availability targets as the primary availability monitor. The easiest way to accomplish this is to use the PATROL Configuration Manager to copy the primary availability monitor settings to the backup availability monitor. For more information, see the PATROL Configuration Manager documentation. Alternatively, you can manually add the same targets to the backup availability monitor.

Table 23 Availability Target Properties (Part 2 of 2)


Chapter 3 89


Before You Begin

Before you configure availability monitoring failover, ensure that

■ you have configured the availability monitoring servers as described in “Configuring an Availability Monitor” on page 87.

■ each pair of machines that you want to configure as primary and backup availability monitors has the same availability targets.

To configure failover, you must access the machine that you want to use as the backup availability monitor, run the Identify Primary menu command, and then select the primary availability monitor. For more details, see the following procedure.

To Configure Failover

1 From the PATROL console, access the KM menu commands, as described in “Accessing KM Commands and InfoBoxes” on page 212, for the managed system that you want to use as the backup availability monitor.

2 Choose the KM menu command Event Management => Availability => Failover Settings => Identify Primary.

The Choose Primary Monitor dialog box opens as shown in Figure 14.

Figure 14 Choose Primary Monitor Dialog Box

3 Select the primary availability monitor and click Accept.

The following changes are made:

■ the managed system you selected in Step 3 is set as the primary availability monitor

■ the managed system that you executed the Identify Primary command from in Step 2 is set as the backup availability monitor



Configuring the Availability Monitor Agent

To make the availability monitor work effectively, you should apply the rules highlighted in Figure 15 to the availability monitor machine. These rules are provided with the PATROL Configuration Manager and are located in the Shipped\ESG\Availability folder. They perform the following functions:

■ preloads the AS_AVAILABILITY.km on the availability monitoring agent■ improves the ability of the availability monitoring agent to schedule pings

effectively. This feature is especially important if the availability monitor is monitoring a large number of agents.

Figure 15 Rules to Apply to the Availability Checker Agent

To Apply Rules to the Availability Monitor

1 Select (highlight) the rules shown in Figure 15 and move them to the availability monitor agent in the left pane. For example, the agent bhunter-HOU-0 in Figure 15.

2 Apply the rules to the agent by clicking the apply configuration icon .

Chapter 3 91


Specifying an Availability Monitoring Account

This procedure describes how to specify the account used by the availability monitor when checking the availability of PATROL Agents. This account is optional. If you don’t enter an account, the availability checker can still detect whether the PATROL Agent is available, but it generates an invalid login event at the PATROL Agent machine. If this is a concern in your environment, follow these steps to specify a valid account.

Before You Begin

The availability monitoring account that you specify must be valid on all of the agents that the availability monitor is configured to monitor. If you must use different accounts for different agents, you must configure multiple availability monitors.

To Specify an Availability Monitoring Account

1 From the primary availability monitor host, access the KM menu commands as described in “Accessing KM Commands and InfoBoxes” on page 212.

2 Choose the KM menu command Event Management => Availability => Checker Account.

3 From the CONFIGURE CHECKER ACCOUNT dialog box, enter the account used by the availability monitor. The account you enter is used for all availability targets.

4 To test whether the account is valid, enter the hostname and PATROL Agent port of one of the availability targets.

5 Click Accept.

PATROL displays a message in the console system output window indicating whether the test was successful.

6 Repeat steps 1-5 for the backup availability monitor.

NOTE You must use the PATROL KM for Event Management to complete this task. This functionality is not available in PATROL Configuration Manager. However, once you specify the account information for one availability checker, you can use the PATROL Configuration Manager to copy your configuration to other availability checkers.



If a Problem Occurs

If you receive invalid login events at the PATROL Agent machine, see “AgentLoginDenied Parameter is in Alarm” on page 203.

Changing the Ping Command Used for Availability Monitoring

This topic describes how to change the path to the ping command used by the availability monitor to check the availability of PATROL agent machines. You can also specify arguments for the ping command.

To Change the Ping Command used for Availability Monitoring

1 Access the availability monitor host menu commands as described in “Accessing KM Commands and InfoBoxes” on page 212.

2 Choose the KM menu command Event Management => Availability => Ping Command.

3 From the Set Ping Command dialog box, enter the absolute path to the ping command executable on the availability monitor machine.


The ping command is stored in the configuration variable pingCmd. To apply your changes to the PATROL Agent, you must restart the PATROL Agent.

To Specify Ping Command Arguments

Example

To use the following ping command, use the configuration variables described below:

You can append the ping command with arguments by specifying the arguments in the configuration variable pingArgs. To assign a value to this variable, you must use the PATROL Configuration Manager.

ping host -n 2 -|32

Chapter 3 93

Integrating with AlarmPoint

Example

To Specify Ping Command Arguments on OpenVMS

When defining ping commands on OpenVMS, use the host macro to represent host names.

Example

To use the following ping command, set the configuration variables described below:

Integrating with AlarmPointYou can use the PATROL KM for Event Management with the AlarmPoint products that provide a wide range of notification options: e-mail, paging, two-way paging, fax, and voice (phone).

BMC Software recommends AlarmPoint, but you could also choose to use any other enterprise paging software that can be called from a command line.

Configuration Variable Value Comments

pingCmd ping Depending on where you are executing the ping command from, you may have to also specify the full path to the ping command. For example, /usr/patrol/ping.

pingArgs -n 2 -| 32 None

ping abc.bmc.com -n 2 -l 32

ping -c 2 -s 99 host

Configuration Variable Value Comments

pingCmd ping None

pingArgs -c 3 -s 99 host This command syntax is defined below:

■ -c 3 — specifies 3 ping attempts■ -s 99 — specifies a ping packet size of 99 bytes■ host — a macro that inserts the actual host name



AlarmPoint Benefits

AlarmPoint selects the notification option based on the personal preferences of the recipients. For example, a user can configure AlarmPoint to send an e-mail message during normal working hours but send a voice notification during nights and weekends. By allowing AlarmPoint users to maintain their own contact and schedule information, AlarmPoint administrators are freed from maintaining this information.


To use AlarmPoint for notification, you configure the notification server to execute a script that calls the AlarmPoint java client. The java client then sends the notification request to the AlarmPoint server. For an overview of the notification process when using the PATROL KM for Event Management and AlarmPoint, see “Sending Pages using AlarmPoint: Process Flow” on page 21.

Configuration Overview

To integrate the PATROL KM for Event Management with AlarmPoint, you must complete the following steps:


1 Install AlarmPoint on a Windows server.

“Installing and Configuring AlarmPoint” 96

2 Configure AlarmPoint and define users (notification targets).

“Installing and Configuring AlarmPoint” 96

3 Install AlarmPoint java client. “Installing the AlarmPoint Java Client” 96

4 Configure AlarmPoint java client “Configuring the AlarmPoint Java Client” 96

5 Test the AlarmPoint Java client. “Testing the Java Client” 97

6 Download AlarmPoint scripts (only if using AlarmPoint 5.2.01).

“Using Action Scripts for AlarmPoint 5.2.01”

98

7 Configure notification. “Configuring Notification” 99

8 Test notification. “Testing Notification” 103

Chapter 3 95

Installing and Configuring AlarmPoint

To use AlarmPoint with the PATROL KM for Event Management, you must install AlarmPoint on a Windows server and define AlarmPoint users (notification targets) and their notification information, such as e-mail addresses, phone numbers, and schedules.

For detailed instructions on installing and configuring AlarmPoint, see the AlarmPoint User Guide and Manual available on the BMC Software support web site.

Installing the AlarmPoint Java Client

You must install the AlarmPoint java client on the notification server. Versions of the java client are available for both Windows and various Unix platforms. For more information about installing the AlarmPoint java client, see the AlarmPoint User Guide and Manual available on the BMC Software support web site.

Configuring the AlarmPoint Java Client

You must configure the AlarmPoint java client to communicate with the AlarmPoint server.

To Specify the AlarmPoint Server

1 On the notification server that has the java client installed, open the APAgent.xml file in a text editor.

2 Enter the IP address or host name of the primary AlarmPoint server in the address variable as show below in bold.

3 To apply your changes, restart the AlarmPoint java client.

You may need to configure other elements of the AlarmPoint java client service. For example, if you are using java client version 1.5, you may need to change the java client default restart properties. For more information, see the AlarmPoint User Guide and Manual available on the BMC Software support web site.

<?xml version="1.0" encoding="UTF-8" ?> - <alarmpoint-agent version="1.0">-  <server type="primary" address="172.23.0.26" />


Testing the Java Client

You can test the AlarmPoint java client to determine if it has access to the AlarmPoint server.

To Test the Java Client

From the notification server on which you installed the AlarmPoint java client, open a browser and enter the following URL. If the default port number was changed, replace 2010 with the port number you used.

http://localhost:2010/agent/status.html

The browser indicates the status of the connection to the AlarmPoint server. A successful connection appears as shown in Figure 16 on page 97.

Figure 16 Java Client Status Displayed in Browser

Chapter 3 97


If a Problem Occurs

If the AlarmPoint java client is unable to connect with the AlarmPoint server, verify that you entered the correct IP address or host name of the AlarmPoint server. Next, verify that you can ping the AlarmPoint server from the notification server.

Using Action Scripts for AlarmPoint 5.2.01

If you are using AlarmPoint 5.2.01, you need to download action scripts that enable integration with the PATROL KM for Event Management.

Downloading Action Scripts

Download the following scripts:

■ AP_PATROL_EmailActionScriptV521-01.ppx —AlarmPoint e-mail action script■ AP_PATROL_FaxActionScriptV521-01.ppx —AlarmPoint fax action script

If you are using AlarmPoint 5.2.02 or later, you don’t need to download these action scripts.

You can download the action scripts required for AlarmPoint 5.2.01 from the following locations:

Unix

ftp://ftp.bmc.com/pub/patrol/patches/PKM_Event_Management/2.5.00/UNIX/pkmforem_alarmpointv521.tar

Windows

ftp://ftp.bmc.com/pub/patrol/patches/PKM_Event_Management/2.5.00/NT/pkmforem_alarmpointv521.exe

Importing the Action Scripts for AlarmPoint 5.2.01

After you download and extract these scripts, you must import and promote them in the AlarmPoint server. For more information, see “Exporting and Importing Scripts and Recordings” and “Action Script Versions” in the AlarmPoint User Guide and Manual. This step is required only if you are using AlarmPoint 5.2.01.


ftp://ftp.bmc.com/pub/patrol/patches/PKM_Event_Management/2.5.00/UNIX/pkmforem_alarmpointv521.tar

ftp://ftp.bmc.com/pub/patrol/patches/PKM_Event_Management/2.5.00/NT/pkmforem_alarmpointv521.exe



The following section describes how to configure the notification server to issue notifications that are sent through the AlarmPoint server.

Using the Custom Notification Type

To use AlarmPoint, you must use the custom notification event type when configuring the PATROL KM for Event Management rules.

Using AlarmPoint Notification Scripts

To integrate with AlarmPoint, use the following AlarmPoint notification scripts that are provided with PATROL KM for Event Management:

■ AS_EVSLocalAlertNotifyAP.bat — PATROL KM for Event Management notification script for Windows

■ AS_EVSLocalAlertNotifyAP.sh —PATROL KM for Event Management notification script for Unix

Using PATROL KM for Event Management Notification Rules

The next step is to create PATROL KM for Event Management rules so that when a PATROL object enters an alarm state, the notification server calls the AlarmPoint notification script and passes a notification target that matches an AlarmPoint user ID. The rules you need are shown below:

■ /AS/EVENTSPRING/object/arsAction — use this rule to specify that notification is enabled for the PATROL object.

■ /AS/EVENTSPRING/ALERT/object/alertLocalCommand — use this rule to specify the path to the notification script on the notification server.

■ /AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsLocalALARM — use this rule to specify the ID of the AlarmPoint user or user group. This rule is a local target rule, rather than a remote target rule, because the rule is located on the notification server and the notification server is performing the notification. Thus, notification is performed locally.

NOTE You should backup and rename these scripts prior to configuring the notification server to use them. For more information about managing notification scripts, see “Using Notification Scripts” on page 64.

Chapter 3 99


In these rules, object refers to a PATROL object, which can be an application class, an application instance, or a parameter. For example, a PATROL object could be the NT_CPU\CPU_0\CPUprcrProcessorTimePercent parameter.

Before You Begin

Before you set the notification rules, you must define notification servers and assign notification servers to the remote agents. For more information, see “Configuring Notification Servers” on page 71 and “Configuring Remote Agents” on page 73.

To Set the arsAction Notification Rule

1 From the PATROL console, access the managed system you are using as the notification server and display the KM menu commands as described in “Accessing KM Commands and InfoBoxes” on page 212.

2 Choose the KM menu command Event Management => Alert Settings => Alert Actions => Set For Parameters.

3 From the next series of dialog boxes, choose the application class, instance, and parameter. For example, NT_CPU\CPU_0\CPUprcrProcessorTimePercent. After you choose the desired parameter, the dialog box shown in Figure 17 on page 101 is displayed.

You can set these rules using the PATROL KM for Event Management or the PATROL Configuration Manager. The following topics describe how to set the rules using the PATROL KM for Event Management. For more information on using the PATROL Configuration Manager, see the PATROL Configuration Manager User Guide.



Figure 17 SET EVENT MANAGEMENT VARIABLE:arsAction Dialog Box

4 From the SET EVENT MANAGEMENT VARIABLE: arsAction dialog box, verify that the following options are selected:

■ Trigger NOTIFY_EVENT (Perform Notification) — this option enables notification for the selected parameter.

■ Make persistent (update config db) — this option ensures that any changes you make on this dialog box persist after an agent restart.


The following configuration variable value is set to 4, which enables notification:

To Set the alertLocalCommand Notification Rule


2 Choose the KM menu command Event Management => Alert Settings => Local Alert Actions => Notification Command => Set For Parameters.

3 From the next series of dialog boxes, choose the same parameter selected in the previous task: NT_CPU\CPU_0\CPUprcrProcessorTimePercent.

/AS/EVENTSPRING/NT_CPU/CPU_0/CPUprcrProcessorTimePercent/arsAction

Chapter 3 101


4 From the SET EVENT MANAGMENT ALERT VARIABLE: alertLocalCommand dialog box, enter the full path name of the AlarmPoint notification script on the notification server computer. For example, /us/p/AS_EVSLocalAlertNotifyAP.sh.


The following configuration variable is set as /us/p/AS_EVSLocalAlertNotifyAP.sh:

To Set the customTargetsLocalALARM Notification Rule


2 Choose the KM menu command Event Management => Alert Settings => Notification Targets => Custom => Local TargetsALARM=> Set For Parameters.

3 From the next series of dialog boxes, choose the same parameter selected in the previous task: NT_CPU\CPU_0\CPUprcrProcessorTimePercent.

4 From the SET EVENT MANAGMENT ALERT VARIABLE: customTargetsLocalALARM dialog box, enter the ID of the AlarmPoint target, as shown in Figure 18.

Figure 18 SET EVENT MANAGEMENT ALERT VARIABLES/RULES Dialog Box


The following configuration variable is set as administrator:

/AS/EVENTSPRING/ALERT/NT_CPU/CPU_0/CPUprcrProcessorTimePercent/alertLocalCommand

/AS/EVENTSPRING/ALERT/NT_CPU/CPU_0/CPUprcrProcessorTimePercent/customTargetsLocalALARM



When the NT_CPU\CPU_0\CPUprcrProcessorTimePercent parameter enters an alarm state on the notification server or on any remote agent configured to send events to the notification server, the notification server calls the AlarmPoint notification script and passes the AlarmPoint ID (administrator). The AlarmPoint script calls the AlarmPoint server, which notifies administrator according to his or her AlarmPoint user settings. For example, an e-mail message may be issued during the day and a page at night.

Testing Notification

To verify that the notification rules are working correctly, you can set the PATROL object into an alarm state and verify that the notification is sent.

To Test Notification Using the setParameterValue Rule

You can set the value of a PATROL object using the setParameterValue rule.

1 Create the rule shown below:

2 Use the PATROL Configuration Manager to apply this rule to the agents that you want to test.

When you apply this rule to an agent, the rule assigns the parameter a value that is within the specified alarm range. This action causes an alarm condition and generates an alert.

To Test Notification Using a PSL Command

You can also use a PSL command to set a parameter value and generate an alert. When the default parameter thresholds are being used, the following command causes the CPUprcrProcessorTimePercent parameter to generate an alert:

If a Problem Occurs

If the notification is not sent when the parameter enters an alarm state, see Chapter 7, “Troubleshooting PATROL KM for Event Management”.

"/AS/EVENTSPRING/setParameterValue" = { REPLACE = "/NT_CPU/CPU_0/CPUprcrProcessorTimePercent=ALARM" }

%PSL set("/NT_CPU/CPU_0/CPUprcrProcessorTimePercent/value",99);

Chapter 3 103

Managing Parameter Thresholds and Poll Times


You can use the PATROL KM for Event Management to set PATROL parameter thresholds and poll times for any parameter on a managed system. By default this ability is enabled.

Benefits of Using the PATROL KM for Event Management

To Set Parameter Thresholds Using the PATROL KM for Event Management


2 Choose the KM menu command Event Management => Parameter Settings => Thresholds.

3 From the next series of dialog boxes, choose the application class, application instance, and parameter. After you choose the desired parameter, the Configure Thresholds dialog box is displayed as shown in Figure 19 on page 105.

When you set parameter thresholds using the PATROL KM for Event Management, the thresholds are stored in agent configuration variables, not in the KM files. This feature makes upgrades easier since your thresholds are stored externally to the KM files. It also allows you to define the settings on one agent and use the PATROL Configuration Manager to deploy the settings throughout your environment.

In addition, if a KM is committed to an agent whose thresholds are being set through the PATROL KM for Event Management, the thresholds stored in the agent configuration variables are reapplied to the agent. This action prevents the PATROL KM for Event Management thresholds from being overwritten.

NOTE When you make thresholds changes using the PATROL KM for Event Management, these changes are not reflected in the console display because the changes are made at the agent, not in the console KM files.



Figure 19 Configure Thresholds Dialog Box

4 Use the Configure Thresholds dialog box, described in Table 24, to specify the properties of the selected objects threshold settings and then click Accept.

Table 24 Threshold Setting Properties (Part 1 of 2)


Active indicates that the parameter is active and the settings in the dialog box represent the current parameter settings

Border Range To enable the border range, click Enable. If you enable the border range, you must also specify border action properties on the Border Actions tab.

Enable the border range if it is possible for the parameter to return a value outside of the other alarm range limits. You can use this for information only or as a third-level alert condition representing either a warning or an alarm state.

Chapter 3 105


If a Problem Occurs

If a problems occurs, see “Parameters Setting Lost After Agent Restart” on page 206.

Alarm Range 1 To enable Alarm1, click Enable and then specify a minimum and maximum range. Use Alarm1 as a first-level alert condition representing either a warning state or an alarm state. Alarm1 values:

■ must be less than Alarm2 values■ cannot overlap the Alarm2 range■ cannot fall outside the range limits or border range

Alarm Range 2 To enable Alarm2, click Enable and then specify a minimum and maximum range. Use Alarm2 as a second-level alert condition representing either a warning state or an alarm state. Alarm2 values:

■ must be greater than Alarm1 values■ cannot overlap the Alarm1 range■ cannot fall outside the range limits or border range

Enable makes the range active

Alert State ■ Click OK when the result of the range breach is informational for users or non-critical (for example, back up a file when it exceeds a certain size).

■ Click Warning or Alarm to have the parameter undergo a state change when the range is breached.

Min minimum value of acceptable range

Max maximum value of acceptable range

Trigger Alarm determines when an alarm is triggered and can be one of the following values:

■ After an alarm has occurred “n” times — Use this value to discount random spikes in the return values. You must also specify how many consecutive times the alarm range can be breached before the parameter alarms.

■ Immediately on alarm — Use this value if the value returned is of concern.■ After all recovery actions fail — Use this value if you want to be alerted after all

recovery actions fail and the returned value remains within the warning or alarm range.

N If you selected After an alarm has occurred “n” times for the trigger alarm, specify how many consecutive times you want the alarm value returned during parameter execution before the parameter actually alarms.

Apply to current session

makes the selected parameter thresholds apply to the current session

Make persistent

makes the selected parameter thresholds persist after the console is disconnected

Table 24 Threshold Setting Properties (Part 2 of 2)




Setting Collector Poll times

This procedure describes how to set parameter poll times using the PATROL KM for Event Management.

Before You Begin

■ Before you set collector poll times, determine which application class the standard or collector parameters reside in.

■ The collector must be active. If the collector is not active, it is not shown in the list of selectable collectors.

To Set Collector Poll times


2 Choose the KM menu command Event Management => Parameter Settings =>Polltimes.

3 Choose the application class and instance for the standard or collector parameter.

4 From the SET EVENT MANAGEMENT VARIABLE: interval dialog box, enter the new poll time and then click Accept.

Using Wildcards to Represent PATROL Instance Names

When you set up parameter threshold or poll time rules, you may want to create one rule that matches several PATROL instances. For example, you may want to create a parameter threshold rule for any process that contains the letters WIN. You can do this using wildcards.

PATROL KM for Event Management uses the following set of characters to identify a wildcard: {re:*}.

For more information, see the following example.

Wildcard Usage Matches No Match

CPU_{re:*} CPU_03CPU_13HoustonCPU_03

CP_1CPU14

Chapter 3 107


Requirements for Using Wildcards

The following usage rules apply to wildcards:

■ You can use a wilcard only to represent PATROL instance names. You cannot use wildcards to represent host names, parameter names, or any other PATROL object.

■ You can use wildcards only in threshold and poll time rules. You cannot use wildcards in notification rules.

■ You can use only one wildcard in an expression.

■ You cannot use wildcards to specify the beginning or ending of an instance name. For example, CPU_{re:*} matches both HoustonCPU_03 and CPU_03.

■ Rules that use explicit instance names take precedence over rules that contain wildcard matches.

■ Rules that contain wildcard matches take precedence over rules that use the __ANYINST__ variable to represent any instance name.

For more information, see the examples shown in Table 25.

Table 25 Wildcard Usage in Threshold Rules: Examples

Processes Running on the Host Rules Result

■ msdtc■ svchost■ msv

Rule #1: /AS/EVENTSPRING/PARAM_SETTINGS/THRESHOLDS/NT_PROCESS/__ANYINST__/PROCSTATUS

Rule#2:/AS/EVENTSPRING/PARAM_SETTINGS/THRESHOLDS/NT_PROCESS/pat{re:*}/PROCSTATUS

Since rule #2 did not match any of the processes running on the host, rule #1 is applied to all of the instances on the host.

■ msdtc■ svchost■ msv

Rule#1:/AS/EVENTSPRING/PARAM_SETTINGS/THRESHOLDS/NT_PROCESS/msdtc/PROCSTATUS

Rule #2:/AS/EVENTSPRING/PARAM_SETTINGS/THRESHOLDS/NT_PROCESS/ms{re:*}/PROCSTATUS

Since rule #1 is an exact match for a process that is running on the host, it takes precedence over rule #2.



Activating and Deactivating Parameters

Using the PATROL KM for Event Management, you can perform the following parameter configurations:

■ deactivate (make inactive) parameters that are active by default in the KM■ activate (make active) parameters that are inactive by default in the KM

Deactivating Parameters that are Active by Default in the KM

When deactivating parameters that are active by default in the KM, you can deactivate a single instance of a parameter or all instances of a parameter. You can also use the PATROL Configuration Manager to apply this setting globally across your enterprise.

To Deactivate a Single Instance of a Parameter



3 From the next series of dialog boxes, choose the application class, application instance, and parameter.

After you choose the desired application, instance, and parameter, the Configure Thresholds dialog box is displayed as shown in Figure 19 on page 105.

4 From the Configure Thresholds dialog box, deselect the Active checkbox.

5 To save the threshold properties, click Accept.

To Deactivate all Instances of a Parameter



Chapter 3 109


3 From the next series of dialog boxes, choose the application class, application instance, and parameter. To deactivate all instances of a parameter, select <all instances> from the instances dialog box. When you select <all instances>, the __ANYINST__ variable is used to represent any instance of the parameter.


4 From the Configure Thresholds dialog box, deselect the Active checkbox.


The following agent configuration variable is created:

where application class and parameter represent the application class and parameter that you chose to deactivate.

If a Problem Occurs


Activating Parameters that are Inactive by Default in the KM

When activating parameters that are inactive by default in the KM, you can activate a single instance of a parameter or all instances of a parameter. You can also use the PATROL Configuration Manager to apply this setting globally across your enterprise.

To Activate a Single Instance of a Parameter



AS/EVENTSPRING/PARAM_SETTINGS/THRESHOLDS/application class/__ANYINST__/parameter

To apply this rule to other servers in your enterprise, use the PATROL Configuration Manager. For more information, see the PATROL Configuration Manager User Guide.



3 From the next series of dialog boxes, choose the application class, application instance, and parameter.


4 From the Configure Thresholds dialog box, select the Active checkbox.


To Activate all Instances of a Parameter

1 From the PATROL Configuration Manager or the Wpconfig utility, set the agent configuration variable AS/EVENTSPRING/processWildcards to a value of 1.

2 Create the following rule, using a wildcard symbol, {re:*}, to represent the instance name.

3 Assign the rule the desired value. For more information on the syntax of the THRESHOLDS rule, see “THRESHOLDS” on page 186.

If a Problem Occurs


Applying Thresholds and Poll Time Changes to the Agent

If you use the PATROL KM for Event Management to change parameter thresholds and poll times and you want to apply the changes to the agent without waiting until the agent restarts, set the value of the following configuration variable to 2, 4, or 6:

AS/EVENTSPRING/PARAM_SETTING/THRESHOLDS/application class/{re:*}/parameter name

To apply this rule to other servers in your enterprise, use the PATROL Configuration Manager. For more information, see the PATROL Configuration Manager User Guide.

/AS/EVENTSPRING/PARAM_SETTINGS/STATUSFLAG/paramSettingsStatusFlag

Chapter 3 111

Specifying What to Monitor or Exclude from Monitoring

Then, the next time the AS_EVENTSPRING parameter RefreshParamSettings runs, it applies the changes and set this variable back to 1. For more information on the paramSettingsStatusFlag variable, see “paramSettingsStatusFlag” on page 188.

Disabling the use of PATROL KM for Event Management Thresholds and Poll Times

If you disable the use of PATROL KM for Event Management parameter thresholds and poll times, you must restart the agent after disabling to ensure that the default KM parameter settings are used.

To Disable PATROL KM for Event Management Thresholds and Poll Times

In this task, you change the threshold for all instances of a PATROL parameter.


2 Choose the KM menu command Event Management => Parameter Settings => Status Flags.

3 From the SET EVENT MANAGEMENT VARIABLE: paramSettingsStatusFlag dialog box, select No to disable PATROL KM for Event Management parameter settings.

4 To save your changes, select Yes.

5 To apply your changes to the PATROL Agent, restart the PATROL Agent.


This section describes how to use the PATROL KM for Event Management to specify which KM application instances to monitor or exclude from monitoring.

Selecting Application Instances to Monitor

To monitor only a few instances and exclude most instances from monitoring, perform the following steps:



1. Add the instances that you want to monitor to an exclude filter.

2. Change the exclude filter to an include filter.

This method is not intuitive but it may be faster than adding all of the instances that you don’t want to monitor to an exclude filter.

Instance monitoring settings are stored in the following agent configuration variables:

■ AgentSetup/ApplicationClass.FilterList Configuration Variable■ AgentSetup/ApplicationClass.FilterType Configuration Variable

To Add Instances You Want to Monitor to an Exclude List (Temporarily)


2 Choose the KM menu command Event Management => Instance Filtering => Edit Filter List.

3 Choose the application class.

4 From the EDIT INSTANCE FILTER LIST dialog box, select Remove and click OK.

5 From the Instance Filter List dialog box, select the application instances that you want to monitor and then click OK.

To Change the Exclude List to an Include List


2 Choose the KM menu command Event Management => Instance Filtering => Change Filter Type.

3 Choose the application class you previously configured in “To Add Instances You Want to Monitor to an Exclude List (Temporarily)” on page 113.

4 From the CHANGE FILTER TYPE dialog box, for the option Change Filter Type to include, select Yes and then click OK.

Chapter 3 113


The filter is changed to an include filter.

To Verify Your Configuration

To verify that the filter is working as you expect, you can generate a report that shows which instances are being monitored.


2 Choose the KM menu command Event Management => Instance Filtering => Filtered Instance Report.

PATROL displays a report in the console system output window that shows the following information:

■ which application classes have filters defined■ the type of filter (include or exclude)■ the application instances in the filter

Excluding Application Instances from Monitoring

This procedure describes how to exclude selected KM application instances from monitoring. This setting is stored in the PATROL KM for Event Management variable filterList.

PATROL automatically monitors application instances that are discovered. If you don’t want to monitor a particular application instance, you need to add it to the exclude filter.

To Exclude Instances from Monitoring


2 Choose the KM menu command Event Management => Instance Filtering => Edit Filter List.

NOTE PATROL monitors only the instances in the include filter. It does not monitor instances that are discovered after you create the filter. To monitor a new instance, you must add it to the include filter.


Configuring Blackout Periods

3 Choose the application class whose instances you want to exclude from monitoring.

4 From the EDIT INSTANCE FILTER LIST dialog box, select Remove and click OK.

5 From the Instance Filter List dialog box, select the application instances that you want to exclude from monitoring and then click OK.

PATROL adds the selected instance to the exclude filter. It is no longer monitored.

To Verify Your Configuration

To verify that the exclude filter is working as you expect, you can generate a report that shows which instances are being monitored.


2 Choose the KM menu command Event Management => Instance Filtering => Filtered Instance Report.

PATROL displays a report in the console system output window that shows the following information:

■ which application classes have filters defined■ the type of filter (include or exclude)■ the application instances in the filter

Configuring Blackout PeriodsYou can use the PATROL KM for Event Management to set blackout periods for PATROL objects (parameters or application classes) and availability targets. During blackout periods, PATROL objects do not generate notifications and availability targets are not monitored for availability. This section describes how to set a blackout period for a PATROL object and an availability target.

TIP To monitor only a few instances and exclude most instances from monitoring, you can add those instances that you want to monitor to an exclude list and then change the exclude list to an include list. This method may be faster than adding all of the instances that you don’t want to monitor to an exclude list. For more information, see “Selecting Application Instances to Monitor” on page 112.

Chapter 3 115


About Notification Blackout Periods

Blackout periods are set to prevent notification from taking place during a specified time period even if an alert condition occurs. Multiple blackout times per day are allowed.

When you set blackout periods for PATROL objects using the PATROL KM for Event Management, the data for the PATROL object is still collected and the history is maintained. However, if the PATROL object enters an alarm state and generates an alert, notification does not occur.

Blackout periods can be applied to most PATROL objects. Blackout periods can be defined locally at the system where the alert occurs and at the notification server.

Local Blackout Periods

If you define a blackout locally at the managed system, alerts are generated at the managed system but they are not forwarded to a remote notification server.

Notification Server Blackout Periods

If you define a blackout period at the notification server, the managed systems continue to forward alert events to the notification server, but the notification server does not perform notification.

Configuring Notification Blackouts

You can set a notification blackout for any PATROL object. The following procedure describes how to set a notification blackout for an application class.

To Set a Notification Blackout for an Application Class


2 Choose the KM menu command Event Management => Alert Settings => Blackout Periods => Set For Classes.

The Choose the Target Classes dialog box opens as shown in Figure 20 on page 117.



Figure 20 Choose the target classes Dialog Box

3 Select an application class and click Accept.

The Set Event Management Blackout Variables/Rules dialog box opens as shown in Figure 21.

Figure 21 Set Event Management Blackout Variables/Rules Dialog Box

Chapter 3 117


Use the Set Event Management Blackout Variables/Rules dialog box to specify the blackout properties for the selected application class. The blackout properties are described in Table 26.

Example

To set a blackout from Friday at 19:00 pm until Sunday at 9:00 requires you to create three blackout periods and merge them as you create each one:

1. Blackout Start Time -->19:00:00 Blackout Stop Time --> 23:59:59Blackout Days-->Fri

2. Blackout Start Time -->00:00:00 Blackout Stop Time --> 23:59:59Blackout Days-->Sat

3. Blackout Start Time -->00:00:00 Blackout Stop Time --> 09:00:00Blackout Days-->Sun

4 Define the blackout properties, and click Accept.

You can set blackout periods for other PATROL objects by selecting the Set for Instances or Set for Parameter menu command in Step 2.

Table 26 Blackout Properties


Blackout Start Time the blackout start time

Blackout End Time the blackout end time

Blackout Days the days that you would like the blackout to occur

Merge Selected Blackout Periods with Pre-Existing Settings

merges the current blackout out period with existing blackout periods for this object

Replace Existing Blackout Periods with Current Selection

replaces all existing blackout periods with the defined blackout period



Configuring Availability Blackouts

You can set an availability blackout period, during which availability monitoring is not performed. You may want to create an availability monitoring blackout period to prevent managed systems from being monitored when they are undergoing regularly scheduled maintenance.

To Configure Availability Monitoring Blackouts


2 Choose the KM menu command Event Management => Availability => Blackout Periods.

The Set Event Management Blackout Variables/Rules dialog box opens as shown in Figure 22.

Figure 22 Set Event Management Blackout Variables/Rules Dialog Box

3 Select one or more targets and then click Accept.

The Set Event Management Blackout Variables/Rules dialog box opens as shown in Figure 23 on page 120.

Chapter 3 119

Configuring Recovery Actions

Figure 23 Availability Monitor Add Target Dialog Box

Use the Set Event Management Blackout Variables/Rules dialog box to specify the blackout properties for the selected application class. The blackout properties are described in Table 26 on page 118.

4 Define the blackout period properties, and click Accept.

Configuring Recovery ActionsThis section describes how to configure PATROL KM for Event Management recovery actions. These recovery actions are executed at the PATROL Agent and are associated with a PATROL object status change, such as a parameter going from an OK state to an ALARM state.

NOTE The availability blackout options do not include the option to merge the blackout periods.



About Recovery Actions

The PATROL KM for Event Management recovery actions are distinct recovery actions that are unrelated to the recovery actions you can define in a KM using the PATROL Console for Windows or the PATROL Console for Unix. For the sake of discussion, the recovery actions that you define in the KM using the PATROL console are referred to as PATROL native recovery actions. The following sections explain the differences between PATROL native recovery actions and PATROL KM for Event Management recovery actions.

PATROL Native Recovery Actions

When you define PATROL native recovery actions in the PATROL console, you associate the recovery actions with alarm and border ranges. These recovery actions run when the PATROL parameter value enters the specified range. The parameter may be in an OK, WARN, or ALARM state when the recovery action runs, depending on how you configure the parameter.

PATROL KM for Event Management Recovery Actions

Unlike PATROL native recovery actions, the PATROL KM for Event Management Recovery actions run only when a parameter changes status. For example, when a parameter goes from an OK state to a WARN or ALARM state, or even when a parameter goes from an ALARM to an OK state.

If you don’t want the parameter to alarm until recovery actions have been attempted, you must use PATROL native recovery actions, rather than PATROL KM for Event Management recovery actions. However, you can use both types. For example, you could define PATROL native recovery actions and specify that the parameter enters a WARN or ALARM state only after all recovery actions fail. Then you could create a PATROL KM for Event Management recovery action that runs only if the PATROL native recovery actions fail.

Enabling PATROL KM for Event Management Recovery Actions

Before configuring PATROL KM for Event Management to execute a PATROL KM for Event Management recovery action for a PATROL object, verify that the recovery action is enabled for that object. To execute recovery actions, the PATROL KM for Event Management rule arsAction must be set to 2, 4, or 6. For more information about arsAction, see “arsAction” on page 161.

To use the PATROL KM for Event Management interface to set the value of ArsAction (and enable recovery actions), use the following procedure.

Chapter 3 121


To Enabled Recovery Actions


2 Choose the KM menu command Event Management => Alert Settings => Alert Actions.

3 Select the PATROL object (application, instance, or parameter) that you want to configure.

The SET EVENT MANAGEMENT VARIABLE: arsAction dialog box is displayed.

4 To allow recovery actions to be associated with this PATROL object, select Allow Recovery Actions.

5 To enable notification for this PATROL object, select Trigger NOTIFY_EVENT.

6 If you want your changes to apply only until the agent is restarted, select Apply to current session. To apply your changes to future sessions, select Make persistent.

7 To save your settings, click Accept.

Recovery actions are enabled for WARNING and ALARM events. To enable recovery actions for INFORMATION events, you must set the configuration variable allowInfoRecoveryActions to 1.

Specifying a Recovery Action Script

This procedure describes how to specify the recovery action script.

Before you begin

Before specifying a recovery action script, you should have completed the following steps:

■ Configured the PATROL KM for Event Management to allow recovery actions. For more information, see “Enabling PATROL KM for Event Management Recovery Actions” on page 121.

■ Specified the type of recovery action command (arsCmdType). For more information, see “Specifying a Recovery Action Command Type” on page 123.

■ Created and tested a recovery action script. For more information, see “Using PSL Recovery Actions” on page 124.



■ On the PATROL Console, open the agent system output window so that you can view any status messages generated during this procedure.

To Specify a Recovery Action Script


2 Choose the KM menu command Event Management => Alert Settings => Local Alert Settings => Recovery Action Commands.

3 Choose the application class, instance, or parameter that you want to associate with the recovery action.

The SET EVENT MANAGEMENT VARIABLE: arsCommand dialog box is displayed.

4 From the SET EVENT MANAGEMENT VARIABLE: arsCommand dialog box, enter the full path and file name of the recovery action script.


PATROL displays a message in the console system output window indicating if the script was found.

Specifying a Recovery Action Command Type

To execute a recovery action, you must specify a command type. You can specify the command type for all PATROL objects or for any individual PATROL application, instance, or parameter. If all of your recovery actions are of one type, for example PSL, you should specify that command type for all PATROL objects, as shown in Step 4 in the procedure below.

The command type is stored in the rule arsCmdType. For more information about the arsCmdType rule, see “arsCmdType” on page 168.

To Specify a Recovery Action Command Type


2 Choose the KM menu command Event Management => Alert Settings => Local Alert Settings => Recovery Action Command Type.

Chapter 3 123


3 Choose the application class, instance, or parameter that you want to associate with the recovery action. To select all PATROL objects, select Set For Classes and then choose the forward slash /.

4 From the SET EVENT MANAGEMENT VARIABLE: arsCmdType dialog box, enter the command type.

PATROL has two built-in command types: PSL and OS. If you use a command type other than PSL or OS, the command type must be defined for the application class. For more information on defining command types, see the PATROL console documentation.


In addition to specifying the command type, you need to specify the full path and file name of the recovery action script. For more information, see “Specifying a Recovery Action Script” on page 122.

Using PSL Recovery Actions

If you use PSL recovery actions, you can use the PATROL KM for Event Management variables shown in Table 27 in your recovery action. Each variable contains a double underline (__) at the beginning and end of the variable name.

Table 27 PATROL KM for Event Management Variables

Variable Description

__appl_class__ application class name

__param__ parameter name

__param_status__ parameter status (ALARM, WARN, OK)

__param_value__ parameter value

__instance__ instance name

__src_event_id__ Source event id. This is the event ID of the event that began the notification process, typically a threshold exceeded event (Standard Event 9, 11 or 39).

__nfile__ A generated file that a PSL recovery action can write output to. The file name appears as the AS_NOTIFICATION_FILE environment variable in your notification script. You do not need to write to this file directly. You can also use the __output__ variable, described below.



Getting Host Information

To obtain other information, such as hostname or IP address, you need to use a get() command. For example, to get the hostname, use the following command:

For more information about using PSL, see the PATROL PSL documentation.

__output__ When you assign a value to this variable, the data is automatically saved to the notification output file, __nfile__. This file name is accessible from the notification script as the environment variable AS_NOTIFICIATION_FILE.

__udefvar__ When you assign a value to this variable, the variable is automatically assigned to the message replacement token %USERDEFINED% and the environment variable AS_USERDEFINED, which is accessible to the notification script. For an example of how to use this variable, see “Sending E-mail Notification for CPU Usage that Includes Parameter Annotations” on page 140.

hostn = get("/hostname");

Table 27 PATROL KM for Event Management Variables

Variable Description

Chapter 3 125

C h a p t e r 4
4 Usage Scenarios
The following section contains typical scenarios for using the PATROL KM for Event Management and the PATROL Configuration Manager. Detailed instructions are included. The following scenarios are described.

Sending E-mail Notification When Disk Space is Low . . . . . . . . . . . . . . . . . . . . . . . . 128Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Selecting a Mail Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Loading the PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . . . . 130Defining the Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Configuring the Remote Agent NT1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Specifying an E-mail Target for Low Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . 135Rewording the Notification Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Testing Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Sending E-mail Notification for CPU Usage that Includes Parameter Annotations 140Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Overview of Annotated Data Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Enabling Recovery Actions and Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Creating Recovery Action Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Creating Notification Command Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Testing Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Configuring a Recovery Action that Runs Under a Specified Account. . . . . . . . . . . 144Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Testing Recovery Action Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Enabling Recovery Actions for ArchFreeSpace on Agent Computer . . . . . . . . . 146Defining the Recovery Action Type for Agent Computer . . . . . . . . . . . . . . . . . . 146Storing the Encrypted Password as a Pconfig Variable. . . . . . . . . . . . . . . . . . . . . 147Configuring the PSL Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Summary of Rules Created . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Testing the Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Chapter 4 127

Sending E-mail Notification When Disk Space is Low


You may want to configure e-mail notification when a PATROL parameter goes into a warning or alarm state. For example, if disk space is low, you may want to send an e-mail message to the storage administrator.

In the following scenario, PATROL is running on two Solaris computers and three Windows Servers computers, as shown in Figure 24. You will configure the Solaris computers, NS1 and NS2, to send e-mail notification when the disk space is low on the Windows Servers computers.

To achieve this goal, you will configure the Solaris computers as notification servers and the Windows Servers computers as remote agents.

Figure 24 Network Configuration

Assumptions

For this scenario, assume the following:

■ A PATROL console is running on NT1. This console is connected to all of the servers shown in Figure 24. This console could be any of the following consoles: PATROL Developer Console, PATROL Central Operator - Windows Edition, PATROL Central Operator - Web Edition. You could also use a PATROL Operator Console if you applied the rule allowOperator.

PrimaryNotification Server

NS1

BackupNotification Server

NS2

NT1 NT2 NT3



■ The PATROL KM for Event Management and the PATROL KM for Windows OS are installed on all of the remote agent and notification server computers.

■ There is a dedicated PATROL agent for each notification server. This is the BMC Software recommended configuration.

■ All PATROL Agents used for monitoring are running on port 3181.

■ Except where otherwise noted, you will use the PATROL KM for Event Management to create and configure the notification rules. For some tasks, you could also choose to use the PATROL Configuration Manager to create and configure rules. For more information, see Table 28 on page 129.


To configure e-mail notification for low disk space, you complete the following tasks. The table below shows the location in which step is completed. An alternative location is also noted. For example, many of the configuration tasks can be completed within either the PATROL KM for Event Management or the PATROL Configuration Manager.

Table 28 Sending E-mail Notification for Low Disk Space: Configuration Overview

Step Task PATROL Product Alternative PATROL Product

1 Selecting a Mail Client NA NA

2 Loading the PATROL KM for Event Management

PATROL console None

3 Defining the Notification Servers PATROL console - (PATROL KM for Event Management)

None

4 Configuring the Remote Agent NT1

PATROL console - (PATROL KM for Event Management)

None

5 Copying notification server settings to NT2 and NT3

PATROL Configuration Manager

None

6 Specifying an E-mail Target for Low Disk Space



7 Copying e-mail targets from NS1 to NS2


None

8 Rewording the Notification Messagee



9 Copying reworded notification message rule from NS1 to NS2


None

10 Testing Notification PATROL console or PATROL Configuration Manager

None

Chapter 4 129


Selecting a Mail Client

You can use any e-mail client that has a command-line interface such as Unix mailx or Blat (shareware) for Windows. For Windows, the PATROL KM for Event Management provides MAPI and SMTP Visual Basic (VB) scripts that are called from the notification script.

Since the notification severs are Unix computers, the recommended approach is to use the default notification script, which sends mail using the built-in Unix mail client, mailx. If the notification servers were Windows computers, you would need to edit the notification script to enable the appropriate mail client. For Unix servers, no editing is required. For more information, see “Using Notification Scripts” on page 64.

Loading the PATROL KM for Event Management

You must load the PATROL KM for Event Management on a PATROL Developer Console that has all of the PATROL Agents defined.

To Load the PATROL KM for Event Management

1 From server NT1, start the PATROL console.

2 From the console main menu, load the EVENT_MANAGEMENT.kml as described in “Loading Knowledge Modules” on page 52.

Defining the Notification Servers

In this task, you configure the Solaris computers, NS1 and NS2, as your primary and backup notification servers.

You must use the PATROL KM for Event Management to complete this task.

To Define NS1 as the Primary Notification Server

1 From the PATROL console on NT1, right-click NS1 and access the KM menu commands as described in “Accessing KM Commands and InfoBoxes” on page 212.

2 Choose the KM menu command Event Management => Quick Config => Notification Server.



The QUICK CONFIG - NOTIFICATION SERVER dialog (Figure 25) is displayed.

Figure 25 QUICK CONFIG - NOTIFICATION SERVER Dialog Box

3 Enter the default e-mail account that receives notifications for all events that go into an alarm or warning state. For this example, use [email protected] as the default e-mail account. Later, you will define the e-mail target for our specific event: low disk space.

The default e-mail account acts as a catch-all for events that don’t have a specific e-mail target associated with them. Typically, when e-mail notifications are sent to the default e-mail account, you determine whether the event is valid and requires notification. If it is valid, you would associate the appropriate e-mail target to that event. For example, if the event was related to Microsoft Exchange, you would assign the e-mail target to the Microsoft Exchange administrator. If the event is not valid or is not important, you would adjust the alarm thresholds or possibly deactivate the parameter that spawned the event.

4 Enter the file name of the script that is run for event notification.

To prevent the notification script from being overwritten during upgrades or new installations, make sure you have copied the notification script from the directory in which it is installed to another directory outside of the BMC Software directory structure. For more information, see “Using Notification Scripts” on page 64.

5 Click Accept.

6 Repeat Steps 1 to 6 for NS2, the backup notification server.

In this example, NS1 is the primary notification server for all of the monitored agents. However, you could configure NS1 as the primary notification sever for some of the remote agents and as the backup notification server for the other remote agents.

Chapter 4 131


Configuring the Remote Agent NT1

In this step, you assign notification servers to the Windows Servers computers (NT1, NT2, and NT3). NS1 is the primary notification server and NS2 is the backup notification server. You must use the PATROL KM for Event Management to complete this task.

To Assign a Primary Notification Server for NT1

1 From the PATROL console, access the NT1 KM menu commands as described in “Accessing KM Commands and InfoBoxes” on page 212.

2 Choose the KM menu command Event Management => Quick Config => Remote Agent.

The NOTIFICATION SERVER SETTINGS dialog box (Figure 26) displays.

Figure 26 NOTIFICATION SERVER SETTINGS Dialog Box

3 Click PRIMARY NOTIFICATION SERVER SETTINGS.

The Primary Notification Server Settings dialog box displays.

4 In the Notification Server Hostname field, type NS1, the host name of the primary notification server.



5 In the Notification Server User Name field, type the user ID you want to use for logging into the notification server. The default is the account you are currently logged in on.

6 Enter the notification server PATROL Agent port.

7 Enter the notification server account password and then click Accept.

The NOTIFICATION SERVER SETTINGS dialog box is displayed (Figure 26 on page 132).

To Assign a Backup Notification Server for NT1

The next step is to assign a backup notification server. The backup notification server sends notification when the primary notification sever is unavailable. For more information about primary and backup notification servers, see “Defining Notification Servers” on page 58.

1 From the NOTIFICATION SERVER SETTINGS dialog box, click BACKUP NOTIFICATION SERVER SETTINGS.

The Backup Notification Server Settings dialog box (similar to Figure 26 on page 132) displays.

2 In the Notification Server Hostname field, enter NS2, the host name of the backup notification server.

3 Enter the NS2 port number and account and password information and click Accept.

The REMOTE NOTIFICATION SERVER SETTINGS dialog box (Figure 26 on page 132) is displayed.

4 To perform a notification test for NS1, select Yes under Perform Alert Test?

5 Click Accept.

6 Verify that the e-mail was received by the default e-mail account.

NOTE For better security, you should create a unique operating system account that is used only for remote notification on the notification servers. You can configure the notification login account to make it unable to fully login to the notification Server. For example, on Unix you can use an invalid login shell, such as /bin/false for the notification account.

Chapter 4 133


To Assign Notification Servers for NT2 and NT3

1 To get the NT1 rulesets, from the PATROL Configuration Manager Agent folder, right-click the NT1 agent and choose the menu command Configuration => Get.

2 When the Job Status window status changes to OK, click Accept.

A backup of the NT1 rulesets is created under Rulesets\ChangeSpring\backup.

3 To get the NT2 rulesets, right-click the NT2 agent and choose the menu command Configuration => Get.

A backup of the NT2 rulesets is created under Rulesets\ChangeSpring\backup.

4 Select (highlight) both of the rulesets you just created.

5 Right-click the highlighted rulesets and choose the menu command Compare.

The RuleSet Comparison window is displayed.

6 To display the rulesets that are unique to NT1, select the option First Unique. (If NT1 was the second ruleset selected, then select the option Second Unique.)

7 Select the unique rules/variables displayed and click Save Selection.

8 From the Save Selected Rules window, enter a ruleset name. For example, RemoteAgentsNS.

Under the RuleSets folder, a ruleset named RemoteAgentsNS is created. When you expand the ruleset, it shows the notification server rules.

9 Select (highlight) the RemoteAgentsNS ruleset and drag it to the NT2 and NT3 agents under the Agents folder.

10 To apply the rulesets to NT2 and NT3, click the Apply Configuration icon .

You must assign notification servers for each PATROL agent that you want to monitor. For NT2 and NT3, you can either repeat the configuration steps performed on NT1 or use the PATROL Configuration Manager to copy the configuration rules from NT1 to NT2 and NT3. The following instructions describe how to use the PATROL Configuration Manager to copy the configuration rules.

When using the PATROL Configuration Manager to copy rules, you first get the configuration (rulesets) for the agent you configured (NT1). Next, you get the rulesets for the agent you want to update (NT2 or NT3). Then you compare the rulesets and save the differences. Finally, you copy the differences to the machines that you want to update. In this case, you would copy the differences to NT2 and NT3.



Specifying an E-mail Target for Low Disk Space

Currently, all e-mail notifications are sent to the [email protected] e-mail target, which is the default e-mail account for the notification server. In this procedure, you specify that e-mail notifications for the LDldFreeSpacePercent parameter are sent to the e-mail account [email protected]. The e-mail address is referred to as the target.

To Specify an E-mail Target for Low Disk Space

1 From the PATROL console, access the remote agent (NT1) host KM menu commands as described in “Accessing KM Commands and InfoBoxes” on page 212.

2 Choose the KM menu command Event Management => Alert Settings => Notification Targets => Email => Remote Targets ALARM => Set For Parameters.

3 From the Choose the target CLASS(es) dialog box, select NT_LOGICAL_DISKS and click Accept.

4 From the Choose target INSTANCE(s) of /NT_LOGICAL_DISKS, select <all instances> and click Accept.

5 From the Choose target PARAMETER(s) of __ANYINST__, select LDldFreeSpacePercent and click Accept.

The SET EVENT MANAGEMENT ALERT VARIABLE:emailTargetsRemoteALARM dialog box is displayed as shown in Figure 27.

NOTE The advantage of creating the target rule on the remote agent is reduced processing at the notification server. However, you could choose to create the rule on the notification server, which has the benefit of centralizing rules. For more information, see “Deciding Where to Place Rules” on page 61.

NOTE Since you decided to create the e-mail target rule on the remote agent, you select the sub-menu command Remote Targets ALARM, because the notification is occurring on a computer that is remote from the agent. However, if you were to create the target rules on the notification server, you would use the menu command Local Targets ALARM, since the targets are located on the same computer performing the notification.

Chapter 4 135


Figure 27 EVENT MANAGEMENT ALERT VARIABLE:emailTargetsRemoteALARM Dialog Box

6 Enter the e-mail target [email protected] and then click Accept.

When you perform this step, the following rule is created:

/NT_LOGICAL_DISKS/__ANYINST__/LDldFreeSpacePercent/emailTargetsRemoteALARM

The value of this rule is [email protected]. For more information on the emailTargets rule, see “emailTargets” on page 171.

7 Perform Steps 1-6 for the other remote agents (NT2 and NT3) or use the PATROL Configuration Manager to copy the configuration rules from NT1 to NT2 and NT3.

Rewording the Notification Message

You can choose to use the default notification message text or reword messages on an individual agent, on a notification server, or on both. For the pros and cons of these approaches, see “Deciding Where to Place Rules” on page 61. For this scenario, assume that you want to reword messages at the notification server.

You can set up a generic message format for all alerts on the notification server or you can create unique messages for specific applications, instances, or parameters. For this scenario, you will create a generic message for all alerts. You will create the rule for this message format on the notification servers NS1 and NS2.



To Reword the Default Notification Message

1 From the PATROL console, access the NS1 KM menu commands as described in “Accessing KM Commands and InfoBoxes” on page 212.

2 Choose the KM menu command Event Management => Alert Setting => Alert Messages => Default Message Format.

The Message Rewording dialog box (Figure 28) displays.

Figure 28 Message Rewording Dialog Box

3 Enter the message subject line and body using the message replacement variables. For a complete list and description of the message replacement variables provided by PATROL KM for Event Management, see “NOTIFY_EVENT Fields” on page 157.

PATROL KM for Event Management substitutes real values at run time. The following example shows how an actual notification message would be displayed using the message format shown above:

4 Perform Steps 1-3 for the backup notification server, NS2, or use the PATROL Configuration Manager to copy the configuration rules from NS1 to NS2.

EXAMPLE

%PARAMETER_STATUS% on %HOSTNAME% for parameter %PARAMETER_NAME% = %PARAMETER_VALUE%

ALARM on NT1 for parameter LDldFreeSpacePercent = 3.50

Chapter 4 137



Next, perform the following tests to verify that notification is working correctly.

Testing the notification script or program

Before testing your configuration, you should test the script or program that you are using to send notifications. For this scenario, you would log into the notification servers, NS1 and NS2, using the PATROL default account, and attempt to send an e-mail message using mailx. After you verify that the e-mail client on the servers can send e-mail using mailx, you would use the following procedure to test whether e-mail notification is sent when the LDldFreeSpacePercent parameter enters an ALARM state.

To Test whether Notification is sent when LDldFreeSpacePercent alarms

1 Using the PATROL Configuration Manager, create the rule shown below:

2 Use the PATROL Configuration Manager to apply this rule to the remote agents NT1, NT2, and NT3.

When you apply this rule to an agent, this rule assigns the parameter a value that is within the specified range. The parameter enters the desired state, ALARM, and generates an alert.

3 Determine whether the LDldFreeSpacePercent parameter enters an ALARM state and whether an e-mail notification is sent to [email protected].

You can also use a PSL command to set a parameter value.

To Force LDldFreeSpacePercent into ALARM using a PSL Command

1 From the PATROL console, access the KM menu commands for one of the remote agents, NT1, as described in “Accessing KM Commands and InfoBoxes” on page 212.

2 Choose the KM menu command PSL Command.

"/AS/EVENTSPRING/setParameterValue" = { REPLACE = "/NT_LOGICAL_DISKS/__ANYINST__/LDldFreeSpacePercent=ALARM" }



3 Enter the PSL command shown below and click Apply.

4 Repeat the PSL command in Step 3 twice.

This PSL command sets the value of LDldFreeSpacePercent on logical disk C: to 1%. Since by default, LDldFreeSpacePercent alarms when the value is 0 to 5%, for 3 consecutive cycles, issuing this PSL command 3 times causes LDldFreeSpacePercent to enter an ALARM state and issue an alert.

5 Determine whether the LDldFreeSpacePercent parameter enters an ALARM state and whether an e-mail notification is sent to [email protected].

If a Problem Occurs

If the e-mail notification is not sent correctly, see “Configuration Problems” on page 198 for troubleshooting help.

set("/NT_LOGICAL_DISKS/C:/LDldFreeSpacePercent/value",1);

Chapter 4 139

Sending E-mail Notification for CPU Usage that Includes Parameter Annotations


This scenario describes how to configure the PATROL KM for Event Management to send an e-mail notification that includes annotated data for the parameter CPUCpuUtil, which monitors the CPU processor utilization.

Assumptions

In this scenario you make the following assumptions:

■ The PATROL KM for Event Management has been installed and the KM has been loaded in the console.

■ You have already defined the notification server and notification script as discussed in “Defining Notification Servers” on page 58 and the script successfully sends notifications.

■ You have already defined notification targets as described in “Defining Notification Targets” on page 60.

■ The configuration instructions assume the use of the PATROL KM for Event Management menu commands. Except where noted, you could also use the PATROL Configuration Manager to perform the configuration tasks.

■ The notification server and the managed nodes are Unix servers. The same result can be accomplished on a Windows server using a Perl script instead of a Unix shell script. However, you would need to edit the Perl script to achieve proper formatting of the notification message.

■ The PATROL KM for Windows OS is installed on the console and on the managed nodes.

■ To obtain the annotated data for CPUCpuUtil, a PSL (PATROL Scripting Language) recovery action will be used.



Overview of Annotated Data Points

Some PATROL parameters collect textual data related to events. The textual data is posted on the associated parameter graph, and is referred to as an annotated data point. By double-clicking the annotated data point, you can access the textual data. You may want to include annotated data in notification messages because it provides administrators with information about the parameters that generated the events.


To create an e-mail notification for a specific parameter that includes annotated data, you need to perform the following general tasks:

1 Enable recovery actions and notification for the parameter.

2 Create recovery action rules for the parameter.

3 Edit the notification command script for the parameter. (Optional)

Enabling Recovery Actions and Notification

In this task, you enable recovery actions and notification for the CPUCpuUtil parameter on the managed node. These settings are stored in the arsAction rule.

To Enable Recovery Action and Notification

1 Access the managed node KM menu commands, as described in “Accessing KM Commands and InfoBoxes” on page 212, and choose the command Event Management => Alert Settings => Alert Actions => Set For Parameters.

2 Select the application class CPU, instance CPU, and parameter CPUCpuUtil.

3 From the SET EVENT MANAGEMENT VARIABLE: arsAction dialog box, select Allow Recovery Actions and Trigger NOTIFY_EVENT.

4 To apply your changes, select Make persistent.


Chapter 4 141


Creating Recovery Action Rules

After you enable recovery actions and notification, you need to create the following recovery action rules.

■ arsCmdType —the type of recovery action command script■ arsCommand —the notification command script

Since recovery actions execute at the managed node, you create these rules on the managed node.

About the Recovery Action Command Type (arsCmdType)

You must specify a command type to execute a recovery action. You can specify the command type for all PATROL objects or for any individual PATROL application, instance, or parameter. PATROL has two built-in command types, PSL and OS. If you use a command type other than PSL or OS, the command type must be defined for the application class. For this example, PSL is the command type.

To Specify the Recovery Action Command Type

1 Access the managed node KM menu, as described in “Accessing KM Commands and InfoBoxes” on page 212, and choose the command Event Management => Alert Settings => Local Alert Settings => Recovery Action Command Type => Set For Parameters.


3 From the SET EVENT MANAGEMENT VARIABLE: arsCmdType dialog box, enter PSL as the command type.


To Specify the Recovery Action Command Script

1 Access the managed node KM menu commands, as described in “Accessing KM Commands and InfoBoxes” on page 212, and choose the command Event Management => Alert Settings => Local Alert Settings => Recovery Action Commands => Set For Parameters.




3 From the SET EVENT MANAGEMENT VARIABLE: arsCommand dialog box, enter the following recovery action script:


PATROL is now configured to include the annotated data in notification messages when the parameter CPUCpuUtil alarms. To customize the message format, see the next step, “Creating Notification Command Scripts” .

Creating Notification Command Scripts

This task describes how to change the notification message format that is defined in the default notification command script, AS_EVLocalAlertNotify.sh. The default script is configured to put data from the __udefvar__ variable in the body of the e-mail message. However, you may want to edit the script to change the body text.

Verify SED Utility Location

To manage carriage returns properly, you may need to edit the SED utility file location specified in the script.

Refer to Script Comments

The script contains numerous comments. Refer to the comments for specific details.

Using Perl Scripts in Windows

You may be able to generate better formatting in Windows by editing the Perl notification command script, located in the %PATROL_HOME%/lib/psl directory.


You can verify the notification test by looking at the PATROL KM for Event Management NotifiedEvents parameter.

__udefvar__=annotate_get(\”/\.__appl_class__.\”/\”.__instance__.\”/\”.__param__);

Chapter 4 143

Configuring a Recovery Action that Runs Under a Specified Account

To Verify that a Notification is Sent

1 From the PATROL console, double-click the notification server.

The AS_EVENTSPRING application class (Event Management) is displayed.

2 Double-click the AS_EVENTSPRING application class.

3 Double-click the NotifiedEvents parameter.

If the test is successful, an annotated data point is displayed for the notification server.


The following scenario describes how to use the PATROL KM for Event Management to execute a recovery action that runs under a specified OS account. The recovery action moves archive files when the Oracle parameter ArchFreeSpace enters an ALARM state.

The example described here is just one of many possible approaches and may not necessarily be the appropriate approach in your environment. The purpose of this example is to show one type of recovery action that you can implement.

Assumptions

■ The PATROL KM for Event Management and the PATROL KM for Oracle are installed and configured on the agent computer.

■ This scenario will consider one agent and, thus, will not address deploying configurations to multiple remote agents. For more information about deploying configurations, see the scenario “Sending E-mail Notification When Disk Space is Low” on page 128.

■ The agent computer is a Unix server running Oracle.

■ The account that you want to run this recovery action under has the proper permissions to execute the recovery action on the agent computer.

■ The recovery action is executed by means of a PSL command.



■ To encrypt the account password, the PATROL DES encryption is used. However, you could also choose to use another encryption method as long as the PSL recovery action is able to decrypt the password. If you use PATROL DES encryption, the password is decrypted internally.


To configure a recovery action that runs under a specified account, you would complete the following tasks. The table below shows the location in which step is completed. An alternative location is also noted. For example, many of the configuration tasks can be completed within either the PATROL KM for Event Management or the PATROL Configuration Manager.

Testing Recovery Action Script

Test the recovery action script that moves the log files by manually running the script outside of PATROL using the Unix account that you want the script to run under. After you verify that the script works, you can automate it with PATROL. For this example, assume the script is /home/oracle/scripts/arch_backup.ksh.

Table 29 Sending E-mail Notification for Low Disk Space: Configuration Overview

Step Task PATROL ProductAlternative PATROL Product

1 Testing Recovery Action Script OS (outside of PATROL) NA

2 Enabling Recovery Actions for ArchFreeSpace on Agent Computer



3 Defining the Recovery Action Type for Agent Computer



4 Storing the Encrypted Password as a Pconfig Variable

PATROL Developer Console None

5 Configuring the PSL Recovery Action



6 Testing the Recovery Action PATROL console None

Chapter 4 145


Enabling Recovery Actions for ArchFreeSpace on Agent Computer

In this procedure you make sure that recovery actions are enabled for the ArchFreeSpace parameter on the agent computer. This configuration setting is stored in the arsAction rule. The following procedure describes how to use the PATROL KM for Event Management interface to verify that the arsAction rule is configured to allow recovery actions. You could also use the PATROL Configuration Manager to create or edit this rule.

To Enable Recovery Actions for ArchFreeSpace on the Agent Computer

1 From the PATROL console, access the agent computer KM menu commands, as described in “Accessing KM Commands and InfoBoxes” on page 212, and choose the command Event Management => Alert Settings => Alert Actions => Set For Parameters.

2 Select the application class ORACLE_AVAILABILITY, instance Test, and parameter ArchFreeSpace.

3 From the SET EVENT MANAGEMENT VARIABLE: arsAction dialog box, select Allow Recovery Actions and Trigger NOTIFY_EVENT.

The following rule is created:

/AS/EVENTSPRING/ORACLE_AVAILABILITY/Test/ArchFreeSpace/arsAction = 6

4 To apply your changes, select Make persistent.


Defining the Recovery Action Type for Agent Computer

The next step is to define the type of recovery action. This setting is stored in the configuration variable arsCmdType. By default, PATROL supports PSL and OS command types. The following procedure describes how to set arsCmdType using the PATROL KM for Event Management interface. You can also create and edit this variable using the PATROL Configuration Manager.

In this scenario, you need to associate the OS account information with the shell script that runs the recovery action. To do this, you must use a PSL command. Therefore, you need to specify arsCmdType as PSL.



To Specify arsCmdType as PSL

1 From the PATROL console, access the agent computer KM menu commands, as described in “Accessing KM Commands and InfoBoxes” on page 212, and choose the command Event Management => Alert Settings => Local Alert Settings => Recovery Action Command Type => Set For Parameters.


3 From the SET EVENT MANAGEMENT VARIABLE: arsCmdType dialog box, enter PSL as the command type.


The following rule is created:

/AS/EVENTSPRING/ORACLE_AVAILABILITY/Test/ArchFreeSpace/arsCmdType = PSL

Storing the Encrypted Password as a Pconfig Variable

For security reasons, encrypt the password of the OS account that is used to execute the recovery action. You can do this by using PATROL DES encryption and storing the password as a pconfig variable that you can access from the PSL recovery action.

To Store the Encrypted Password as a Pconfig Variable

1 From the PATROL Developer Console, right-click the managed host and choose KM Commands => PSL Command.

2 From the PSL Command dialog box, type the following command and click Apply.

The pconfig variable /MYCOMPANY/ORACLE/OSlogin is created and assigned the value of the encrypted password.

Note that whenever the password is changed, you must update the pconfig variable.

encrypted_passwd = encrypt("oracle_password", "DES"); pconfig("REPLACE", "/MYCOMPANY/ORACLE/OSlogin", "oracle ".encrypted_passwd);

Chapter 4 147


Configuring the PSL Recovery Action

The next step is to assign the PSL recovery action to the arsCommand rule so that when the ArchFreeSpace parameter enters a WARN or ALARM state, the PSL recovery action gets the account and encrypted password and uses it to execute the script located in /home/oracle/scripts/arch_backup.ksh.

To Assign the PSL Recovery Action to the arsCommand Rule

1 From the PATROL console, access the agent computer KM menu commands, as described in “Accessing KM Commands and InfoBoxes” on page 212, and choose the command Event Management => Alert Settings => Local Alert Settings => Recovery Action Commands => Set For Parameters.


3 From the SET EVENT MANAGEMENT VARIABLE: arsCommand dialog box, enter the following PSL code:

This PSL recovery action is stored in the following configuration variable:

/AS/EVENTSPRING/ORACLE_AVAILABILITY/test/ArchFreeSpace/arsCommand


oracle_os = nthlinef(pconfig("GET", "/MYCOMPANY/ORACLE/OSlogin"), 2, ""); usern = nthargf(oracle_os, 1, " ", ""); passwd = nthargf(oracle_os, 2, " ", ""); results = execute("OS", "/home/oracle/scripts/arch_backup.ksh", "", usern, passwd); print("Results of script follows:\n", results, "\nend..."); ;

NOTE Before entering your own PSL recovery action code, you should test the code for errors using the testing functionality in the PATROL console.



Summary of Rules Created

At this point, the following rules have been created.

Testing the Recovery Action

After you assign the PSL recovery action, force the ArchFreeSpace parameter into alarm and verify that the recovery action script executes.

Table 30 Rules Created: Oracle Recovery Action Example

Rule

/AS/EVENTSPRING/ORACLE_AVAILABILITY/Test/ArchFreeSpace/arsAction = 6

This rule specifies that the ArchFreeSpace parameter associated with the application instance TEST of the ORACLE_AVAILABILITY application class is enabled for recovery actions. For more information on the arsAction rule, see “arsAction” on page 161./AS/EVENTSPRING/ORACLE_AVAILABILITY/Test/ArchFreeSpace/arsCmdType = PSL

This rule specifies that the ArchFreeSpace parameter associated with the application instance TEST of the ORACLE_AVAILABILITY application class uses PSL recovery actions. For more information on the arsCmdType rule, see “arsCmdType” on page 168.AS/EVENTSPRING/ORACLE_AVAILABILITY/test/ArchFreeSpace/arsCommand =

oracle_os = nthlinef(pconfig("GET", "/MYCOMPANY/ORACLE/OSlogin"), 2, ""); usern = nthargf(oracle_os, 1, " ", ""); passwd = nthargf(oracle_os, 2, " ", ""); results = execute("OS", "/home/oracle/scripts/arch_backup.ksh", "", usern, passwd); print("Results of script follows:\n", results, "\nend..."); ;

This rule specifies the PSL recovery action. For more information on the arsCommand rule, see “arsCommand” on page 168.

NOTE To apply these rules to all instances of the ArchFreeSpace parameter on the agent, replace Test with __ANYINST__.

Chapter 4 149


To Force ArchFreeSpace into ALARM using a PSL Command


2 Choose the KM menu command PSL Command.

3 Enter the PSL command shown below and click Apply.

This PSL command sets the value of ArchFreeSpace parameter of the test instance to 1. This action causes ArchFreeSpace to enter an ALARM state and issue an alert.

4 Determine whether the ArchFreeSpace parameter enters an ALARM state and whether the recovery action is executed.

If a Problem Occurs

If the PSL editor indicates a syntax problem, see the PATROL Script Language Reference Summary.

set("/ORACLE_AVAILABILITY/test/ArchFreeSpace/value",1);


C h a p t e r 5
5 Rules and Configuration Variables
This reference provides a comprehensive listing of PATROL KM for Event Management settings and rules.

PATROL KM for Event Management allows object-level control (for example, application of rules) throughout an enterprise. You can deploy these rules using automation scripting, custom applications, the PATROL Console, or the PATROL Configuration Manager.

PATROL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Example: PATROL Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Example: Rule Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Example: PATROL KM for Event Management E-mail Rule . . . . . . . . . . . . . . . . 154

NOTIFY_EVENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156How the NOTIFY_EVENT and REMOTE_NOTIFY_EVENT are Triggered . . . 156Event Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Order of Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Empty Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Using the Variable userdefined. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Event Size Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157NOTIFY_EVENT Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Alert Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161arsAction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161alertSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162allowOverrides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163loginDeniedIgnoredUsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164useEnvOnlyForCmds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164allowInfoRecoveryActions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165spoolDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165setParameterValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Local Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166alertResend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167alertLocalCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167arsCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168arsCmdType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168alertResetOnInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Chapter 5 151

Remote Alert Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169NOTIFICATION_SERVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170RemoteAgentCommSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Notification Target Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171emailTargets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171pagerTargets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172customTargets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173ttTargets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Blackout Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174blackoutPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174__OVERRIDE__ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Notification Server Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175nsRemoteTargetSetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Custom Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176msgText . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176msgBody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177CustomId1 and CustomId2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178allowOperator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180appClassSettingsStatusFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180disableNotifyAnnotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181maxEventsToReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182snmpSettings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182snmpOid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Primary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Blackout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183pingCmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184pingOkString . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184pingPacketSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185pingAttempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185pingArgs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185checkerAccount.defaultAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Parameter Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186THRESHOLDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188paramSettingsStatusFlag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188processWildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Instance Filtering Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190FilterList Configuration Variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190FilterType Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190


PATROL Objects

PATROL ObjectsBefore you use PATROL KM for Event Management, you should have an understanding of PATROL objects. Table 31 lists the hierarchy and description of PATROL objects.

Example: PATROL Object

This example assumes an Windows Server with a physical disk partitioned into multiple logical disks (C: and D:). The logical disk application class contains the parameter, LDldFreeMegabytes. This parameter shows the number of megabytes of free space available on the C: logical disk.

Table 31 PATROL Objects Hierarchy

Hierarchy(1=Highest) Object Description Windows Example Unix Example

1 host host computer of the objects that are being monitored

ntprod1 sunprod1

2 application class

type of objects that can be monitored

NT_LOGICAL_DISKS FILESYSTEM

3 application instance

actual instance of an application class

C: root

4 parameter specific parameter of an application instance

LDldFreeMegabytes FSCapacity

Table 32 Example: PATROL Object

Object Example Variable

host the Windows Server hosts

/

application class

the logical disks application class of the Windows Server

/NT_LOGICAL_DISKS

application instance

the logical disk, C: /NT_LOGICAL_DISKS/C:

parameter the parameter LDldFreeMegabytes associated with the logical disk C:

/NT_LOGICAL_DISKS/C:/LDldFreeMegabytes

Chapter 5 153

PATROL Objects

Example: Rule Inheritance

You can use PATROL KM for Event Management to define different rules for each PATROL object. The KM applies inheritance to these rules. Rules defined for objects at a higher level in the hierarchy are applied to all lower-level objects that do not have their own rule.

This example contains the following rules:

Rule 1: E-mail User1 for any parameter in alarm on this host (‘/’) that does not have a more specific rule assigned. User1 is the default e-mail account.

Rule 2: E-mail User2 for any parameter in any instance of the logical disks application class (/NT_LOGICAL_DISKS) in alarm on this host.

Rule 3: E-mail User3 for any parameter in alarm on this host for the logical disks application class instance C: (/NT_LOGICAL_DISKS/C:).

Rule 4: E-mail User4 when the parameter LDldFreeMegabytes is in alarm on this host for the logical disks application class instance C: (/NT_LOGICAL_DISKS/C:/LDldFreeMegabytes).

Example: PATROL KM for Event Management E-mail Rule

PATROL KM for Event Management uses variables to specify which functions are performed when events occur for a PATROL object. A variable is defined by a category, a PATROL object, and a rule.

Table 33 Example: Rule Inheritance

Object in Alarm Action

/NT_LOGICAL_DISKS/C:/LDldFreeMegabytes User4 receives an e-mail. Rule 4 is specific to the parameter and instance that are in alarm

/NT_LOGICAL_DISKS/C:/LDldIdleTimePercent User3 receives e-mail. No rule is defined for the parameter, LDldIdleTimePercent, so the parameter inherits the rules defined for the application instance, (logical disk C:), which, in this case, is Rule 3.

/NT_LOGICAL_DISKS/D:/LDldFreeMegabytes User2 receives an e-mail. No rule is defined at the instance level for D:, so Rule 2, the application class rule, applies.

/NT_CPU/CPU_0/CPUprcrProcessorTimePercent User1 receives an e-mail since none of the lower-level rules apply to this alarm.


PATROL Objects

The general variable naming format is the following: category/object/rule

The following example shows how to send an e-mail when an alarm condition occurs for a PATROL object:

category: /AS/EVENTSPRING/ALERT/EMAIL is the category including rules that perform notification.

object: /NT_LOGICAL_DISKS/C: is the PATROL object, an application instance, to which the rule is applied.

rule: emailTargetsLocalALARM is the rule indicating who is notified by e-mail when an alarm condition occurs for the PATROL object /NT_LOGICAL_DISKS/C:

PATROL KM for Event Management uses a special instance name of __ANYINST__ to indicate that a rule for a particular parameter is applied to all instances of the application class. For example,

causes an e-mail to be sent if an alarm occurs for the ServiceStatus parameter on any monitored service on the Windows Server.

The PATROL object name can also include the hostname when the rule exists on the notification server but only applies to a particular host. For example, for the configuration variable

the rule only applies for alarm conditions occurring on the Windows Server winprod.

Table 34 PATROL KM for Event Management Variable Definition

Variable Definition

category a grouping of related rules that perform notification

object the PATROL object to which the rule applies

If object is not specified, the rule applies to all objects.

rule the rule to apply to the PATROL object

/AS/EVENTSPRING/ALERT/EMAIL/NT_LOGICAL_DISKS/C:/emailTargetsLocalALARM

/AS/EVENTSPRING/ALERT/EMAIL/NT_SERVICES/__ANYINST__/ServiceStatus/emailTargetsLocal

/AS/EVENTSPRING/ALERT/EMAIL/winprod/NT_LOGICAL_DISKS/C:/emailTargetsLocalALARM

Chapter 5 155

NOTIFY_EVENT

NOTIFY_EVENTThis section describes the event details provided by the NOTIFY_EVENT and REMOTE_NOTIFY_EVENT.

How the NOTIFY_EVENT and REMOTE_NOTIFY_EVENT are Triggered

When an agent generates an alert, such as high CPU, it generates a NOTIFY_EVENT event within it’s own event database. This initial NOTIFY_EVENT event triggers a corresponding REMOTE_NOTIFY_EVENT event at the Notification Server if the agent is configured to do so (rule: alertSystem).

Event Details

The event details are collected prior to triggering the initial NOTIFY_EVENT event. NOTIFY_EVENT events and REMOTE_NOTIFY_EVENT events contain identical event details.

The alert message is provided as the first NOTIFY_EVENT argument EV_ARG1. The event details are provided as the second argument, EV_ARG2.

The fields within the event details are comma delimited and are described in “NOTIFY_EVENT Fields” on page 157.

Order of Fields

The field positioning within the event details does not change. If additional fields are added, the existing fields remain in the order indicated.

Empty Fields

Some fields, such as custom id or parent instance, may be empty. In addition, if the NOTIFY_EVENT is triggered from an application class object, fields that relate to the instance or the parameter appear as __NA__ or are empty.


NOTIFY_EVENT

Using the Variable userdefined

Since the userdefined variable can contain characters that could affect the generation or processing of a NOTIFY_EVENT, the following changes are made to this variable prior to triggering the initial NOTIFY_EVENT:

■ the length is limited to 25k■ new-lines are replaced with -CR-■ tabs and commas are replaced with spaces

If tabs and commas are needed, you must replace them with non-problematic characters prior to their use in the PATROL KM for Event Management. For example, you could replace tabs replaced with -TAB- and then after the event is processed, insert the tabs back.

Event Size Limitations

If you use the userdefined variable at the remote agent to reword notification messages, the size of event can exceed PEM (PATROL Event Manager) limit.

NOTIFY_EVENT Fields

This topic describes the NOTIFY_EVENT fields. It also shows the following:

■ the message replacement variables that you can use to reword notification messages (rule: msgText and msgBody)

■ the environment variables that you can you use in your notifications script (rule: alertLocalCommand)

Table 35 NOTIFY_EVENT Fields (Part 1 of 4)

FieldMessage Replacement Variable Environment Variable Description

Hostname %HOSTNAME% AS_HOSTNAME Hostname of affected system (e.g., glamis)

IP Address %IPADDRESS% AS_IPADDRESS IP Address for hostname (e.g., 192.168.1.1)

TCP Port %TCP_PORT% AS_TCP_PORT Affected agent TCP listening port (e.g., 3181)

UDP Port %UDP_PORT% AS_UDP_PORT Affected agent UDP listening port (e.g., 3181)

Chapter 5 157

NOTIFY_EVENT

Application Class %APPCLASS% AS_APPCLASS Application Class name (e.g., ORACLE, FILESYSTEM, NT_SERVICES)

Instance Name (sid) %APPINSTANCE% AS_APPINSTANCE Internal instance name (e.g., oracle_db1)

Icon Name %ICON_NAME% AS_ICON_NAME Name of the instance as it appears on the PATROL console (e.g., oracle_db1)

Parent Instance %PARENT_INSTANCE%

AS_PARENT_INSTANCE

Instance name that is the parent container of instance (e.g., /CPU/CPU)

Parameter Name %PARAMETER_NAME%

AS_PARAMETER Parameter name (e.g., CPUCpuUtil)

Parameter Status %PARAMETER_STATUS%

AS_PARAMETER_STATUS

Parameter status at time of alert (e.g., ALARM)

Parameter Value %PARAMETER_VALUE%

AS_PARAMETER_VALUE

Parameter value at the time of alert (e.g., 99)

Alert Date %DATE% AS_DATE Date the alert occurred. This is the local date on hostname.

For example, Sun June 27 2004.

Alert Time %TIME% AS_TIME Time the alert occurred. This is the local time on hostname.

Time Zone %TIMEZONE% AS_TIMEZONE Time zone the affected system is set to (e.g. US/Eastern/EDT (Unix) or Eastern Daylight Time (NT))

Last10 Parameter Values

%LAST10% AS_LAST10 Last 10 parameter values preceding and including current value, if available. Values are space delimited. (e.g., 98.11 97.14 95.87 etc.)

Average of Last 10 %AVE10% AS_AVE10 Average of the last 10 parameter values. (e.g., 97.21)




NOTIFY_EVENT

Last10 Timestamps %LAST10TS% AS_LAST10TS Times the last 10 parameter values were collected. These map directly with the Last10 values. (Time in seconds since epoch.)

Last10 Total Period %LAST10TP% AS_LAST10TP Length of time, in minutes, from the first parameter value and the last

Event Id %EVENT_ID% AS_EVENT_ID Event id on hostname, which triggered the notification. This is the originating event id such as from Standard Event 11 (e.g., 5343)

User defined %USERDEFINED% AS_USERDEFINED User defined variable. This contains the information stored in the variable /_my_APPCLASS_APPINSTANCE_PARAMETER at the time of the alert condition

This variable can be set by any KM or any PSL code prior to the PATROL object exceeding a threshold and generating a NOTIFY_EVENT event.

OS Type %OS_TYPE% AS_OS_TYPE Operating system type of hostname (e.g., NT 5.0 Service Pack 1) (V2.4.02 and later)

Alarm Min %ALARM_MIN% AS_ALARM_MIN Lower threshold of current alarm range

(V2.4.02 and later)

Alarm Max %ALARM_MAX% AS_ALARM_MAX Upper threshold of current alarm range

(V2.4.02 and later)



Chapter 5 159

NOTIFY_EVENT

The following variables are not available from event details; they are provided as message placement and environment variables only at a notification server.

Custom Id1 %CUSTOM_ID1% AS_CUSTOM_ID1 Custom identifier assigned to object

(V2.4.02 and later)

Custom Id2 %CUSTOM_ID2% AS_CUSTOM_ID2 Custom identifier assigned to object

(V2.4.02 and later)

PATROL Agent version

%AGENT_VERSION%

AS_AGENT_VERSION The version of the PATROL Agent running on the host.

PATROL Home %PATROL_HOME% AS_PATROL_HOME The PATROL installation directory.

Event catalog %EVENT_CATALOG%

AS_EVENT_CATALOG The PATROL event catalog file.

Event class %EVENT_CLASS% AS_EVENT_CLASS The event class of the event. For example, 9 or 11.

Event status %EVENT_STATUS% AS_EVENT_STATUS The status of the event. For example, Open.

Event severity %EVENT_SEVERITY%

AS_EVENT_SEVERITY The event severity. For example, 4.

Event type %EVENT_TYPE% AS_EVENT_TYPE The type of event. For example, ALARM.

Table 36 Notification Server Message Replacement Variables

Message Replacement Variable Environment Variable Description

%NOTIFY_EVENT_ID% AS_NOTIFY_EVENT_ID Event Manager event id for the NOTIFY_EVENT (e.g., 5439)

%EVENT_TYPE% AS_EVENT_TYPE Event Manager event type of the NOTIFY_EVENT (e.g., ALARM)

%EVENT_STATUS% AS_EVENT_STATUS Event Manager event status of the NOTIFY_EVENT (e.g., OPEN)




Alert Rules

The following variables are available only as environment variables that can be used by a notification script.

Alert RulesEach PATROL object (computer, application class, instance, and parameter) can have its own alert settings.

arsAction

You can use the arsAction rule to specify the actions to perform when an alert condition occurs for a specific PATROL object.

Table 37 Notification Server Environment Variables

Environment Variable Description Example

AS_NOTIFICATION_TYPE notification type e-mail, page

AS_NOTIFICATION_TARGETS notification targets [email protected]

AS_NOTIFICATION_MSG reworded message High CPU on glamis at 99.54%

AS_NOTIFICATION_FILE filename on hostname that contains recovery action output

/usr/patrol/CPU_CPU_CPUCpuUtil_20020404111134.out

Table 38 arsAction Rule

Rule arsAction

Configuration Variables ■ /AS/EVENTSPRING/object/arsAction■ /AS/EVENTSPRING/object/arsActionINFORMATION■ /AS/EVENTSPRING/object/arsActionWARNING■ /AS/EVENTSPRING/object/arsActionALARM

Values 3 bit mask0 - Do nothing2 - Allow recovery actions4 - Trigger NOTIFY_EVENT (Perform notification)6 - Allow recovery actions and notification

Menu Command Access Event Management => Alert Settings => Alert Actions

NOTE To allow recovery actions for INFORMATION events, you must also set the allowInfoRecoveryActions variable to 1.

Chapter 5 161

Alert Rules

alertSystem

You can use the alertSystem rule to specify the location of the notification server that performs the notification for the specified PATROL object. The notification server can be local, remote, both, or none.

Table 39 alertSystem Rule

Rule alertSystem

Configuration Variable ■ /AS/EVENTSPRING/ALERT/object/alertSystem■ /AS/EVENTSPRING/ALERT/object/alertSystemINFORMATION■ /AS/EVENTSPRING/ALERT/object/alertSystemWARNING■ /AS/EVENTSPRING/ALERT/object/alertSystemALARM

Values RemoteLocalLocal, RemoteNone

For a detailed description of these options, see Table 40 on page 163.

Support supported by PATROL KM for Event Management version 2.4.05 or later

Menu Command Access

Event Management => Alert Settings => Notification System


Alert Rules

allowOverrides

You can use the allowOverrides rule to disable the use of rule overrides (__OVERRIDE__).

Table 40 Notification System Options

Location Description

LOCAL Send alerts to a notification server on the same computer as the PATROL Agent that is doing the monitoring. This configuration is sufficient for sending e-mail notification, but most systems do not have paging capabilities. Paging usually requires the REMOTE option.

Using the LOCAL option, notification failures have no impact on other systems. Local notification is potentially more reliable since it requires fewer intermediate components (for example, the network connection, the remote notification server).

Some disadvantages to using the LOCAL option are

■ Notification scripts and procedures are required on each computer.■ Most systems are unable to perform paging locally.■ Notification targets (for example, who is paged or e-mailed) must be maintained

for each computer.

REMOTE Specifies that alerts are sent to a notification server that is on a different computer. The REMOTE option allows you to centralize notification and simplifies the management of settings and procedures. However, if the notification server fails, alerts from many monitored machines are not sent. One way to reduce this risk is to configure a backup notification server. If the primary notification server is unavailable, PATROL automatically fails over to the backup notification server.

LOCAL, REMOTE

You can choose both LOCAL and REMOTE. You may need to select this option if you want to send an e-mail message or page from the local box, but still forward the event to an enterprise console.

NONE PATROL KM for Event Management does not perform notification.

Table 41 allowOverrides Rule

Rule allowOverrides

Configuration Variable /AS/EVENTSPRING/allowOverrides

Values 0 = do not allow rule overrides1 = allow rule overrides (default)

Example 1


Menu Command Access Not available

Chapter 5 163

Alert Rules

loginDeniedIgnoredUsers

Use the LoginDeniedIgnoredUsers configuration variable to specify the users to ignore when a user name is denied login to the agent because of ACL restrictions or invalid login information. When you use this variable, the specified user account does not generate invalid login errors even if it is unable to login to the agent.

useEnvOnlyForCmds

Use the useEnvOnlyForCmds rule to indicate whether PATROL KM for Event Management should run all operating system commands (for example, notification and recovery) with command-line arguments.

NOTE If you use this configuration variable, you must add the built-in users EventSpring and EventSpring_Availability_Check to the list of usernames. By default, if you don’t use the LoginDeniedIgnoredUsers configuration variable, then any login errors caused by these built-in users are ignored. However, if you do use the LoginDeniedIgnoredUsers configuration variable, login errors caused by these users are not ignored unless you also add them to the comma-delimited list of usernames.

Table 42 LoginDeniedIgnoredUsers Rule

Rule loginDeniedIgnoredUsers

Configuration Variable

/AS/EVENTSPRING/loginDeniedIgnoredUsers

Values comma delimited string

Examples patrol_checker,EventSpring,EventSpring_Availability_Check


Menu Command Access

Not available

Table 43 useEnvOnlyForCmds Rule

Rule useEnvOnlyForCmds


/AS/EVENTSPRING/useEnvOnlyForCmds

Values 0 = run commands with command-line arguments (default)1 = do not use command-line arguments

Example 1


Menu Command Access

Event Management => Alert Settings => Local Alert Settings => Notification Command


Alert Rules

allowInfoRecoveryActions

Use the allowInfoRecoveryActions rule to indicate whether the PATROL KM for Event Management can perform recovery actions for INFORMATION events. For example, an INFORMATION event is generated when a parameter goes from an ALARM state to an OK state.

spoolDirectory

Use the spoolDirectory configuration variable to specify the directory where PATROL KM for Event Management reports are stored (for example, parameter reports and recovery action output).

Table 44 useEnvOnlyForCmds Rule

Rule allowInfoRecoveryActions


/AS/EVENTSPRING/allowInfoRecoveryActions

Values 0 = recovery actions not enabled for INFORMATION events (default)1 = recovery actions enabled for INFORMATION events

Example 0

Support supported by PATROL KM for Event Management version 2.7or later

Menu Command Access

None

Table 45 SpoolDirectory Rule

Rule spoolDirectory

Configuration Variable /AS/EVENTSPRING/spoolDirectory

Values directory path

The default location is the directory specified in the PATROL_HOME environment variable.

Example /usr/local/patrol_reports


Chapter 5 165

Local Alert Settings

setParameterValue

You can use the setParameterValue rule to set the value of an active parameter.

.

Local Alert SettingsYou can use the Local Alert Settings menu commands to specify configurations or rules that apply to the PATROL Agent where the alert occurs. Local settings can include external procedures (for example, script, batch file, or other OS command) to execute for local notification and recovery actions. Local notification settings (for example, locally defined targets and the notification command) are used only if the value of the Notification System is set to Local. If the Notification System is set to Remote, local alert settings, including local notification targets, are not forwarded to the notification servers.

Table 46 SetParameterValue Rule

Rule setParameterValue


/AS/EVENTSPRING/setParameterValue

Format PARAMETER=VALUE,DELAY=N,...,PARAMETER=VALUE,DELAY=N

■ parameter = a PATROL object (/APPLICATION_CLASS/INSTANCE/PARAMETER). When you use an instance name of __ANYINST__, the KM selects a valid instance.

■ VALUE = ALARM, WARM, OK, CLEAR. If you specify CLEAR, the KM attempts to set the parameter to a value that is not within an active alarm range.

■ DELAY = the time in seconds that the KM waits between each parameter set (optional).

Example /CPU/CPU/CPUCpuUtil=ALARM,.../CPU/CPU/CPUCpuUtil=CLEAR,DELAY=5




alertResend

You can use the alertResend rule to specify the number of times the agent should resend outstanding alerts. You can configure alarm and warning alerts to have different resend values. Alerts are resent at the interval specified by the ResendAlertQueue parameter polling time and contain current alert information, such as, parameter value and status. A resend value of -1 causes PATROL KM for Event Management to resend outstanding alerts for object until the alert condition clears.

alertLocalCommand

You can use the alertLocalCommand rule to specify a script or program to perform notification, such as paging or e-mail. PATROL KM for Event Management contains sample notification scripts located in the PATROL PSL directory. The same notification command is typically set at the root (/) object level so that it applies to all PATROL objects (for example, application classes, instances, and parameters) with an ALERT status.

Table 47 alertResend Rule

Rule alertResend

Configuration Variable /AS/EVENTSPRING/ALERT/object/alertResend

Values Alarm_Resends,Warning_Resends

Example 2,1

Menu Command Access Event Management => Alert Settings => Local Alert Settings => Alert Resend

Table 48 alertLocalCommand Rule

Rule alertLocalCommand

Configuration Variable /AS/EVENTSPRING/ALERT/object/alertLocalCommand

Values notification script or program

Example /usr/patrol/my_notify.sh

Support supported by PATROL KM for Event Management version 2.4.05or later

Menu Command Access

Event Management => Alert Settings => Local Alert Settings => Notification Command

Chapter 5 167


arsCommand

You can use the arsCommand rule to specify a script or program that performs recovery procedures pertaining to the PATROL object with an ALERT status. PATROL KM for Event Management contains sample notification scripts located in the PATROL PSL directory.

You can specify that the recovery action command executes only for a specific alert status, such as INFORMATION, WARN, or ALARM by appending the status to the variable name. However, to run recovery actions for INFORMATION events, you must also set the variable allowInfoRecoveryActions to 1.

arsCmdType

You can use the arsCmdType rule to specify the command type to use when executing the recovery action command. This command is typically used when the recovery action requires special KM information, such as the PATROL password used to log into a database. The AS_EVENTSPRING application class contains a sample PATROL command type.

Table 49 arsCommand Rule

Rule arsCommand

Configuration Variable /AS/EVENTSPRING/object/arsCommand/AS/EVENTSPRING/object/arsCommandINFORMATION/AS/EVENTSPRING/object/arsCommandWARNING/AS/EVENTSPRING/object/arsCommandALARM

Values recovery script or program

Example /usr/patrol/filesystem_recovery.sh


Menu Command Access

Event Management => Alert Settings => Local Alert Settings => Recovery Action Commands

NOTE You must enable recovery actions using the Alert Actions menu command for the KM to execute these actions. See “arsAction” on page 161.


Remote Alert Settings

alertResetOnInit

You can use the alertResetOnInit rule to specify whether the agent should, upon an agent restart, close outstanding events (for example, alarms or warnings) that existed prior to the agent being shutdown. You may want to close these events because they are no longer applicable. You cannot apply this rule to specific PATROL objects. By default, this option is not enabled.

Remote Alert SettingsYou can use the Remote Alert Settings menu commands to specify the notification servers and the communication settings you want to use for remote notifications.

Table 50 arsCmdType Rule

Rule arsCmdType

Configuration Variable ■ /AS/EVENTSPRING/object/arsCmdType■ /AS/EVENTSPRING/object/arsCmdTypeINFORMATION■ /AS/EVENTSPRING/object/arsCmdTypeWARNING■ /AS/EVENTSPRING/object/arsCmdTypeALARM

Values command type

Example PSL


Menu Command Access

Event Management => Alert Settings => Local Alert Settings => Recovery Action Command Type

Table 51 alertResetOnInit Rule

Rule alertResetOnInit

Configuration Variable /AS/EVENTSPRING/ALERT/alertResetOnInit

Values 0 - Do not send reset alert1 - Send reset alert

Menu Command Access Event Management => Alert Settings => Local Alert Settings => Send Reset on Init

NOTE The notification server must be running when you set up PATROL KM for Event Management alert rules on remote agents.

Chapter 5 169

Remote Alert Settings

NOTIFICATION_SERVER

You can use the following notification server configuration variables to identify the primary and backup notification servers for the remote agents.

■ NOTIFICATION_SERVER1.defaultAccount—the user name and password for the primary notification sever

■ NOTIFICATION_SERVER2.defaultAccount—the user name and password for the backup notification sever

■ NOTIFICATION_SERVER1—hostname and port number of the primary notification server

■ NOTIFICATION_SERVER2—hostname and port number of the backup notification server

RemoteAgentCommSettings

You can use the RemoteAgentCommSettings configuration variable to configure the remote communication settings for the following situations:

■ the agent sending events to a notification server■ an availability monitor checking the availability of monitored agents

Table 52 Remote Alert Settings: Configure Notification Servers Configuration Variable

Configuration Variable/AS/EVENTSPRING/NOTIFICATION_SERVER1.defaultAccount (primary)/AS/EVENTSPRING/NOTIFICATION_SERVER2.defaultAccount (backup)

Values user/encrypted password

Example patrolns/FB0A195D062696

Menu Command Access Event Management => Quick Config => Remote Agent

Table 53 Remote Alert Settings: Configure Notification Servers Configuration Variable

Configuration Variable/AS/EVENTSPRING/NOTIFICATION_SERVER1 (primary)/AS/EVENTSPRING/NOTIFICATION_SERVER2 (backup)

Values host,agent port number

Example ns1,3181

Menu Command Access Event Management => Quick Config => Remote Agent

Table 54 Remote Alert Settings: Remote Communication Settings Configuration Variable

Configuration Variable /AS/EVENTSPRING/RemoteAgentCommSettings

Values TCPUDP,timeout,retries


Notification Target Rules

Notification Target RulesYou can use emailTargets rules to specify whom to notify (the target) when an alert condition occurs for a PATROL object. You can specify a different target for WARNING, ALARM, and INFORMATION conditions.

Notification targets are typically defined only on the notification server. If you define targets on the remote agent, you must use a remote notification system and remote notification targets. Remote notification targets are forwarded to the notification server for processing.

emailTargets

You can use emailTargets rules to specify e-mail accounts as notification targets.

Example UDP,100,3

Menu Command Event Management =>Alert Settings => Remote Alert Settings => Remote Comm Settings

TIP To prevent notification, use a special target name of NONE or leave the target blank. For example, if you set a default target for an application class and set the target to NONE for a particular instance or parameter in that application class, notifications for that instance or parameter are not sent.

NOTE The target type, such as page or e-mail, can be changed to any type of notification action. For example, trouble ticket targets are not required for trouble tickets. The target can perform any task programmed in the notification command.

Table 54 Remote Alert Settings: Remote Communication Settings Configuration Variable

Chapter 5 171


pagerTargets

You can use pagerTargets rules to specify one or more pagers as notification targets.

Table 55 Notification Targets: Email Target Configuration Variable

Rule: emailTargets


/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsLocalINFORMATION/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsLocalWARNING/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsLocalALARM/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsLocalESCALATED/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsLocal /AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsRemoteINFORMATION/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsRemoteWARNING/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsRemoteALARM/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsRemote

Values email_target1,email_target2,…mail_targetn

Example patrol,[email protected]

Menu Command Access

Event Management => Alert Settings => Notification Targets => Email

Table 56 Notification Targets: Pager Target Configuration Variable

Rule pagerTargets


/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsLocalINFORMATION/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsLocalWARNING/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsLocalALARM/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsLocalESCALATED/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsLocal/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsRemoteINFORMATION/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsRemoteWARNING/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsRemoteALARM/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsRemote

Values pager_target1,pager_target2,…pager_targetn

Example adminpg

Menu Command Access

Event Management => Alert Settings => Notification Targets => Pager



customTargets

You can use the customTargets rule to specify custom notification targets.

ttTargets

You can use ttTargets rules to specify trouble ticket notification targets.

Table 57 Notification Targets: Custom Target Configuration Variable

Rule customTargets


/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsLocalINFORMATION/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsLocalWARNING/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsLocalALARM/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsLocalESCALATED/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsLocal /AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsRemoteINFORMATION/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsRemoteWARNING/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsRemoteALARM/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsRemote

Values custom_target1,custom_target2,…custom_targetn

Example glamis

Menu Command

Event Management => Alert Settings => Notification Targets => Custom

Table 58 Notification Targets: TT Targets Configuration Variable

Rule ttTargets


/AS/EVENTSPRING/ALERT/TT/object/ttTargetsLocalINFORMATION/AS/EVENTSPRING/ALERT/TT/object/ttTargetsLocalWARNING/AS/EVENTSPRING/ALERT/TT/object/ttTargetsLocalALARM/AS/EVENTSPRING/ALERT/TT/object/ttTargetsLocalESCALATED/AS/EVENTSPRING/ALERT/TT/object/ttTargetsLocal/AS/EVENTSPRING/ALERT/TT/object/ttTargetsRemoteINFORMATION/AS/EVENTSPRING/ALERT/TT/object/ttTargetsRemoteWARNING/AS/EVENTSPRING/ALERT/TT/object/ttTargetsRemoteALARM/AS/EVENTSPRING/ALERT/TT/object/ttTargetsRemote

Values trouble_tix_target1,trouble_tix_target2,…trouble_tix_targetn

Example ttpatrol

Menu Command Event Management => Alert Settings => Notification Targets => Trouble Ticket

Chapter 5 173

Blackout Settings

Blackout SettingsYou can use the Blackout Periods menu commands to prevent notification during a specified time period, even if an alert condition occurs. You can specify multiple blackout times per day. Blackout periods apply to notification only and can be applied to most PATROL objects. For more information about blackout periods, see “Configuring Blackout Periods” on page 115.

blackoutPeriod

You can use the blackoutPeriod configuration variable to specify the start and stop times of a blackout period for a specified PATROL object.

__OVERRIDE__

You can use the __OVERRIDE__ configuration variable to override PATROL KM for Event Management rules based on the time of day. Using this command, you can establish multiple overrides per day.

NOTE If the type of alert condition (INFORMATION, WARNING, ALARM, or ESCALATED) is not specified for a notification target (for example, /AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsRemote), notification occurs for all alert conditions.

Table 59 Blackout Periods Configuration Variable

Rule blackoutPeriod

Configuration Variable /AS/EVENTSPRING/BLACKOUT/object/blackoutPeriod

Values day1 start1 stop1,day2 start2 stop2

Note: Start and stop times are in seconds past midnight.

Example Sat 3600 7200,Wed 3600 7200

Menu Command Access Event Management => Alert Settings => Blackout Periods


Notification Server Settings

Notification Server SettingsYou can use the Notification Server Settings menu command to perform actions specific to a notification server.

nsRemoteTargetSetting

You can use the nsRemoteTargetSetting configuration variable to specify the handling of remote targets received by the notification server. Table 61 on page 175 lists the options you can specify for the remote target setting.

Table 60 Overrides Configuration Variable

Configuration Variable /AS/EVENTSPRING/__OVERRIDE__/object/rule

Values day start stop=value_for_rule

Example Sat 0 86399,Sun 0 86399=oncallpager

Menu Command Access Event Management => Alert Settings => Overrides

Table 61 Notification Server Settings: Remote Target Setting Configuration Variable

Rule nsRemoteTargetSetting

Configuration Variable /AS/EVENTSPRING/NS/nsRemoteTargetSetting

Values ■ Ignore—remote targets are ignored. Notification is sent only to the local targets defined at the notification server.

■ Merge (default)—remote targets are merged with local targets defined at the notification server. For example, an email notification is sent to both the email addresses defined at the remote agent and the email addresses defined at the notification server.

■ Override—notification is sent only to the targets defined at the remote agent.

■ Forward—remote targets are forwarded. Use this option when you are using cascading notification servers in which one notification server is forwarding events to another notification server.

Example Merge

Menu Command Access Event Management => Alert Settings => Notification Server Settings => Remote Target Settings

Chapter 5 175

Custom Settings

Custom SettingsYou can use the following custom settings to reword notification messages and to assign custom identifiers to an object.

msgText

You can use the msgText rule to specify the message format for the subject line of the notification message. You can specify different formats for different types of alerts and for specific PATROL objects (applications, instances, or parameters).

Table 62 msgText Configuration Variable

Rule msgText


/AS/EVENTSPRING/ALERT/MSG/object/msgText/AS/EVENTSPRING/ALERT/MSG/object/msgTextINFORMATION/AS/EVENTSPRING/ALERT/MSG/object/msgTextWARNING/AS/EVENTSPRING/ALERT/MSG/object/msgTextALARM

Values message_replacement_textmessage_replacement_variablesmessage_replacement_text_and_variables

Example %HOSTNAME% has CPU Processor time of %PARAMETER_VALUE% for time zone %TIMEZONE% for %OS_TYPE%

For more information about replacement variables, see “NOTIFY_EVENT Fields” on page 5-157.

Menu Command Access

Event Management => Alert Settings => Alert Messages => Default Message Format

NOTE If you do not specify INFORMATION, WARNING or ALARM, the same message format is used for all events.


Custom Settings

msgBody

You can use the msgBody rule to specify the message format for the body of the notification message. You can specify different formats for different types of alerts and for specific PATROL objects (applications, instances, or parameters).

An example of a reworded message template is:

At run time, the message could be displayed as:

Table 63 msgBody Configuration Variable

Rule msgText


/AS/EVENTSPRING/ALERT/MSG/object/msgBody/AS/EVENTSPRING/ALERT/MSG/object/msgBodyINFORMATION/AS/EVENTSPRING/ALERT/MSG/object/msgBodyWARNING/AS/EVENTSPRING/ALERT/MSG/object/msgBodyALARM

Values message_replacement_textmessage_replacement_variablesmessage_replacement_text_and_variables

Example %HOSTNAME% has CPU Processor time of %PARAMETER_VALUE% for time zone %TIMEZONE% for %OS_TYPE%

For more information about replacement variables, see Table 35, “NOTIFY_EVENT Fields,” on page 5-157.

Menu Command Access

Event Management => Alert Settings => Alert Messages => Default Message Format

NOTE If you do not specify INFORMATION, WARNING or ALARM, the same message format is used for all events.

%HOSTNAME% has CPU Processor time of %PARAMETER_VALUE% for time zone %TIMEZONE% for %OS_TYPE%

Mercury has CPU Processor time of 99 for time zone Eastern Standard Time for NT 5.0 Service Pack 1

Chapter 5 177

Custom Settings

CustomId1 and CustomId2

You can use the CustomId1 and CustomId2 configuration variables to specify custom identifiers. These variables are commonly used to identify an application, such as Oracle, or a geographical area.

allowOperator

You can use the allowOperator configuration variable to control which PATROL KM for Event Management menu commands an operator can execute from a PATROL Operator console.

NOTE A special instance name of __ANYINST__ can be used for all instances of a parameter. If object is not specified, then the configuration variable defines the default message format.

Table 64 Custom Configuration Variables


/AS/EVENTSPRING/object/CustomId1/AS/EVENTSPRING/object/CustomId2

Values custom_identifier

Example financial_app


Menu Command Access

Event Management => Alert Settings => Custom Identifiers => CustomID1Event Management => Alert Settings => Custom Identifiers => CustomID2


Custom Settings

All configuration changes take affect immediately once they have been applied. The following are exceptions:

■ arsAction, only in certain circumstances■ RemoteAgentCommSettings

These configuration settings are updated by restarting the PATROL Agent after applying the configuration change.

Table 65 allowOperator Variable

Configuration Variable /AS/EVENTSPRING/MENU_COMMANDS/allowOperator

Values ■ all - all menu commands■ availability - Availability menu commands■ configNS - Quick Config -> Notification Server menu command■ configRemoteAgent - Quick Config -> Remote Agent menu command■ thresholds - Threshold menu commands■ interval - Poll time menu commands■ arsAction - Alert Action menu commands■ arsCommand - Recovery Action menu commands■ arsCmdType - Recovery Action Command Type menu commands■ overrides - Override related menu commands■ customId - Custom Identifier menu commands■ alertLocalCommand - Notification Command menu command■ alertSystem - Notification System menu command■ alertResend - Alert Resend menu command■ alertResetOnInit - SendResetOnInit menu command■ msgText - Alert Messages menu commands■ emailTargetsLocal - Local Email Target menu commands■ emailTargetsRemote - Remote Email Target menu commands■ pagerTargetsLocal - Local Pager Target menu commands■ pagerTargetsRemote - Remote Pager Target menu commands■ ttTargetsLocal - Local Trouble Ticket Target menu commands■ ttTargetsRemote - Remote Trouble Ticket Target menu commands■ customTargetsLocal - Local Custom Target menu commands■ customTargetsRemote - Remote Custom Target menu commands■ blackoutPeriod - Blackout Periods menu commands■ instanceFiltering - Instance Filtering menu commands


Chapter 5 179

Custom Settings

active

You can use the active configuration variable to set the status of an application class.

appClassSettingsStatusFlag

You can use the appClassSettingsStatusFlag to indicate whether PATROL KM for Event Management application class settings are used.

NOTE You cannot use this setting to activate an application class that is inactive by default in the KM. If you use the PATROL KM for Event Management to activate such an application class, the application class again becomes inactive after an agent restart.

Table 66 active Variable

Configuration Variable /AS/EVENTSPRING/APPLICATION_CLASSES/object/active

Values 0 = set active status to 0 (disable application class)1 = set active status to 1 (perform pre-discovery for the application class)2 = set active status to 2 (perform full discovery for the application class)

Support supported by PATROL KM for Event Management version 2.4.05.02 or later

NOTE You cannot use this setting to activate an application class that is inactive by default in the KM. If you use the PATROL KM for Event Management to activate such an application class, the application class again becomes inactive after an agent restart.

Table 67 appClassSettingsStatusFlag Variable


/AS/EVENTSPRING/APPLICATION_CLASSES/STATUSFLAGS/appClassSettingStatusFlag

Values 0 = use KM defaults1 = use PATROL KM for Event Management application class settings2 = refresh active rules



Availability

disableNotifyAnnotations

You can use the disableNotifyAnnotations variable to disable notification annotations for the NotifiedEvents parameter. By default, this variable is not provided; annotations are performed. To disable annotations, add this configuration variable to the agent using the PATROL Configuration Manager and set the value to 1.

maxEventsToReport

You can use the maxEventsToReport variable to specify the maximum number of NOTIFY_ EVENTS events to report in the console system output window when you run the PATROL KM for Event Management menu command Reports => All NOTIFY EVENTS.

AvailabilityYou can use the availability settings to specify the agents and hosts that PATROL monitors for availability.

Table 68 disableNotifyAnnotations

Configuration Variable /AS/EVENTSPRING/disableNotifyAnnotations

Values 0 = don’t disable annotations (default)1 = disable annotations

Example 1

Menu Command Access None


Table 69 disableNotifyAnnotations

Configuration Variable /AS/EVENTSPRING/maxEventsToReport

Values Any integer value. The default value is 100.

Example 100



Chapter 5 181

Availability

Targets

You can use the Targets configuration variable to specify the host to be monitored. You can also use this menu command to change the default SNMP settings and the SNMP Object ID.

snmpSettings

You can use the snmpSettings configuration variable to specify the SNMP ping information for the PATROL Agent on the managed system that you want to monitor for availability.

snmpOid

You can use the snmpOid configuration variable to specify the SNMP Object ID on the managed system that you want to monitor for availability. PATROL uses the SNMP object ID only when checking the availability of the remote agent on the managed system. It uses the object ID when making an SNMP call to the agent and checking for a response. You can use the default object ID or provide any other valid SNMP object ID.

Table 70 Add Target Configuration

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/Targets(Targets2)

Values host PATROL_Agent_port SNMP_port

Example glamis 3181 161,mirage - 161

Menu Command Access Event Management => Availability => Add Target

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/snmpSettings

Values SNMP_Community SNMP_Timeout SNMP_Retries

Example public,500,3


Configuration Variable /AS/EVENTSPRING/AVAILABILITY/snmpOid

Values SNMP_ObjectID

Example .1.3.6.1.2.1.1.3.0



Availability

Updated

Use the Updated configuration variable to indicate that changes have been made to the availability targets and availability checkers.

Primary

You can use the Primary configuration variable to specify the primary availability monitor.

Blackout

You can use the Blackout configuration variable to specify time periods to stop monitoring of a host or an agent.

NOTE The KM automatically sets the Updated variable to 1 whenever you make a change using the Availability menu command.

Table 71 Add Target: Updated Flag Configuration

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/Updated

Values 0 - Ignore changes to Targets and Primary configuration variables1 - Enable changes to Targets and Primary configuration variables

Table 72 Primary Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/Primary

Values host_primary_monitor PATROL_Agent_port SNMP_port

Example pismo 3181 161

Menu Command Access Event Management => Availability => Failover Settings => Identify Primary

NOTE The PATROL Agent that you use to run the Identify Primary menu command becomes the backup monitor.

Chapter 5 183

Availability

pingCmd

You can use the pingCmd configuration variable to specify the operating system command to use when checking host availability.

pingOkString

The pingOkString configuration variable is the string that appears in the output of the pingCmd.

NOTE If you specify one or more availability blackouts for a PATROL Agent or host, the KM stops monitoring that agent or host during the blackout period.

Table 73 Blackout Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/Blackouts/host_port

Values day1 start1 stop1, day2 start2 stop2

Example Sat 3600 7200,Wed 3600 7200

Menu Command Access Event Management => Availability => Blackout Periods

Table 74 PingCmd Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingCmd

Values absolute_path_to_OS_ping_command

Example /usr/patrol/myping.sh

Menu Command Access Event Management => Availability => Ping Command

Table 75 pingOKString Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingOkString

Values ping output

Example bytes



Availability

pingPacketSize

The pingPacketSize configuration variable defines the packet size of the ping command in bytes.

pingAttempts

The pingAttempts configuration variable defines the number of pings attempted.

pingArgs

The pingArgs configuration variable allows you to use custom ping arguments. The arguments defined by pingArgs are appended to the ping command defined by the configuration variable pingCmd.

If you assign a value to the configuration variable pingArgs, the configuration variables pingAttempts and pingPacketSize are ignored.

For more information about using this variable, see Table 78 on page 186 or “To Specify Ping Command Arguments” on page 93.

Table 76 pingPacketSize Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingPacketSize

Values number of bytes; if not specified, the default value is 32 bytes

Example 32



This variable is not supported on OpenVMS or iSeries.

Table 77 pingAttempts Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingAttempt

Values number of attempts; if not specified, the default value is 2 attempts

Example 2



This variable is not supported on OpenVMS or iSeries.

Chapter 5 185

Parameter Settings

checkerAccount.defaultAccount

You can use the checkerAccount.defaultAccount configuration variable to specify the account to use when performing pings against other PATROL Agents.

Parameter SettingsYou can use the Parameter Settings menu commands to customize PATROL parameter thresholds and polling times. These changes are stored externally from the KM and do not change the KM version.

THRESHOLDS

Using the Thresholds configuration variable, you can change the thresholds for all instances of a parameter or thresholds for a particular parameter instance. Changes apply only to the agent where the command was executed. This operation is similar to creating a localized parameter (overriding the global definition) by using a developer console.

Table 78 pingArgs Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingArgs

Values ping command arguments

Example -n 2 -|32



Table 79 Checker Account Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/checkerAccount.defaultAccount

Values username/PEM_encrypted_password

Example patrolns/FB0A195D062696

Menu Command Access Event Management => Availability => Checker Account

NOTE BMC Software recommends that you do use the PATROL Agent default account. The account could be locked out if an agent check fails because of an invalid login.


Parameter Settings

The following table provides a detailed description of the THRESHOLDS configuration rule.

Table 80 Parameter Settings: Thresholds Configuration


/AS/EVENTSPRING/PARAM_SETTINGS/THRESHOLDS/object

where object is the full parameter object name such as /FILESYSTEM/root/FSCapacity

Value parameter_settings

Example 1,1 0 100 0 0 2,1 1 50 0 0 1,1 51 100 0 0 2

Menu Command Access Event Management => Parameter Settings => Thresholds

Table 81 Understanding the THRESHOLDS Rule (Part 1 of 2)

Item Description

/AS/EVENTSPRING variable folder

/PARAM_SETTINGS variable folder

/THRESHOLDS variable folder

/NT_CPU application class

/__ANYINST__ a variable that indicates any instance of the application class. You could also specify a specific instance instead.

CPUprcrProcessorTimePercent

parameter name

1 indicates that the parameter is active

Border Settings

0 indicates that the border range is inactive

0 the border begin range

0 the border end range

0 specifies when to trigger alarm; 0 means immediately on the first occurrence

0 if the trigger value is non zero, this value specifies the number of occurrences before triggering an alarm

0 specifies that the state is OK

Alarm1 Settings

1 indicates that the Alarm 1 alarm is active

80 the Alarm 1 begin range

85 the Alarm 1 end range



Chapter 5 187

Parameter Settings

interval

You can use the interval configuration variable to specify poll times for standard and collector parameters.

paramSettingsStatusFlag

You can use the paramSettingsStatusFlag configuration variable to enable or disable the use of PATROL KM for Event Management thresholds or poll times. By default, they are enabled. For more information on using PATROL KM for Event Management to manage thresholds and poll times, see “Managing Parameter Thresholds and Poll Times” on page 104.

1 specifies that the state is WARN

Alarm 2 Settings

1 indicates that the Alarm 2 alarm is active

85 the Alarm 2 begin range

100 the Alarm 2 end range



2 specifies that the state is ALARM

Table 82 Parameter Settings: poll times Configuration


/AS/EVENTSPRING/PARAM_SETTINGS/POLLTIMES/object/interval


Values polltime_in_seconds

Example 90

Menu Command Access

Event Management => Parameter Settings => Polltimes

Table 81 Understanding the THRESHOLDS Rule (Part 2 of 2)

Item Description


Parameter Settings

processWildcards

You can use the processWildcards rule to enable the use of wildcards for instance names when specifying parameter thresholds and poll times.

Table 83 Parameter Settings: Status Flags Configuration


/AS/EVENTSPRING/PARAM_SETTINGS/STATUSFLAGS/object/paramSettingsStatusFlag


Note: To apply the setting globally, omit the object reference, as shown below:

/AS/EVENTSPRING/PARAM_SETTINGS/STATUSFLAGS/paramSettingsStatusFlag

Values 0 - PATROL KM for Event Management settings are ignored1 - PATROL KM for Event Management parameter settings have been processed2 - Refresh thresholds4 - Refresh poll times6 - Refresh thresholds and poll times

NOTE You can use a special instance name, __ANYINST__, for all instances of a parameter.

Table 84 Parameter Settings: poll times Configuration

Configuration Variable /AS/EVENTSPRING/processWildcards

Values 1 = enable wildcards

0 = disable wildcards

Example 1

Menu Command Access

None

Support supported by PATROL KM for Event Management version 2.700 or later

Chapter 5 189

Instance Filtering Settings

Instance Filtering SettingsYou can use the Instance filtering configuration variables to manage discovered application instances.

FilterList Configuration Variable

You can use the FilterList configuration variable to specify the application instances that you want to filter. For more information, see “Selecting Application Instances to Monitor” on page 112.

FilterType Configuration Variable

You can use the FilterType configuration variable to specify the type of instance filter. There are two filter types: Exclude and Include. Instances specified in an exclude filter list are not monitored. Instances specified in an include filter list are monitored. “Selecting Application Instances to Monitor” on page 112.

Table 85 Filter List Configuration Variable

Configuration Variable /AgentSetup/ApplicationClass.filterList

Values list_of_application_instances

Example C:,D:,E:,F:

Menu Command Access Event Management => Instance Filtering => Edit Filter List

Table 86 Filter Type Configuration Variable

Configuration Variable /AgentSetup/ApplicationClass.filterType

Values IncludeExclude

Menu Command Access Event Management => Instance Filtering => Edit Filter List


C h a p t e r 6
6 Parameters
This chapter list PATROL KM for Event Management parameters and shows their default settings. The following topics are discussed:

Parameter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Parameter Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Chapter 6 191

Parameter Summary

Parameter SummaryPATROL KM for Event Management parameters are in the following applications classes:

■ AS_EVENTSPRING■ AS_AVAILABILITY

Table 87 lists PATROL KM for Event Management parameters.

Table 87 PATROL KM for Event Management Parameters (Part 1 of 3)

Parameter Description

AS_EVENTSPRING Application Class

AlertTest tests the notification systems and rules without forcing a production parameter into an alert state

AgentLoginDenied Monitors failed login attempts to the agent. The alarm is immediate - not polling based.

To prevent a possible flood of notifications, this parameter alarms on the first occurrence and must be manually reset or reset by a recovery action. Each failed login attempt increments the parameter value by one and generates an annotation that contains the IP address and user name of the failed login account. You can use this information to troubleshoot communication problems with the notification server. For more information, see “AgentLoginDenied Parameter is in Alarm” on page 203.

NotifiedEvents the number of OK, ALARM, and WARN NOTIFY events processed by the PATROL KM for Event Management during the collection cycle. Data about each event is stored in a parameter annotation. For example, if the following 3 events are detected during the collection cycle, an OK, an ALARM, and a WARN event, then the value of the NotifiedEvents parameter is set to 3 and 3 annotations are created on the graph at that data point.

By default, the collection cycle is every 30 seconds. The collector parameter is EventCollector.

You can use information to troubleshoot notification problems. For more information, see Chapter 7, “Troubleshooting PATROL KM for Event Management”.


Parameter Summary

BlackoutEvents the number of blackout NOTIFY events processed by the PATROL KM for Event Management during the collection cycle. Blackout NOTIFY events are generated when a PATROL object generates an event and a PATROL KM for Event Management rule specifies that the object is in a blackout period and should not be forwarded. For more information about configuring blackout periods, see “Configuring Blackout Periods” on page 115.

Data about each event is stored in the event annotation.



EscalatedEvents the number of escalated NOTIFY events processed by the PATROL KM for Event Management during the collection cycle. Data about each event is stored in the parameter annotation.



EventCollector collects the NOTIFY events on the monitored agent and sets the value of the following parameters:

■ NotifiedEvents■ EscalatedEvents■ BlackoutEvents

RefreshParamSettings

updates parameter settings as required

ResendAlertQueue resends specified alerts

RetriggerEventQueue

retriggers events that failed to be sent to a notification server

AS_AVAILABILITY Application Class

AlertTest tests the notification systems and rules without forcing a production parameter into an alert state



Chapter 6 193

Parameter Defaults

Parameter DefaultsTable 88 lists the default properties for each PATROL KM for Event Management parameter.

AvailabilityMonitorColl

Collector that performs availability checks and sets the value of the following parameters:

■ HostPingFailures■ AgentPingFailures■ SnmpPingFailures

The AgentPingFailures parameter value is set during every second polling cycle. For example, if you set the poll time for the AvailabilityMonitorColl at 2 minutes, data is collected every 2 minutes for the HostPingFailures and SnmpPingFailures parameters, and every 4 minutes for the AgentPingFailures parameter.

AgentPingFailures indicates the availability of the PATROL Agent

The AgentPingFailures parameter value is set by the AvailabilityMonitorColl during every second polling cycle. For example, if you set the poll time for the AvailabilityMonitorColl at 2 minutes, data is collected every 4 minutes for the AgentPingFailures parameter.

HostPingFailures indicates the host is unavailable using an ICMP ping

SnmpPingFailures indicates the SNMP Agent is unavailable

Table 88 PATROL KM for Event Management Parameter Defaults (Part 1 of 2)

Parameter TypeAlarm1Alarm2 Border Schedule Icon Units A

nnot

ated

Act

ive

AlertTest Con 1-50

51-100

N/A N/A Gauge N/A N Y

AgentLoginDenied Con N/AN/A

0-0 N/A Graph N/A Y Y

NotifiedEvents Con N/AN/A

N/A N/A Graph N/A Y Y




Parameter Defaults

Parameter TypeAlarm1Alarm2 Border Schedule Icon Units A

nnot

ated

Act

ive

BlackoutEvents Con N/AN/A


EscalatedEvents Con N/AN/A


EventCollector Coll N/A N/A 30 seconds N/A N/A N Y

RefreshParamSettings Std N/AN/A

0-1000 1.5 minutes Graph N/A N Y

ResendAlertQueue Std N/AN/A

N/A 10 minutes Graph N/A N Y

RetriggerEventQueue Std N/AN/A

N/A 2 minutes Graph N/A N Y

AvailabilityMonitorColl

Coll N/AN/A

N/A 2 minutes 3 seconds

N/A N/A N Y

AgentPingFailures Con N/A1

N/A N/A Graph N/A N Y

HostPingFailures Con N/A1


SnmpPingFailures Con 12

N/A N/A Graph N/A N Y

Table 88 PATROL KM for Event Management Parameter Defaults (Part 2 of 2)

Chapter 6 195

Parameter Defaults


C h a p t e r 7
7 Troubleshooting PATROL KM for Event Management
This chapter contains information for troubleshooting PATROL KM for Event Management.

This chapter contains the following topics:

Configuration Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Cannot Send E-mail Notifications to Multiple Targets . . . . . . . . . . . . . . . . . . . . . 198Parameters are Unavailable or are Not Being Updated. . . . . . . . . . . . . . . . . . . . . 200Too Many E-mail Alerts Are Being Generated . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Parameters Show a Negative Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Parameter Annotations Show Incorrect Targets or Other Errors . . . . . . . . . . . . . 203AgentLoginDenied Parameter is in Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203The Availability Monitor is Not Pinging Frequently Enough . . . . . . . . . . . . . . . 205NOTIFY_EVENTS not Generated when Parameter is in Alarm . . . . . . . . . . . . . 205Parameters Setting Lost After Agent Restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Notification Message not Sent from OpenVMS Server . . . . . . . . . . . . . . . . . . . . . 207AS_AVAILABILITY Application Not Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . 207When Using event_trigger2() Statements, Notifications Sent to Wrong Target 207

Gathering Diagnostic Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Where to Find Diagnostic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Installation Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Determining PATROL KM for Event Management Version Number . . . . . . . . 209

Chapter 7 197

Configuration Problems

Configuration ProblemsThis section contains troubleshooting information for the following common configuration problems:

Cannot Send E-mail Notifications to Multiple Targets

When the notification server is on Windows computer and you are using Blat as the command-line e-mail client, e-mail notifications are not being sent to all of the e-mail addresses that are entered as notification targets.

Why set the /AS/EVENTSPRING/useEnvOnlyForCmds Rule to O?

The batch file uses the environment variable AS_NOTIFICATION_TARGETS to get the list of e-mail targets. PATROL does not allow commas to be passed to the environment variable.

Problem Type Page

Cannot Send E-mail Notifications to Multiple Targets 198

Parameters are Unavailable or are Not Being Updated 200

Too Many E-mail Alerts Are Being Generated 201

Parameters Show a Negative Number 202

Parameter Annotations Show Incorrect Targets or Other Errors 203

AgentLoginDenied Parameter is in Alarm 203

The Availability Monitor is Not Pinging Frequently Enough 205

NOTIFY_EVENTS not Generated when Parameter is in Alarm 205

Parameters Setting Lost After Agent Restart 206

Notification Message not Sent from OpenVMS Server 207

AS_AVAILABILITY Application Not Displayed 207

When Using event_trigger2() Statements, Notifications Sent to Wrong Target 207

Explanation Solution

The PATROL KM for Event Management is not configured to pass command-line arguments.

From the PATROL Configuration Manager, set the /AS/EVENTSPRING/useEnvOnlyForCmds rule to 0.

For more information, see “To Set the /AS/EVENTSPRING/useEnvOnlyForCmds Value” on page 199.



If you set the rule /AS/EVENTSPRING/useEnvOnlyForCmds to 0, the PATROL KM for Event Management passes the targets as command-line arguments first. Command-line arguments support commas.

Default Values

If you configure the notification server using the Quick Config menu option, the default value for /AS/EVENTSPRING/useEnvOnlyForCmds is 1 on Unix and AS/400 (iSeries) environments, which does not support commas.

In Windows and VMS environments, the default value is 0, which does support commas.

To Set the /AS/EVENTSPRING/useEnvOnlyForCmds Value


2 Choose the KM menu command Event Management => Alert Settings => Local Alert Settings => Notification Command => Set For Classes.

3 From the Choose Target Class(es) dialog box, select / (for all application classes) and select Accept.

The SET EVENT MANAGEMENT VARIABLE: alertLocalCommand dialog box is displayed, as shown in Figure 29.

Chapter 7 199


Figure 29 SET EVENT MANAGEMENT VARIABLE: alertLocalCommand dialog box

4 For the option Call command using Event Management KM environment variables only, select No.


6 Restart the PATROL Agent for the changes to be recognized.

Parameters are Unavailable or are Not Being Updated

In the PATROL console, the parameters NotifiedEvents, EscalatedEvents, or BlackoutEvents, located in the host Event Management folder, are unavailable or are not being updated.



Too Many E-mail Alerts Are Being Generated

PATROL is generating too many e-mail messages, or too many notifications in general or you are receiving notifications for events that are not important to you.


PATROL KM for Event Management is not configured correctly.

Verify that the arsAction rule is configured to perform notification.

The value should be 4 or 6. For more information, see “Configuring Recovery Actions” on page 120.

PATROL KM for Event Management KM not loaded.

Load the EVENT_MANAGEMENT.kml in the PATROL console. For more information, see “Loading Knowledge Modules” on page 52.


Parameters and thresholds need tuning.

Begin baselining and adjusting parameter thresholds.

Review the e-mail alerts to determine which parameters are generating alerts. Then adjust the parameter thresholds, deactivate threshold ranges, or deactivate parameters, as necessary. You can make these changes on one remote agent and then use the PATROL Configuration Manager to deploy these changes to other agents.

Blackout periods are needed. If you are receiving alerts because systems are down for maintenance, you should configure blackout periods that specify when alerts are not generated. For more information, see “Configuring Blackout Periods” on page 115.

The rule /AS/EVENTSPRING/ALERT/arsAction is set to 4.

Set the rule /AS/EVENTSPRING/ALERT/arsAction to 0.

If the arsAction rule is set to 4 for all PATROL objects, notifications are sent for all events. Instead, you may want to disable notification for all PATROL objects, by setting /AS/EVENTSPRING/arsAction to 0 at the remote agent. Then, enable notification only for the desired applications, instances, or parameters.

When you enable notification for a specific PATROL object, the following configuration variable is created:

/AS/EVENTSPRING/ALERT/object/arsAction

Chapter 7 201


Parameters Show a Negative Number

When you open the parameters NotifiedEvents, BlackoutEvents, or EscalatedEvents, located in the host Event Management application, they shows a negative number.


The notification command is failing at the notification server.

Fix the notification command.

Run the notification script from the command line using the PATROL default user account. If the script fails, determine why. Possible reasons could include:

■ the script has a typo■ the script may be in the wrong directory■ the script may lack an exit statement

If the script runs correctly, verify that you have entered the correct script name in your PATROL KM for Event Management rule. If you update the script, you must restart the PATROL Agent for the change to be recognized. For more information, see “Testing Notification Scripts” on page 70.

The PATROL default account does not have the proper permissions to execute the script file.

Check the permissions on the script file.

The PATROL Agent on the notification server is not running.

Verify that the PATROL agent on the notification server is running.

The remote notification event did not reach the notification server.

Resolve connection problems.

Verify whether you can ping the notification server from the remote agent. Use the same hostname specified during notification configuration. For more information about configuring remote agents, see “Configuring Remote Agents” on page 73.

The remote agent is configured incorrectly.

Verify the rules have correct values.

■ /AS/EVENTSPRING/alertSystem should be set to REMOTE.

■ /AS/EVENTSPRING/NOTIFICATION_SERVER1.defaultAccount rule exists at the remote agent. If this rule is not present, you need to specify the notification server as described in “Configuring Remote Agents” on page 73.



Parameter Annotations Show Incorrect Targets or Other Errors

When you examine the annotation for the NotifiedEvents, BlackoutEvents, or EscalatedEvents parameter, the text indicates that there is no action to take or it indicates that the targets are incorrect.

AgentLoginDenied Parameter is in Alarm

The AgentLoginDenied parameter, which monitors failed login attempts to the agent, is in alarm.


The notification rules are not configured correctly.

Examine the annotation information in the NotifiedEvents parameter at the remote agent and at the notification server. Examine the NOTIFY_EVENT and the REMOTE_NOTIFY_EVENT in the PATROL Event Manager. Determine whether the notification settings at the remote agent are appropriate. If a NOTIFY_EVENT is not being sent, see “NOTIFY_EVENTS not Generated when Parameter is in Alarm” on page 205.


The notification server account is not valid.

Supply a valid account and reset the parameter.

For more information, see “To Supply a Valid Account” on page 204.

A user has caused the PATROL default account to be locked out.

Determine the user account that generated the failed login.

On Windows, domain accounts are often locked out after 3 failed login attempts. If the PATROL default account is locked out, PATROL no longer works properly. This could happen if a user starts a console using an account that does not have the rights to connect to the agents.

For more information, see “To Determine the User Account that Generated the Failed Login” on page 204.

Chapter 7 203


To Supply a Valid Account

1 From the remote agent machine, supply the correct notification server account. For more information, see “Configuring Remote Agents” on page 73.

2 Reset the AgentLoginDenied parameter by accessing the remote agent Event Management application and choosing the KM menu command Reset AgentLoginDenied Alert.

For information about accessing KM menu commands on different consoles, see “Accessing KM Commands and InfoBoxes” on page 212.

To Determine the User Account that Generated the Failed Login

Review the AgentLoginDenied annotated data point to determine the account used during the failed login. The annotated data point format is as follows:

U P:X.Y@Z

U = login name

P == protocol (T=TCP, U=UDP)

X == agent side file descriptor used for the connection

Y == agent side local port used for the connection

Z == ip address of the client connecting (e.g., console, PatrolCli, remote agent, etc.

Example)

To analyze the annotated data more closely, you can run this Unix command:

It returns the hosts that attempted to connect to the notification server.

patrol T:[email protected]

dump_hist -param AgentLoginDenied -annotate | grep @ | awk -F@ {'print $2'} | sort | uniq



The Availability Monitor is Not Pinging Frequently Enough

The availability monitors are pinging less frequently than specified by the AvailabilityMonitorColl collector parameter. By default, the AvailabilityMonitorColl parameter schedules pinging every 2 minutes.

NOTIFY_EVENTS not Generated when Parameter is in Alarm

A parameter alarms but a NOTIFY_EVENT is not sent to the notification server.


The availability monitor is monitoring too many agents.

Monitor a maximum of 100 agents.

An availability monitor should monitor a maximum of 100 agents. If it monitors more than 100 agents, it may not be able to ping with the frequency specified by the parameter AvailabilityMonitorColl.


The parameter is being set to ALARM by way of an PSL command, not because it exceeded its threshold.

There is currently no workaround for this issue.

Some KMs change the state of a parameter using a PSL command. When this occurs, the parameter does not generate the standard state change events 9, 11, or 39, that it generates when it exceeds thresholds or is cleared. Thus, the PATROL KM for Event Management does not detect the ALARM state and does not generate a NOTIFY_EVENT.

The wrong standard events catalog (StdEvents.ctg) is being used.

Take the following steps:

1. For the PATROL Agent machine, obtain the updated catalog file, StdEvents.ctg.EVS, and copy it to %PATROL_HOME%\lib\knowledge.

2. Rename existing StdEvents.ctg to StdEvents.ctg.bak or any other suitable name.

3. Rename StdEvents.ctg.EVS to StdEvents.ctg.

4. Restart the PATROL Agent.

If you are using the PATROL Console for Windows or PATROL Console for Unix, make sure each is using the same StdEvents.ctg file that is used by the PATROL Agent.

Chapter 7 205


Parameters Setting Lost After Agent Restart

When using the PATROL Agent versions prior to 3.6.00, parameter poll times that are set using the PATROL KM for Event Management are not retained upon agent restart.

Removing the allowsendparamonly Variable

1 Move patrol.conf from %PATROL_HOME%\common\patrol.d to a secure location.

2 Using the PACFG (PATROL Agent Configuration) utility, specify that secured location.

3 Using Notepad (with word wrap disabled) or Wordpad, open patrol.conf.

4 Underneath the [AGENT] stanza, remove the following line:

5 Save and close the file.

6 Reinitialize the agent.


The allowsendparamonly variable exists in %PATROL_HOME%\common\patrol.d\patrol.conf file and is set to true.

Remove the allowsendparamonly variable.For instructions, see “Removing the allowsendparamonly Variable” on page 206.

If this variable exists and is set to True, then state change events for applications and instances are not generated. This reduces network traffic, but it also prevents the PATROL KM for Event Management from detecting when parameters become active after an agent restart. Thus, the PATROL KM or Event Management threshold and poll time settings are not applied.

etc/patrol.d/patrol.conf does not exist. If patrol.conf file doesn't exist then all the agent variables get set to TRUE. To resolve this problem, obtain a copy of the file patrol.conf and remove the allowsendparamonly variable, if it exists, as described in “Removing the allowsendparamonly Variable” on page 206.

To obtain the patrol.conf file, copy it from another computer or contact BMC Software Support.

allowsendparamonly=true



Notification Message not Sent from OpenVMS Server

On an OpenVMS notification server, a parameter alerts and creates a NOTIFY_EVENT but the notification message is not sent.

AS_AVAILABILITY Application Not Displayed

The AS_AVAILABILITY application icon is not displayed in the PATROL Console.

When Using event_trigger2() Statements, Notifications Sent to Wrong Target

When creating custom notifications using the event_trigger2() statement, notifications may be sent to the wrong target. This could occur if the origin of the event is external to the PATROL Agent machine from which you want to issue the notification.


The message subject line or body text contain too many characters.

Shorten the subject line to 80 characters or less and the body text to 255 characters or less.

In OpenVMS, the subject line of a mail message is limited to 80 characters and the e-mail message body is limited to 255 characters. If you exceed these limits, notification messages may not be sent. For more information, see “Using Notification Scripts” on page 64.

The notificiation rules are not configured properly.

For more information about configuring notification rules, see “Configuring Notification Servers” on page 71.


Availability targets have not been added.

Add availability targets. For more information, see “Configuring Availability Monitoring” on page 87.

The AS_AVAILABILITY application class instantiates only when availability targets have been defined.


The event_trigger2() statement obtains the application class, instance, and parameter name from the NOTIFY_EVENT details, not from the event origin. For more information see “Event Details” on page 156.

If this problem occurs, you will need to change your notification rules so that notifications are sent to the correct target.

Chapter 7 207

Gathering Diagnostic Information

Gathering Diagnostic InformationThis section contains general information on gathering diagnostic information for PATROL KM for Event Management.

Where to Find Diagnostic Information

The following table lists locations where you can find diagnostic information for problems with PATROL KM for Event Management.

Installation Logs

One log file is created each time the installer is run. The name of the log file is a combination of the computer name and a time stamp. The log file is located in the %USERPROFILE%\Application Data\BMCINSTALL\ directory.

For example, a log file for user bhunt on a Windows Server computer BHUNT_1 could be:

Type Location Description

Installation logs

%USERPROFILE%\Application Data\BMCINSTALL\

See “Installation Logs” on page 208.

System Output Window

See the documentation for you PATROL console.

The system output window contains messages relating to the operation of KMs, including error messages.

PATROL Event Manager

From the PATROL console, right-click the host and select Event Manager.

The PATROL Event Manager shows all of the PATROL related events for the host. You can check here to determine if NOTIFY_EVENTS are being generated.

parameter annotation data

From the PATROL console, access the host Event Management application and open one of the following parameters:

■ NotifiedEvents■ BlackoutEvents■ EscalatedEvents

Double-click the annotated data points on the graph.

These parameter annotations contains information about every notification related event that passes through the PATROL KM for Event Management.



C:\WINNT\Profiles\jrando\Application Data\BMCinstall\BHUNT_1-1005340189.log.

Determining PATROL KM for Event Management Version Number

Follow these steps to determine the PATROL KM for Event Management version that is installed on the host machine.

To Determine the PATROL KM for Event Management Version

1 From the PATROL console, access the host Event Management application.

2 Right-click the Event Management application and select the menu command InfoBox and described in “Accessing KM Commands and InfoBoxes” on page 212.

The PATROL KM for Event Management version is displayed next to KM Version.

Chapter 7 209

A p p e n d i x A
A Accessing Menu Commands, InfoBoxes, and Online Help
BMC Software offers several PATROL consoles from which you can view a PATROL Knowledge Module (KM). Because of the different environments in which these consoles run, each one uses a different method to display and access information in the KM. This appendix provides instructions for accessing the KM menu commands, InfoBoxes, and online Help on each of the PATROL consoles. See the PATROL for Windows Servers online Help for more detailed information about navigation in the PATROL Consoles.

Accessing KM Commands and InfoBoxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Accessing Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213


Accessing KM Commands and InfoBoxes

Accessing KM Commands and InfoBoxesTable 0-1 provides information about how to access KM commands and InfoBoxes from the various PATROL consoles.

Table 0-1 Accessing KM Commands and InfoBoxes

ConsoleTo access menu commands

To accessInfoBoxes

PATROL Console for Microsoft Windows Servers

In either the Desktop tree tab or work area, right-click a computer or application icon and choose KM Commands from the pop-up menu.

In either the Desktop tree tab or the work area, right-click an application class or parameter icon and choose InfoBox from the pop-up menu.

PATROL Console for Unix In the work area, right-click a computer or application icon to display a pop-up menu that contains KM-specific commands.

With the middle mouse button, click an application class or parameter icon.

PATROL Central Operator - Windows Edition

In the navigation pane, right-click a managed system or application icon and choose Knowledge Module Commands from the pop-up menu.

In the navigation pane, right-click a PATROL object and choose InfoBox from the pop-up menu.

PATROL Central Operator - Web Edition

In the tree view area, right-click an application icon and choose Knowledge Module Commands from the pop-up menu.

In the tree view area, right-click a PATROL object and choose Infobox from the pop-up menu.

212 PATROL® for Microsoft Windows Servers Getting Started

Accessing Online Help

Accessing Online HelpTable 0-2 provides information about how to access Help from each console.

NOTE If you are trying to access Help from a Unix console, see the PATROL Installation Reference Manual for specific instructions about installing and setting up a browser in the Unix environment.

Table 0-2 Accessing Online Help (Part 1 of 2)

ConsoleTo access product help

To access application class help

To access parameter help

PATROL Console for Microsoft Windows Servers

From the console menu bar, choose Help => Help Topics => PATROL Knowledge Modules.

Double-click an application class in the KM tab of the console. From the Application Properties dialog box, click the Help tab. Then click Show Help.

■ Right-click a parameter icon and choose Help On from the pop-up menu.

■ Double-click a parameter icon; click the ? icon or Help button in the parameter display window.

■ Double-click a parameter in the KM tab of the console; from the properties dialog box, click the Help tab; then click Show Help.

PATROL Console for Unix

From the console menu bar, choose Help On => Knowledge Modules.

Choose Attributes => Application Classes and double-click the application name. Click Show Help in the Application Definition dialog box.

Right-click a parameter icon and click Help On.


Accessing Online Help

PATROL Central Operator - Windows Edition

From the console menu bar, choose Help => Help Topics. In the Contents tab, click the name of your product.

In the Operator tab of the navigation pane, select an application icon and press F1.

In the Operator tab of the navigation pane, select a parameter icon and press F1.

PATROL Central Operator - Web Edition

In the upper right corner of PATROL Central, click Help and choose PATROL KM Help.

In the tree view, right-click an application class and choose Help.

In the tree view, right-click a parameter and choose Help.

Table 0-2 Accessing Online Help (Part 2 of 2)

ConsoleTo access product help

To access application class help

To access parameter help

214 PATROL® for Microsoft Windows Servers Getting Started

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Index

Symbols%AGENT_VERSION% 160%ALARM_MAX% 159%ALARM_MIN% 159%APPCLASS% 158%APPINSTANCE% 158%AVE10% 158%CUSTOM_ID1% 160%CUSTOM_ID2% 160%DATE% 158%EVENT_CATALOG% 160%EVENT_CLASS% 160%EVENT_ID% 159%EVENT_SEVERITY% 160%EVENT_STATUS% 160%EVENT_TYPE% 160%HOSTNAME% 157%ICON_NAME% 158%IPADDRESS% 157%LAST10% 158%LAST10TP% 159%LAST10TS% 159%NOTIFY_EVENT_ID% 160%OS_TYPE% 159%PARAMETER_NAME% 158%PARAMETER_STATUS% 158%PARAMETER_VALUE% 158%PARENT_INSTANCE% 158%PATROL_HOME% 160%TCP_PORT% 157%TIME% 158%TIMEZONE% 158%UDP_PORT% 157%USERDEFINED% 159__ANYINST__ 149, 166, 189__appl_class__ 124__instance__ 124__nfile__ 124__output__ 125__OVERRIDE__ 174__param__ 124__param_status__ 124__param_value__ 124__src_event_id__ 124__udefvar__ 125, 143

Aaccounts

adminstrative rights required for 28availability monitoring 92console connection 28domain 28generating failed login alarms 204operator 28root 29setting up for installation 27Unix 28Windows 27

action scripts, AlarmPoint 98active (configuration variable) 180ActiveX control 66addresses

default 72email, multiple 198paging 99

AgentLoginDenied 203defined 192resetting 204troubleshooting 203using annotation data 204

AgentPingFailures 194agents

applying settings to 111assigning notification servers to 73configuring 73–75maximum to monitor 61monitoring for availability 87–93persistent connection to 75protocol settings 79tuning 91where to install 32

alarm rangesdefault 194setting 106

AlarmPointbenefits 95integrating with 94–103java client 21, 96notification script for 95

215


alarmsgenerating notification for 128resetting 204triggering 106tuning 201

alert condition 174alertLocalCommand

defined 167using 99

alertResenddefined 167using 19, 20, 78

alertResetOnInitdefined 169using 19

alertsblacking out 115–120clearing outstanding 77configuring 76false 77resending 78troubleshooting 201variables for 158

alertSystemdefined 162troubleshooting 202using 19, 20, 72, 76

AlertTest 193aliases, account 29ALL_COMPUTERS.KM 43allowInfoRecoveryActions 165allowOperator 178allowOverrides 163allowsendparamonly variable 206annotations

disabling 181parameter 194troubleshooting 203, 208using in recovery actions 140–144

AP_PATROL_EmailActionScriptV521-01.ppx 98AP_PATROL_FaxActionScriptV521-01.ppx 98APAgent.xml 96appClassSettingsStatusFlag 180application classes

AS_AVAILABILITY 23AS_EVENTSPRING 23hierarchy 23icons 23variable for 158

architecture 16arguments

command-line 164, 198NOTIFY_EVENT 156ping command 93

arsActiondefined 161troubleshooting 201

216 PATROL Knowledge Module for Event Managemen

arsAction, continuedusing 19, 85, 99

arsCmdTypedefined 168using 19, 142

arsCommanddefined 168using 19, 20, 142

AS/400See also iSeriesinstalling on 42scripts 67subject line limitations 80

AS_AVAILABILITY.km 55defined 23InfoBox items 24loading 53preloading 91troubleshooting 207

AS_EVENTSPRING.kmdefined 23InfoBox items 24loading 53

AS_EVENTSPRING_ALL_COMPUTERS.km 53AS_EVSLocalAlertNotify.bat

editing 68requirements for using 66

AS_EVSLocalAlertNotify.pllocation 65requirements for using 66

AS_EVSLocalAlertNotify.sh 65AS_EVSLocalAlertNotifyAP.bat 99AS_EVSLocalAlertNotifyAP.sh 99availability

blackouts 184monitoring 87–93

AvailabilityMonitorColldefined 194troubleshooting 205using 61

Bbacking up notification scripts 69backup availability monitor 89backup notification servers 58batch file 66best practices 61Blackout (configuration variable) 183BlackoutEvents

annotations 208defined 193troubleshooting 203

blackoutPerioddefined 174using 19

t User Guide


blackouts, configuring 115–120Blat

defined 65troubleshooting 198version tested with 66

BMC Software, contacting 2body, notification message 80border, parameter 105Bourne shell 45

CC shell 45cache, PATROL 43changing

account, availability monitoring 92notification messages 79notification targets 171parameter thresholds 104ping commands 93poll times 107what is being monitored 112

checkerAccount.defaultAccountdefined 186using 92

clearingAgentLoginDenied parameter 204false alerts 77

client, java 21collection period, setting 107colormap option 45command-line 198commands

menu 151operating system 142ping, changing 93

commas in variables 157configuration variables

__ANYINST__ 189__OVERRIDE__ 174active 180alertLocalCommand 167alertResend 167alertResetOnInit 169alertSystem 162allowInfoRecoveryActions 165allowOperator 178allowOverrides 163appClassSettingsStatusFlag 180arsAction 161arsCmdType 168arsCommand 168Blackout 183blackoutPeriod 174checkerAccount.defaultAccount 186CustomId1 and CustomId2 178

configuration variables, continuedcustomTargets 173disableNotifyAnnotations 181emailTargets 171filterList 190filterType 190interval 188LoginDeniedIgnoredUsers 164msgBody 177msgText 176NOTIFICATION_SERVER1.defaultAccount 170nsRemoteTargetSetting 175pagerTargets 172paramSettingsStatusFlag 188pingArgs 185pingAttempts 185pingCmd 184pingOkString 184pingPacketSize 185Primary 183processWildcards 189RemoteAgentCommSettings 170setParameterValue 166snmpOid 182snmpSettings 182spoolDirectory 165Targets 182Thresholds 186ttTarget 173Updated 183useEnvOnlyForCmds 164userdefined 157

configuringalarm ranges 104AlarmPoint 96alarms 104availability monitoring 87–93backup availability monitor 89blackouts 115–120globally 134notification servers 71–73ping command 93poll times 107primary availability monitor 87recovery actions 120–125remote agents 73–75thresholds 104

connection, persistent 75consoles

connection accounts 28supported 26

copying rules 134custom installation option 35customer support 3CustomId1 and CustomId2

defined 178using 19

217


customizingnotification messages 79ping command 93scripts 67–69

customTargetsdefined 173using 21, 99

Ddate variables 158default email account 72default port number 27default values, parameter 194defining

notification servers 58remote agents 58targets 60where to place rules 61

dependencies 55deploying settings 59designing

availability monitoring 61notification servers 60

diagnosing problems 197–209disableNotifyAnnotations 181disabling

annotations 181monitoring of specific instances 112notification 85parameters 109rules 86use of event management KM thresholds 112

displaying in console 55

Eediting

notification messages 79scripts 67–69

electronic product download (EPD) site 31emailTargets

defined 171using 19

enablingftp 29notification 141parameters 109PATROL KM for Event Management thresholds 112recovery actions 121

enterprise console 59environment variables

LANG 45PATH 45PATROL_BROWSER 46


environment variables, continuedsetting for Help browser 45using in notification command 200

EPD (Electronic Product Download) site 31error messages 208EscalatedEvents 193

annotations 208troubleshooting 203

event catalog variable 160event class variable 160event severity variable 160event status variable 160event type variable 160event_trigger2() statement 207EventCollector 193events

ID, variables for 159NOTIFY_EVENT 156PATROL standard 19REMOTE_NOTIFY_EVENT 156size limitations 157standard 205translating 20

examplee-mail rule 154PATROL objects 153ping command 93, 94rule inheritance 154usage scenarios 128–150using targets 136wildcard usage 108

eXceed 45excluding instances from monitoring 112exit statement 202

Ffailed login 204failover

configuring 89features 17

filtering objects to monitor 112filterList

defined 190using 114

filterTypedefined 190using 113

first time installation 37fixes, installing 30ftp, enabling 29

HHelp, online 211

t User Guide


hierarchy, rule 154host macro 94hostname variable 157HostPingFailures 194

IICMP ping 194icon name variable 158icon, parameter 194importing action scripts 98inheritance, rule 154installation

custom option 35log files 208preparing for 30setting up installation accounts 27system requirements 26typical option 35Unix account requirements 28Windows account requirements 27

installingAlarmPoint java client 96for the first time 37on AS/400 (iSeries) 42patches 30upgrading from an earlier version 43where to install PATROL Agent 32

instance name__ANYINST__ 189using wildcards to represent 107variable 158

integrationAlarmPoint 94–103Blat 65PATROL Enterprise Manager (PEM) 20

intervalcollection, changing 107configuration variable 188

IP address variable 157iSeries

See also AS/400installing on 42scripts 67subject line limitations 80

Jjava client, AlarmPoint 96

KKMs

determining versions of 209installing individual 35

KMs, continuedinstalling QuickStart packages 35loading and unloading 52preloading 52upgrading from an earlier version 43

Korn shell 45

LLANG environment variable 45license requirements 27Linux

scripts 64supported versions 26

loading KMswith the PATROL Console for Unix 55with the PATROL Console for Windows 54

local installation 31local notification 162location, rule 61lock, account 203login, failed 204LoginDeniedIgnoredUsers 164logs, installation 208

MMAIL utility 67mailx 64Make Connection Persistent option 75managed system role 32MAPI scripts 67maxEventsToReport 181maximum agents to monitor 61menu commands, accessing 211–212merging blackout settings 118messages

body 177customizing 140error log 208rewording 79subject line 176

migrating from earlier version 43monitoring

agent availability 87–93notification servers 60specific instances 112

msgBodydefined 177using 19

msgTextdefined 176using 19

multiple targets, email 198

219


Nnegative value, parameter 202Netscape Navigator 44new PATROL users

easy install option 35installing for the first time 37

NFS 29notification

local versus remote 162scripts, using 64–71server 17, 58system, configuring 72types supported 69

notification messagesbody text 80length 80rewording 79subject line 80where to send from 72

notification scriptsbacking up 69customizing 69editing 67specifying 72testing 70

notification serversbenefits of 58configuring 71–72defining 58monitoring for availability 60primary and backup 58protocol settings 79providing security for 59

notification targetsdefining 72types 70

NOTIFICATION_SERVER1defined 170using 73

NOTIFICATION_SERVER1.defaultAccountdefined 170troubleshooting 202using 73

NOTIFICATION_SERVER2defined 170using 73

NOTIFICATION_SERVER2.defaultAccount 170NotifiedEvents

annotations 181, 208defined 192troubleshooting 203usage example 143

NOTIFY_EVENTdescription 156missing 205triggering 156


NOTIFY_EVENT, continuedtroubleshooting 203

nsRemoteTargetSetting 175

Oobjects, PATROL 153OpenVMS

ping command 94scripts 67subject line limitations 80support for 26troubleshooting 207

operating systems, support for 26operator accounts 28OS (operating system)

command type 142type, variable 159

OS(operating system)supported 26

output window, system 208overrides

allowing 163variable 174

PPACFG (PATROL Agent Configuration) utility 206pagerTargets 172parameters

activating 105AgentLoginDenied 192AgentPingFailures 194AlertTest 192, 193AvailabilityMonitorColl 194BlackoutEvents 193default values 194EscalatedEvents 193EventCollector 193HostPingFailures 194list of 192NotifiedEvents 192RefreshParamSettings 193ResendAlertQueue 193RetriggerEventQueue 193set value 166SnmpPingFailures 194variables for 158

paramSettingsStatusFlagdefined 188using 111

parent instance variable 158partitions, installing on 29patches, installing 30PATH environment variable 45

t User Guide


PATROL AgentsSee also agentsversion of, variable for 160where to install 32

PATROL Configuration Managericon 22using 134

PATROL Enterprise Manager (PEM) 59PATROL Event Translator (PET) 20PATROL objects 153PATROL Script Language (PSL) 124PATROL security 34PATROL.conf 206PATROL_BROWSER environment variable 46PATROL_CACHE 43pconfig variables 17PEM (PATROL Enterprise Manager) 59Perl scripts 65permissions 202persistent agent connection 75PET (PATROL Event Translator) 20pingArgs

defined 185using 93, 94

pingAttempts 185pingCmd

defined 184OpenVMS 94using 93

pingingarguments 93commands 93InfoBox items 24on OpenVMS 94problems with 205variables 184–186

pingOkString 184pingPacketSize 185planning

availability monitoring 61installation 30notification 58

platforms, supported 26poll times

applying to agent 111disabling 112setting 107

practices, best 61preloading KMs 52preparing for installation 30Primary (configuration variable) 183problem resolution 197–209processWildcards

defined 189using 111

productapplication classes 23architecture 16capabilities 15components 15features 16uninstalling in Windows environments 48

product support 3protocol settings 79PSL (PATROL Script Language) 124

Rranges, alarm 106recommendations, rule location 61recovery actions

about 121allowing 161configuring 120–125enabling 121examples 144rule location 63testing 149

redundancy 58, 60RefreshParamSettings 193remote agents, assigning notification servers to 73remote installation 31REMOTE_NOTIFY_EVENT

triggering 156troubleshooting 203

RemoteAgentCommSettingsdefined 170using 79

removingannotations 181customized KM files 43menu commands 43notification 85

renaming notification scripts 69requirements

license 27system 26Unix account 28Unix script 65Windows account 27Windows script 66

ResendAlertQueue 193resending alerts 78Reset AgentLoginDenied Alert menu command 204restart, agent 206RetriggerEventQueue 193rewording

default notification message 81example 136messages 79variables 81

221


rules__OVERRIDE__ 174See also configuration variablesactive 180alertLocalCommand 167alertResend 167alertResetOnInit 169alertSystem 162allowOperator 178allowOverrides 163appClassSettingsStatusFlag 180arsAction 161arsCmdType 168arsCommand 168Blackout 183blackoutPeriod 174checkerAccount.defaultAccount 186copying 134CustomId1 and CustomId2 178customTargets 173disableNotifyAnnotations 181e-mail 154emailTargets 171example 153filterList 190filterType 190hierarchy 153hierarchy of 154inheritance 154inheritance of 154interval 188LoginDeniedIgnoredUsers 164loginDeniedIgnoredUsers 164msgBody 177msgText 176notification server 170nsRemoteTargetSetting 175overriding 86pagerTargets 172paramSettingsStatusFlag 188pingArgs 185pingAttempts 185pingCmd 184pingOkString 184pingPacketSize 185Primary 183processWildcards 189RemoteAgentCommSettings 170setParameterValue 166snmpOid 182snmpSettings 182spoolDirectory 165Targets 182testing 84Thresholds 186ttTarget 173Updated 183


rules, contineduseEnvOnlyForCmds 164using wildcards in 107where to locate 61

Sscalability 205scenarios 128–150schedule, parameter 195scheduling interval, setting 107scripts

action 98AlarmPoint 98, 99AS/400 (iSeries) 67backing up 69batch file 66customizing 69editing 67–69Linux 64OpenVMS 67Perl 65renaming 69testing 70Unix 64using 64–71using exit statements in 202Windows 65

securityaccount 28changing levels 34notification server 59

SED Utility 143Send Distribution utility 67send_mapi.vbs 66sendmail.vbs 66servers

deploying settings to 59monitoring for availability 60notification 71

setParameterValuedefined 166using 103

setting environment variables for Help browser 45shells

Bourne 45C 45Korn 45

SMTP scripts 67snmpOid 182SnmpPingFailures 194snmpSettings 182spoolDirectory 165standard events catalogue 43standard events, PATROL 19, 159, 205StdEvent.ctg 43

t User Guide


StdEvents.ctg.EVS 205stopping

notification 85the monitoring of objects 112

subject lineback slashes in 81length limitations 80notification message 80rewording 79rewording variables 81

support, customer 3supported platforms 26system output window 208system requirements 26

Ttabs in variables 157targets

availability monitoring 88custom 21example 136rules 171–174using multiple 198where to locate 61

Targets (configuration variable) 182TCP port variable 157TCP protocol 79technical support 3telnet, enabling 29testing

AlarmPoint java client 97notification scripts 70notification using AlarmPoint 103recovery actions 149rules 84

thresholdsapplying to agent 111configuration variable 186disabling 112PATROL KM for Event Management 104rule for 187setting 104tuning 201

time variables 158, 159Tivoli 59Trigger NOTIFY_EVENT option 101triggering alarms 106troubleshooting 197–209ttTarget

defined 173using 70

typical installation option 35

UUDP Port variable 157UDP protocol 79umask setting 29uninstalling 48units, parameter 194Unix

account requirements 28browser requirements 44scripts 64subject line limitations 80using for availability monitoring 61

unloading KMswith the PATROL Console for Unix 57with the PATROL Console for Windows 57

Updated (configuration variable) 183upgrading 43

backing up scripts prior to 30from an earlier version of the KM 43

useEnvOnlyForCmdschanging value of 199defined 164troubleshooting 198

user account 45User defined variables 159userdefined configuration variable 157

Vvariables

alarm settings 159alert 158application class 158date 158disableNotifyAnnotations 181event catalog 160event class 160event ID 159event severity 160event status 160event type 160hostname 157icon name 158instance name 158IP address 157maxEventsToReport 181message-replacement 157–161OS type 159parameter 158parent instance 158PATROL Agent version 160PATROL_BROWSER 46pconfig 17pingArgs 186pingAttempt 185

223


variables, continuedpingPacketSize 185TCP port 157time 158, 159UDP port 157user-defined 159using tabs or commas in 157

VB (Visual Basic) 65verifying discovery 64version, determining 209Visual Basic (VB) 65VMware, support for 29

WWhat If? feature 84wilcards 107Windows

accounts 27scripts 65

t User Guide

*52965**52965**52965**52965*

*52965*

patrol km for event management - bmc software · patrol® km ® for event management 3 customer...

Documents