PATROL Knowledge Module For Event Management User Guide

PATROL KM for Event Management
User Guide
Supporting
PATROL KM for Event Management 2.7 PATROL 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 INC 2101 CITYWEST BLVD HOUSTON TX 77042-2827 USA Telephone 713 918 8800 or 800 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.
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
s s s s s s s
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 support@bmc.com. 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:
s
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
s s s
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
PATROL KM for Event Management
PATROL Knowledge Module for Event Management User Guide
Contents
Chapter 1 Product Components and Capabilities 15 16 16 17 17 17 18 19 20 21 22 22 22 22 23 23 24 25 26 26 27 29 30 30 30 31 31 32 32 34 34 34 35 36 37 37 42 43
5
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Typical Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rules Stored as Pconfig Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sending Notification: Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sending Alerts to an Enterprise Console: Process Flow . . . . . . . . . . . . . . . . . . . . . Sending Pages using AlarmPoint: Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the PATROL Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PATROL Configuration Manager Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tasks that Must be Completed Using PATROL KM for Event Management . . . Application Classes and Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 2 Installing and Migrating PATROL KM for Event Management
Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Machine Support Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backing up the Notification Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking for Product Patches or Fixes Before Installing. . . . . . . . . . . . . . . . . . . . . Determining How to Install Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining Where to Install the PATROL Agent. . . . . . . . . . . . . . . . . . . . . . . . . . Determining Where to Install KMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PATROL Security Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assessing and Implementing a Different Security Level . . . . . . . . . . . . . . . . . . . . Typical and Custom Installation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing into a PATROL 3.3.x or 3.4.x Unix Environment . . . . . . . . . . . . . . . . . . First-Time Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing For the First Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing on AS/400 (iSeries) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading from an Earlier Version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remove Customized KM Files From the PATROL_CACHE . . . . . . . . . . . . . . . . . 43 Remove Existing Menu Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Considerations for Using Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Browser Version Required for Viewing PATROL Console for Unix Help . . . . . . 44 Additional Considerations for Using Online Help for Unix . . . . . . . . . . . . . . . . . . 44 Uninstalling PATROL KM for Event Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Determining the Version of the Installation Utility . . . . . . . . . . . . . . . . . . . . . . . . . 47 Uninstalling 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 . . . . . . . . . . . . . . . . . . . . . 51 Loading and Preloading KMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Determining Which KMs to Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 KM Files Preloaded on Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Loading and Unloading KMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Loading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Verifying that PATROL KM for Event Management KM is Loaded . . . . . . . . . . . 55 Unloading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Configuration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Defining Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Defining Notification Targets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Defining Availability Monitors and Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Deciding Where to Place Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Configuring Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Recommended Configuration Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Using Notification Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Testing Notification Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Configuring Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Configuring Remote Agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Configuring Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Rewording Notification Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Setting Notification Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Testing Notification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Disabling Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Configuring Availability Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Configuring an Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Configuring a Backup Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Configuring the Availability Monitor Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Specifying an Availability Monitoring Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Changing the Ping Command Used for Availability Monitoring . . . . . . . . . . . . . 93 Integrating with AlarmPoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 AlarmPoint Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Installing and Configuring AlarmPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Installing the AlarmPoint Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Configuring the AlarmPoint Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Testing the Java Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Using Action Scripts for AlarmPoint 5.2.01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6 PATROL Knowledge Module for Event Management User Guide
Configuring Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Testing Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Managing Parameter Thresholds and Poll Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Benefits of Using the PATROL KM for Event Management. . . . . . . . . . . . . . . . . 104 Setting Collector Poll times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Using Wildcards to Represent PATROL Instance Names. . . . . . . . . . . . . . . . . . . 107 Activating and Deactivating Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Applying Thresholds and Poll Time Changes to the Agent . . . . . . . . . . . . . . . . . 111 Disabling the use of PATROL KM for Event Management Thresholds and Poll Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Specifying What to Monitor or Exclude from Monitoring . . . . . . . . . . . . . . . . . . . . . 112 Selecting Application Instances to Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Excluding Application Instances from Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 114 Configuring Blackout Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 About Notification Blackout Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Configuring Notification Blackouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Configuring Availability Blackouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Configuring Recovery Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 About Recovery Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Enabling PATROL KM for Event Management Recovery Actions . . . . . . . . . . . 121 Specifying a Recovery Action Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Specifying a Recovery Action Command Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Using PSL Recovery Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Chapter 4 Usage Scenarios 127 128 128 129 130 130 130 132 135 136 138 140 140 141 141 141 142 143 143 144 144 145 145 146 146
7
Sending E-mail Notification When Disk Space is Low . . . . . . . . . . . . . . . . . . . . . . . . Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting a Mail Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading the PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . . . . Defining the Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the Remote Agent NT1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying an E-mail Target for Low Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . Rewording the Notification Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sending E-mail Notification for CPU Usage that Includes Parameter Annotations Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of Annotated Data Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling Recovery Actions and Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Recovery Action Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Notification Command Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Recovery Action that Runs Under a Specified Account . . . . . . . . . . . Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing Recovery Action Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling Recovery Actions for ArchFreeSpace on Agent Computer . . . . . . . . . Defining the Recovery Action Type for Agent Computer . . . . . . . . . . . . . . . . . .
Storing the Encrypted Password as a Pconfig Variable . . . . . . . . . . . . . . . . . . . . . 147 Configuring the PSL Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Summary of Rules Created. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Testing the Recovery Action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Chapter 5 Rules and Configuration Variables 151
PATROL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Example: PATROL Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Example: Rule Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Example: PATROL KM for Event Management E-mail Rule . . . . . . . . . . . . . . . . 154 NOTIFY_EVENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 How the NOTIFY_EVENT and REMOTE_NOTIFY_EVENT are Triggered . . . 156 Event Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Order of Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Empty Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Using the Variable userdefined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Event Size Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 NOTIFY_EVENT Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Alert Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 arsAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 alertSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 allowOverrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 loginDeniedIgnoredUsers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 useEnvOnlyForCmds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 allowInfoRecoveryActions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 spoolDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 setParameterValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Local Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 alertResend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 alertLocalCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 arsCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 arsCmdType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 alertResetOnInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Remote Alert Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 NOTIFICATION_SERVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 RemoteAgentCommSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Notification Target Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 emailTargets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 pagerTargets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 customTargets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 ttTargets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Blackout Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 blackoutPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 __OVERRIDE__ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Notification Server Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 nsRemoteTargetSetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Custom Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 msgText . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 msgBody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
CustomId1 and CustomId2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . allowOperator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . appClassSettingsStatusFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . disableNotifyAnnotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . maxEventsToReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . snmpSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . snmpOid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Primary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Blackout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pingCmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pingOkString . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pingPacketSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pingAttempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pingArgs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . checkerAccount.defaultAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameter Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . THRESHOLDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paramSettingsStatusFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . processWildcards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instance Filtering Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FilterList Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FilterType Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 6 Parameters
178 178 180 180 181 181 181 182 182 182 183 183 183 184 184 185 185 185 186 186 186 188 188 189 190 190 190 191
Parameter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Parameter Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Chapter 7 Troubleshooting PATROL KM for Event Management 197 198 198 200 201 202 203 203 205 205 206 207 207 207 208 208
9
Configuration Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cannot Send E-mail Notifications to Multiple Targets . . . . . . . . . . . . . . . . . . . . . Parameters are Unavailable or are Not Being Updated. . . . . . . . . . . . . . . . . . . . . Too Many E-mail Alerts Are Being Generated . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameters Show a Negative Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameter Annotations Show Incorrect Targets or Other Errors . . . . . . . . . . . . . AgentLoginDenied Parameter is in Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Availability Monitor is Not Pinging Frequently Enough . . . . . . . . . . . . . . . NOTIFY_EVENTS not Generated when Parameter is in Alarm . . . . . . . . . . . . . Parameters Setting Lost After Agent Restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notification Message not Sent from OpenVMS Server . . . . . . . . . . . . . . . . . . . . . AS_AVAILABILITY Application Not Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . When Using event_trigger2() Statements, Notifications Sent to Wrong Target Gathering Diagnostic Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Where to Find Diagnostic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Determining PATROL KM for Event Management Version Number. . . . . . . . . 209 Appendix A Accessing Menu Commands, InfoBoxes, and Online Help 211
Accessing KM Commands and InfoBoxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Accessing Online Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Index 215
10
Figures
Typical PATROL KM for Event Management Architecture . . . . . . . . . . . . . . . . . . . . . 17 Select Products and Components to Install - Typical Install . . . . . . . . . . . . . . . . . . . . 39 Quick Config - Notification Server Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Notification Server Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Primary Notification Server Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Selecting / to Represent all PATROL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Set Event Management Alert Variables/Rules Dialog Box . . . . . . . . . . . . . . . . . . . . . 81 Selecting Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Selecting Application Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Selecting Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Set Event Management Alert Variables/Rules Dialog Box . . . . . . . . . . . . . . . . . . . . . 83 What If Results Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Availability Monitor Add Target Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Choose Primary Monitor Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Rules to Apply to the Availability Checker Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Java Client Status Displayed in Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 SET EVENT MANAGEMENT VARIABLE:arsAction Dialog Box . . . . . . . . . . . . . . 101 SET EVENT MANAGEMENT ALERT VARIABLES/RULES Dialog Box . . . . . . . . 102 Configure Thresholds Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Choose the target classes Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Set Event Management Blackout Variables/Rules Dialog Box . . . . . . . . . . . . . . . . . 117 Set Event Management Blackout Variables/Rules Dialog Box . . . . . . . . . . . . . . . . . 119 Availability Monitor Add Target Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 QUICK CONFIG - NOTIFICATION SERVER Dialog Box . . . . . . . . . . . . . . . . . . . . . 131 NOTIFICATION SERVER SETTINGS Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 EVENT MANAGEMENT ALERT VARIABLE:emailTargetsRemoteALARM Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Message Rewording Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 SET EVENT MANAGEMENT VARIABLE: alertLocalCommand dialog box . . . . . 200
11
12
Tables
E-mail Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Sending Alerts to Enterprise Console Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Sending Pages using AlarmPoint Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Application Classes and KM File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 AS_EVENTSPRING InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 AS_AVAILABILITY InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 System Requirements for Installing and Using PATROL KM for Event Management 26 System Role Packages Available for Product Components . . . . . . . . . . . . . . . . . . . . . 38 EVENT_MANAGEMENT.kml File and Associated KM Files) . . . . . . . . . . . . . . . . . . 53 Notification Target Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Recommended Rule Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Recommended Configuration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Notification Script Location on Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Requirements for Using Scripts on Unix Notification Server . . . . . . . . . . . . . . . . . . . . 65 Notification Script Location on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Requirements for Notification Server When Using Windows e-mail Clients . . . . . . 66 Editing Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Notification Script Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Quick Config - Notification Server Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Notification Server Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 REMOTE AGENT COMMUNICATION SETTINGS dialog box . . . . . . . . . . . . . . . . . 79 Message Length Limitations by Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Availability Target Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Threshold Setting Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Wildcard Usage in Threshold Rules: Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Blackout Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 PATROL KM for Event Management Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Sending E-mail Notification for Low Disk Space: Configuration Overview . . . . . . 129 Sending E-mail Notification for Low Disk Space: Configuration Overview . . . . . . 145 Rules Created: Oracle Recovery Action Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 PATROL Objects Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Example: PATROL Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Example: Rule Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 PATROL KM for Event Management Variable Definition . . . . . . . . . . . . . . . . . . . . . 155 NOTIFY_EVENT Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Notification Server Message Replacement Variables . . . . . . . . . . . . . . . . . . . . . . . . . 160 Notification Server Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 arsAction Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 alertSystem Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
13
Notification System Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 allowOverrides Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 LoginDeniedIgnoredUsers Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 useEnvOnlyForCmds Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 useEnvOnlyForCmds Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 SpoolDirectory Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 SetParameterValue Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 alertResend Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 alertLocalCommand Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 arsCommand Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 arsCmdType Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 alertResetOnInit Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Remote Alert Settings: Configure Notification Servers Configuration Variable . . . 170 Remote Alert Settings: Configure Notification Servers Configuration Variable . . . 170 Remote Alert Settings: Remote Communication Settings Configuration Variable . 170 Notification Targets: Email Target Configuration Variable . . . . . . . . . . . . . . . . . . . . 172 Notification Targets: Pager Target Configuration Variable . . . . . . . . . . . . . . . . . . . . 172 Notification Targets: Custom Target Configuration Variable . . . . . . . . . . . . . . . . . . 173 Notification Targets: TT Targets Configuration Variable . . . . . . . . . . . . . . . . . . . . . . 173 Blackout Periods Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Overrides Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Notification Server Settings: Remote Target Setting Configuration Variable . . . . . 175 msgText Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 msgBody Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Custom Configuration Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 allowOperator Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 active Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 appClassSettingsStatusFlag Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 disableNotifyAnnotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 disableNotifyAnnotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Add Target Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Add Target: Updated Flag Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Primary Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Blackout Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 PingCmd Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 pingOKString Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 pingPacketSize Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 pingAttempts Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 pingArgs Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Checker Account Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Parameter Settings: Thresholds Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Understanding the THRESHOLDS Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Parameter Settings: poll times Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Parameter Settings: Status Flags Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Parameter Settings: poll times Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Filter List Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Filter Type Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 PATROL KM for Event Management Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 PATROL KM for Event Management Parameter Defaults . . . . . . . . . . . . . . . . . . . . . 194
14
Chapter
1
16 16 17 17 17 18 19 20 21 22 22 22 22 23 23 24
Product Components and Capabilities

1
This chapter provides an overview of the PATROL Knowledge Module for Event Management (also referred to as PATROL KM for Event Management). Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Typical Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rules Stored as Pconfig Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sending Notification: Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sending Alerts to an Enterprise Console: Process Flow . . . . . . . . . . . . . . . . . . . . . Sending Pages using AlarmPoint: Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the PATROL Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PATROL Configuration Manager Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tasks that Must be Completed Using PATROL KM for Event Management . . . Application Classes and Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 1
15
Features
Features
PATROL KM for Event Management provides event notification, message rewording, and centralized alert management features. With the PATROL KM for Event Management, you can:
s
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
Architecture
The 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:
s s s
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).
16
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
Primary
Notification Server 1
Backup
Notification Server 2
Agent 1
Agent 2
Agent 3
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 dont need to reconfigure the rules. The pconfig variable settings are retained.
Chapter 1 17
Notification Process
The following diagrams show how notification occurs in the following configuration:
s s s
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.
18
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 NA parameter exceeds threshold and enters WARN/ALARM state, generating PATROL standard event 11 or 39. 2. Recovery action initiated (if configured) arsAction arsCommand arsCmdType arsAction 3. The remote agent triggers a PATROL NOTIFY_EVENT (if arsAction = 4 or 6) 4. CustomID values are set (if configured) customId1 customId2 5. Notification message reworded (if configured) 6. PATROL determines if a blackout period applies. If so, NOTIFY_EVENT is not sent to the notification server. 7. The alert is queued. msgText msgBody blackoutPeriod
alertResetOnInit alertResend
8. Determine whether notification is local alertSystem or remote. If local, notification sent from remote agent. If remote, notification sent from notification server. 9. Determine the notification targets. emailTargets 10. Remote agent NotifiedEvent parameter NA is annotated with alert information. 11. A REMOTE_NOTIFY_EVENT is sent to NA notification server (if arsAction = 4 or 6) 12. The notification server parses REMOTE_NOTIFY_EVENT event details, which contains the same information as the original NOTIFY_EVENT. 13. Repeat steps 4 through 10 on the notification server (except step 7). NA
Multiple. See steps 4 through 10.
14. The notification server executes the emailTargets script to send e-mail message to targets. alertLocalCommand
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 NA (parameter exceeds defined threshold and enters WARN or ALARM state, generating PATROL event 11 or 39) 2. Notification processing occurs on the remote agent as previously discussed in Table 1 on page 19. arsAction arsCommand msgText msgBody The message rewording (msgText) blackoutPeriod must be done on the remote agent alertResetOnInit alertResend so that when the PATROL Event alertSystem Translator (PET) pulls the event, the event contains the host specific information.
3. The NOTIFY_EVENT is sent to the NA notification server. 4. The notification server process the REMOTE_NOTIFY_EVENT as previously discussed in Table 1 on page 19. 5. PATROL Event Translator (PET) pulls REMOTE_NOTIFY_EVENT from the notification server arsAction arsCommand blackoutPeriod alertSystem NA
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. 7. The event is received by the PATROL Enterprise Manager. NA
20
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 NA (parameter exceeds defined threshold and enters WARN or ALARM state, generating PATROL standard event 11 or 39) 2. Notification processing occurs on the remote agent as previously discussed in Table 1 on page 19. arsAction arsCommand msgText blackoutPeriod alertResetOnInit alertResend alertSystem customTargets
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. 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. arsAction arsCommand blackoutPeriod alertSystem customTargets
Chapter 1
21
Using the PATROL Configuration Manager
Using the PATROL Configuration Manager

The 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

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).
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.
s s s
Configuring Notification Servers on page 71 Configuring Remote Agents on page 73 Specifying an Availability Monitoring Account on page 92
22
Application Classes and Instances

The PATROL KM for Event Management contains two application classes:
s s
AS_EVENTSPRING AS_AVAILABILITY
Table 4 describes the PATROL KM for Event Management application classes, icons and KM files. Table 4 Application Classes and KM File
Description
Application Class KM File
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
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.
NOTE
The AS_AVAILABILITY application class icon is not displayed in the PATROL Console until availability targets are added.
Chapter 1
23
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 5 Item Spool Directory AS_EVENTSPRING InfoBox Items Description directory used to store output files generated by parameter reports and recovery actions executed by the PATROL KM for Event Management
KM Version the version of the PATROL KM for Event Management
Table 6 shows the InfoBox items for the AS_AVAILABILITY application instances. Table 6 Item Primary Monitor Ping Command Ping Host (ICMP)? Ping PATROLAgent? Blacked Out? KM Version AS_AVAILABILITY InfoBox Items Description agent with primary responsibility for performing availability monitoring command used to perform ping checks whether the host is being pinged using the ICMP protocol whether the PATROL Agent is being monitored for availability
Ping SNMP Agent? whether the SNMP agent is being monitoring for availability indicates whether the selected instance is currently being blacked out the version of the PATROL KM for Event Management
24
Chapter
Installing and Migrating PATROL KM for Event Management

2
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Machine Support Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backing up the Notification Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking for Product Patches or Fixes Before Installing. . . . . . . . . . . . . . . . . . . . . Determining How to Install Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining Where to Install the PATROL Agent. . . . . . . . . . . . . . . . . . . . . . . . . . Determining Where to Install KMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PATROL Security Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assessing and Implementing a Different Security Level . . . . . . . . . . . . . . . . . . . . Typical and Custom Installation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing into a PATROL 3.3.x or 3.4.x Unix Environment . . . . . . . . . . . . . . . . . . First-Time Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing For the First Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing on AS/400 (iSeries) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading from an Earlier Version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remove Customized KM Files From the PATROL_CACHE . . . . . . . . . . . . . . . . . Remove Existing Menu Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Considerations for Using Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Browser Version Required for Viewing PATROL Console for Unix Help . . . . . . Additional Considerations for Using Online Help for Unix. . . . . . . . . . . . . . . . . . Uninstalling PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining the Version of the Installation Utility . . . . . . . . . . . . . . . . . . . . . . . . . Uninstalling PATROL KM for Event Management on Windows . . . . . . . . . . . . .
Chapter 2
26 26 27 29 30 30 30 31 31 32 32 34 34 34 35 36 37 37 42 43 43 43 44 44 44 47 47 47
25
Installation Overview
This chapter contains instructions for installing PATROL KM for Event Management. For additional installation instructions, see the following documents: Information 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). You need more technical details about how to use the installation program. Document
s
s s s
PATROL for Microsoft Windows Servers Getting Started PATROL for Unix Getting Started PATROL for OpenVMS Installation Guide PATROL for AS/400 Getting Started
PATROL Installation Reference Manual
You need more information on distributing the Distribution Server Getting Started Guide PATROL KM for Event Management or other PATROL components using the Distribution Server.
System Requirements
Before installing the PATROL KM for Event Management, verify
s
the target computer meets the system requirements noted in Table 7 on page 26, including supported OS platforms and PATROL product versions.
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. the account that you use to install the product has sufficient privileges
Table 7 Resource operating systems PATROL products
System Requirements for Installing and Using PATROL KM for Event Management (Part 1 of 2) Requirements 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. 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. Comments
26
Table 7 Resource
System Requirements for Installing and Using PATROL KM for Event Management (Part 2 of 2) Requirements Comments
security levels For information on security, see PATROL Security Levels On iSeries, only security levels 0 and on page 34. 1 are supported. 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 enterprises PATROL installation. 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. 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. Browser Version Required for Viewing PATROL Console for Unix Help on page 44
ports
Use Netscape Navigator version 3.014.78 to use online (Unix only) Help with PATROL for Unix. browser to support online Help for PATROL for Unix Console 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.
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:
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.
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.
Console Connection Accounts

BMC Software recommends that you create a separate account, in addition to the PATROL default account, for PATROL console operators who dont 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:
28
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

BMC 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
s s s s s s s
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.
30
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 images 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:
s
Computers hosting the PATROL AgentSelect 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 UnixSelect 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:
s
Computers hosting the PATROL Console ServerSelect 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.
32
Computers hosting the PATROL AgentSelect 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:
s s
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 products respective online help systems and the following documents:
s s s s s
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 Levels

You 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.
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.
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:
esstool policy -a
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.
34
Typical and Custom Installation Types

The installation utility may prompt you to select one of the following installation types:
s
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.
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. 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 s the port numbers that components use to communicate with each other s a security level greater than basic security s 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 dont want to install.
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
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 ManagementPreload 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 ManagementPreload 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.
36
First-Time Installation
The 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.
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.
Before You Begin

s
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.
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:
s
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.
Table 8
System Role Packages Available for Product Components System Role to Select Console System
Product Component/Selectable Entity PATROL Knowledge Module for Event Management

a
PCO-Winb no
PATROL 3c yes
Managed System yes
Common Servicesa yes
PATROL Central Operator Web Edition. This console is available when you select the common services role. PATROL Central Operator Microsoft Windows Edition. This console is available when you select the console system role.
c b
PATROL Console for Windows and PATROL Console for Unix are PATROL 3 console systems. They are available when you select the console system role.
Fore more information, see Determining Where to Install the PATROL Agent on page 32.
38
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.
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. Figure 2 Select Products and Components to Install - Typical Install
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.
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.
Chapter 2
39
12 In the Review Selections and Install window, review the selections carefully to
ensure that they are correct:
s s
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:
s
If you are installing to a computer that hosts or will host a PATROL Console, select Console System.
40
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:
s s s
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:
s
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:
s
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.
42
Upgrading from an Earlier Version
Upgrading from an Earlier Version

The 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

If 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:
s
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:
44
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. Type of Shell Bourne Korn C Export Command for LANG Variable LANG=C export LANG export LANG=C setenv LANG=C
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.
Chapter 2
45
Type of Shell Bourne Korn C
Export Command for PATH Variable PATH=$PATH:/netscape_location export PATH export PATH=$PATH:/netscape_location setenv PATH=$PATH:/netscape_location
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: Type of Shell Bourne Export Command for PATROL_BROWSER Variable PATROL_BROWSER=netscape -display $DISPLAY -install -iconic export LANG export PATROL_BROWSER=netscape -display $DISPLAY -install -iconic setenv PATROL_BROWSER=netscape -display $DISPLAY -install -iconic
Korn C
To use different arguments, set the value of PATROL_BROWSER to the appropriate string.
Example
For a Korn shell, use the following command:
export PATROL_BROWSER=/usr/local/bin/netscape -raise
46
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.
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.
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.
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.
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.
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 Here

The following table lists other topics and where you can find them: Topic overview of the PATROL KM for Event Management features Source of Information Chapter 1, Product Components and Capabilities.
setting up and configuring PATROL KM for Chapter 3, Using the PATROL KM Event Management for Event Management. information on usage scenarios information about PATROL KM for Event Management configuration variables parameter descriptions troubleshooting information step-by-step procedures and detailed descriptions of the applications, menu commands, parameters, and InfoBoxes
Chapter 4, Usage Scenarios. Chapter 5, Rules and Configuration Variables. Chapter 6, Parameters. Chapter 7, Troubleshooting PATROL KM for Event Management, PATROL KM for Event Management component online Help
Chapter
3
51 51 51 52 52 52 55 55 58 58 60 60 61 63 63 64 70 71 73 76 79 82 84 85 87 87 89 91 92 93
49
Using the PATROL KM for Event Management

3
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 . . . . . . . . . . . . . . . . . . . . . Loading and Preloading KMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining Which KMs to Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . KM Files Preloaded on Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading and Unloading KMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying that PATROL KM for Event Management KM is Loaded. . . . . . . . . . . Unloading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Notification Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Availability Monitors and Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deciding Where to Place Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recommended Configuration Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Notification Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing Notification Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Remote Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rewording Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Notification Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing Notification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disabling Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Availability Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Backup Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the Availability Monitor Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying an Availability Monitoring Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the Ping Command Used for Availability Monitoring . . . . . . . . . . . . .
Chapter 3
Integrating with AlarmPoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 AlarmPoint Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Installing and Configuring AlarmPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Installing the AlarmPoint Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Configuring the AlarmPoint Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Testing the Java Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Using Action Scripts for AlarmPoint 5.2.01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Configuring Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Testing Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Managing Parameter Thresholds and Poll Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Benefits of Using the PATROL KM for Event Management . . . . . . . . . . . . . . . . . 104 Setting Collector Poll times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Using Wildcards to Represent PATROL Instance Names . . . . . . . . . . . . . . . . . . . 107 Activating and Deactivating Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Applying Thresholds and Poll Time Changes to the Agent . . . . . . . . . . . . . . . . . 111 Disabling the use of PATROL KM for Event Management Thresholds and Poll Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Specifying What to Monitor or Exclude from Monitoring . . . . . . . . . . . . . . . . . . . . . . 112 Selecting Application Instances to Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Excluding Application Instances from Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 114 Configuring Blackout Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 About Notification Blackout Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Configuring Notification Blackouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Configuring Availability Blackouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Configuring Recovery Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 About Recovery Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Enabling PATROL KM for Event Management Recovery Actions . . . . . . . . . . . 121 Specifying a Recovery Action Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Specifying a Recovery Action Command Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Using PSL Recovery Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
50
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:
s
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 KMs

When 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 products 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.
s s s
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 KMs data collection history, you do not see any gaps that would otherwise occur (because of the consoles absence).

Installing 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.
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) Components (KM files) Description The AS_AVAILABILITY application class icon is not displayed in the PATROL Console until availability targets are added. When loaded, this KM is displayed on the console as Event Management.
Product (.kml file)
EVENT_MANAGEMENT.kml AS_AVAILABILITY
AS_EVENTSPRING
AS_EVENTSPRING_ALL_COMPU This KM file never appears TERS on the console as a loaded KM; it is merged with the ALL_COMPUTERS.
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.
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.
NOTE
3 Select the .km or .kml files that you want to load. 4 Click Finish.
PATROL loads the selected KMs on the selected computers.
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.
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.
NOTE
2 Select one or more of the .kml files, and click Open.

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.
NOTE
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.
NOTE
The AS_AVAILABILITY application class icon is not displayed in the PATROL Console until availability targets are added.
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.
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.
56
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
Before you can use PATROL KM for Event Management, you must gather information and plan your configuration. You should gather the following information:
s s s s s
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.
58
To assure availability in critical environments, the backup notification server should be on a separate machine and network segment. 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.
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.
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. Table 10 / /CPU /NT_CPU Notification Target Configuration Information E--mail Target patrol@any.co.com unixadmin@any.co.com ntadmin@any.co.com Paging Target none unixadmin ntadmin
PATROL Object
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.
60
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, seeConfiguring the Availability Monitor Agent on page 91.
TIP
Availability checkers perform best on Unix machines and allow easier management of multiple agents running availability checkers on one machine.
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.
Chapter 3
61
Table 11 Rule Type
Recommended Rule Location (Part 1 of 2) Recommended Location notification server Advantage

s
Disadvantage More processing is performed at the notification server
Targets (notification recipients)
Easier to manage Less processing at managed nodes reduces PATROL resource consumption Reduces the number of rules at the notification server Since messages are reworded before arriving at the notification server, you dont need a second level of notification servers to properly send messages to an enterprise console. Reduces network traffic Reduces processing at the notification server
Alert Messages (wording and content of notification messages)
remote agent
More difficult to manage the rules on multiple remote agents
Blackouts
remote agent
More difficult to manage the rules on multiple remote agents
Alert Action (what to do when an alert occurs) Parameter Settings (thresholds and poll times) Alert Resend (whether to resend outstanding alerts)
remote agent only remote agent only remote agent only
The alert action must be defined on the remote agent where PATROL alerts are generated. The parameter settings must be defined on the remote agent where PATROL alerts are generated. The alert resend settings must be defined on the remote agent where the PATROL alerts are generated. 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.
Notification Command notification (the script used to send server only notifications)
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.
62
Configuring Notification
Table 11 Rule Type
Recommended Rule Location (Part 2 of 2) Recommended Location remote agent only remote agent only Advantage Disadvantage
Custom Identifiers Recovery Actions
Custom identifiers must be defined on the remote agent where message rewording is taking place. Recovery actions settings must be defined on the remote agent where PATROL events are generated and where you expect the recovery action to occur.
This 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. Table 12 1 2 3 4 Recommended Configuration Process (Part 1 of 2) Topic(s) Using Notification Scripts Testing Notification Scripts Configuring Notification Servers Rewording Notification Messages Page 64 70 71 79
Step Configuration Task Identify, edit, and test the notification script. Configure a notification server. Reword default notification message for the notification server.
Use PATROL Configuration Manager For an example of how to use the PATROL 134 to copy the notification server settings Configuration Manager, see To Assign (rules) to the other notification servers. Notification Servers for NT2 and NT3. For more detailed instructions on using the PATROL Configuration Manager, see the PATROL Configuration Manager User Guide. Configure remote agents to use a notification server. Configuring Remote Agents 73
Chapter 3
63
Table 12 6
Recommended Configuration Process (Part 2 of 2) Topic(s) Page For an example of how to use the PATROL 134 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. Setting Notification Targets Managing Parameter Thresholds and Poll Times Configuring Alert Settings 82 104 76
Step Configuration Task 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. 7 Configure notification rules and parameter settings for the agents.
Use PATROL Configuration Manager For an example of how to use the PATROL 134 to copy agent notification rules and Configuration Manager, see To Assign parameter settings to other like agents. Notification Servers for NT2 and NT3 on page 134. For more detailed instructions on For example, you may want to set up a using the PATROL Configuration Manager, notification rule for a parameter related see the PATROL Configuration Manager User Guide. to Oracle. You would then copy that rule to all other agents that are monitoring Oracle. Configure availability monitoring. Configuring Availability Monitoring 87
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:
s s
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)
NOTE
The PATROL KM for Event Management Perl script has been tested with Perl 5.
64
Default Location on Unix

The scripts that run on Unix, shown in Table 13, are located in
$PATROL_HOME$/lib/psl
Table 13 Script
Notification Script Location on Unix Name AS_EVSLocalAlertNotify.sh AS_EVSLocalAlertNotify.pl
Unix Script Perl Script
Unix Requirements
To use the Unix scripts, the server sending the notification must meet the requirements shown in Table 14. Table 14 Script Unix Requirements for Using Scripts on Unix Notification Server Requirements 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.
Windows Scripts
On Windows, the following script options are available:
s
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

Chapter 3 65
NOTE
The PATROL KM for Event Management has been tested with Blat version 1.7.
Default Location on Windows

The Windows scripts are located in the %PATROL_HOME%\lib\psl\ directory and are named as shown in Table 15. Table 15 Script Batch File Script SMTP VB Script Notification Script Location on Windows Name AS_EVSLocalAlertNotify.bat 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
Windows Requirements
To use these Windows scripts, the server sending the notification must meet the requirements shown in Table 16. Table 16 Script Batch File Script Requirements for Notification Server When Using Windows e-mail Clients Requirement 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. 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
Perl Script
66
Table 16 Script
Requirements for Notification Server When Using Windows e-mail Clients Requirement The SMTP service must be running. This VB script is not supported on Windows NT Workstation.
SMTP VB Script
MAPI VB Script
Microsoft Outlook must be installed. This VB script is not supported on Windows NT Workstation.
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.
Chapter 3
67
Table 17 Unix
Editing Scripts 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.
Script Platform Editing Required
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) 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. 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.
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.
:EMAIL rem -rem -- BLAT based eMail rem -rem set email_file=c:\blat\mtext%AS_PARAMETER_NAME%_%AS_SSTIME%.txt rem 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.txt rem if exist c:\blat\blat.exe c:\blat\blat %email_file% -t %ntargets% -s %nmsg% rem goto BYE
68
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 (# ):
#system("c:\\blat\\blat.exe $email_file -t \"$ntargets\" -s \"$nmsg\"");
Editing the SMTP VB Script

To use the SMTP VB Script (sendmail.vbs), you must edit the script to add the following information:
s s
name of the e-mail server the SMTP server port
Add this information in the script as shown below.

' 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 number iConf.Fields("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25
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:
s s s
pages trouble tickets custom notifications
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.
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.
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: AS_EVSLocalAlertNotify.ext type targets message
NOTE
Replace ext with the file extension of your notification script (bat, sh, or pl).
The notification script arguments are described in Table 18. Table 18 type Notification Script Arguments The notification type that you are testing. The following notification types are supported:
s s s s
Argument Description
emailsends an e-mail notification pagesends a page notification ttsends a trouble ticket notification customsends 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. the notification or test message that is sent to the targets
message
70
The following example shows a test of the AS_EVSLocalAlertNotify.bat script on Windows:

AS_EVSLocalAlertNotify.bat email "patrol@bmc.com" "This is a test."
Configuring Notification Servers

This section describes the purpose of a notification server and describes how to configure a server as a notification server.
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.
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
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: Table 19 Property Quick Config - Notification Server Properties 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 dont 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 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.
72
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.
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.
Before You Begin

You should configure and test the notification servers before configuring the remote PATROL Agents served by the notification servers.
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:
s s s s
AS/EVENTSPRING/NOTIFICATION_SERVER1.defaultAccount (primary) AS/EVENTSPRING/NOTIFICATION_SERVER2.defaultAccount (backup) AS/EVENTSPRING/NOTIFICATION_SERVER1 (primary) AS/EVENTSPRING/NOTIFICATION_SERVER2 (backup)
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.
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
74
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: Table 20 Property Notification Server Hostname Notification Server Properties Description 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 Notification Server User Name Notification Server Password Verify Password Make Connection Persistent the port number of the notification server that the selected managed system will use the user name that the selected managed system will use to connect to the notification server the password that the selected managed system will use to connect to the notification server verify the password that the selected managed system will use to connect to the notification server 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
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. 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. Topic Specifying Where to Initiate Notifications Preventing False Alerts Changing the Number of Times Alerts are Resent Defining Agent-to-Notification Server Protocol Settings Page 76 77 78 79
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.
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.
76
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.
5 To save your changes, click Accept.
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 1 From the PATROL console, access the host KM menu commands as described in
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 1 From the PATROL console, access the host KM menu commands as described in
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.
78
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:
s s
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 1 From the PATROL console, access the host KM menu commands as described in
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. Table 21 Setting REMOTE AGENT COMMUNICATION SETTINGS dialog box 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

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.
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 Platform Unix Windows Message Length Limitations by Platform Message Length Limitations Subject line is limited to 100 characters. No known limit on the message body. 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) OpenVMS When using the native SNDDST mail utility, the subject line is limited to 44 characters and the message body is limited to 5000 characters. Subject line is limited to 80 characters. The message body is limited to 255 characters. If limits are exceeded, message is not sent.
80
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
s
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 dont 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
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.
82
Figure 9
Selecting Application Instances
4 Select the application instance of the parameter, and click Accept.

The Set Event Management KM Variables/Rules dialog box opens as shown in Figure 10. Figure 10 Selecting Parameters
5 Select the parameter and click Accept.

The Set Event Management KM Variables/Rules dialog box opens as shown in Figure 11. 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

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.
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.
84
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 dont want to receive. You can accomplish this by adjusting the thresholds, deactivating threshold ranges, or deactivating parameters. 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.
Overriding Rules
You can also limit notification by overriding a rule. For example, if you dont 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.
86
Configuring Availability Monitoring

This 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 Property Hostname Availability Target Properties (Part 1 of 2) Description 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
88
Table 23 Property
Availability Target Properties (Part 2 of 2) Description the SNMP connection timeout for the managed system you are monitoring the number of times the PATROL Agent tries to connect to the managed system that you are monitoring before it fails 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.
SNMP Timeout SNMP Retries SNMP Object ID
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. 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.
Configuring a Backup Availability Monitor

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.
Configuring Availability Failover

This procedure describes how to specify which availability monitor is the backup availability monitor.
Chapter 3
89
Before You Begin

Before you configure availability monitoring failover, ensure that
s
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:
s
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
90
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:
s s
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. Rules to Apply to the Availability Checker Agent
Figure 15
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 dont 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.
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.
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.
92
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

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.
Example
To use the following ping command, use the configuration variables described below: ping host -n 2 -|32
Chapter 3
93
Integrating with AlarmPoint
Configuration Variable Value pingCmd ping
Comments 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
Example
ping abc.bmc.com -n 2 -l 32
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: ping -c 2 -s 99 host Configuration Variable Value pingCmd pingArgs ping
Comments None
-c 3 -s 99 host This command syntax is defined below:

s s s
-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

You 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.
94
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: Step Configuration Task 1 2 3 4 5 6 7 8 Install AlarmPoint on a Windows server. Topic(s) Installing and Configuring AlarmPoint Page 96 96 96 96 97 98 99 103
Configure AlarmPoint and define users Installing and Configuring AlarmPoint (notification targets). Install AlarmPoint java client. Configure AlarmPoint java client Test the AlarmPoint Java client. Download AlarmPoint scripts (only if using AlarmPoint 5.2.01). Configure notification. Test notification. Installing the AlarmPoint Java Client Configuring the AlarmPoint Java Client Testing the Java Client Using Action Scripts for AlarmPoint 5.2.01 Configuring Notification Testing Notification
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.
<?xml version="1.0" encoding="UTF-8" ?> - <alarmpoint-agent version="1.0"> -  <server type="primary" address="172.23.0.26" />
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.
96
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:
s s
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 dont 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/p kmforem_alarmpointv521.tar
Windows
ftp://ftp.bmc.com/pub/patrol/patches/PKM_Event_Management/2.5.00/NT/pk mforem_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.
98
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:
s
AS_EVSLocalAlertNotifyAP.bat PATROL KM for Event Management notification
script for Windows

s
AS_EVSLocalAlertNotifyAP.sh PATROL KM for Event Management notification
script for Unix
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.
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:
s
/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.
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. 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.
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
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.
100
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:
s
Trigger NOTIFY_EVENT (Perform Notification) this option enables notification
for the selected parameter.

s
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: /AS/EVENTSPRING/NT_CPU/CPU_0/CPUprcrProcessorTimePercent/arsAction
To Set the alertLocalCommand Notification Rule 1 From the PATROL console, access the managed system you are using as the
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.
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: /AS/EVENTSPRING/ALERT/NT_CPU/CPU_0/CPUprcrProcessorTimePercent/a lertLocalCommand
To Set the customTargetsLocalALARM Notification Rule 1 From the PATROL console, access the managed system you are using as the
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/c ustomTargetsLocalALARM
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:

"/AS/EVENTSPRING/setParameterValue" = { REPLACE = "/NT_CPU/CPU_0/CPUprcrProcessorTimePercent=ALARM" }
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: %PSL set("/NT_CPU/CPU_0/CPUprcrProcessorTimePercent/value",99);
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.
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

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.
To Set Parameter Thresholds Using the PATROL KM for Event Management 1 From the PATROL console, access the host KM menu commands as described in
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.
104
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 Property Active Border Range Threshold Setting Properties (Part 1 of 2) Description indicates that the parameter is active and the settings in the dialog box represent the current parameter settings 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
Table 24 Property
Threshold Setting Properties (Part 2 of 2) Description
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:
s s s
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:
s s s
must be greater than Alarm1 values cannot overlap the Alarm1 range cannot fall outside the range limits or border range 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.
Enable Alert State
makes the range active

s
Min Max
minimum value of acceptable range maximum value of acceptable range
Trigger Alarm determines when an alarm is triggered and can be one of the following values:
s
After an alarm has occurred n times Use this value to discount random
s s
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.
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 makes the selected parameter thresholds apply to the current session current session Make persistent makes the selected parameter thresholds persist after the console is disconnected
If a Problem Occurs
If a problems occurs, see Parameters Setting Lost After Agent Restart on page 206.
Setting Collector Poll times

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

s
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 1 From the PATROL console, access the host KM menu commands as described in

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 CPU_{re:*} Matches CPU_03 CPU_13 HoustonCPU_03 No Match CP_1 CPU14
Chapter 3
107
Requirements for Using Wildcards

The following usage rules apply to wildcards:
s
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 Result
Processes Running on the Host Rules

s s s
msdtc svchost msv
Since rule # 2 did not /AS/EVENTSPRING/PARAM_SETTINGS/THRESH match any of the OLDS/NT_PROCESS/__ANYINST__/PROCSTATUS processes running on the host, rule # 1 is applied to all of the Rule# 2: /AS/EVENTSPRING/PARAM_SETTINGS/THRESH instances on the host. OLDS/NT_PROCESS/pat{re:*}/PROCSTATUS
Rule # 1:
s s s
msdtc svchost msv
Since rule # 1 is an /AS/EVENTSPRING/PARAM_SETTINGS/THRESH exact match for a process that is running OLDS/NT_PROCESS/msdtc/PROCSTATUS on the host, it takes precedence over rule Rule # 2: /AS/EVENTSPRING/PARAM_SETTINGS/THRESH # 2. OLDS/NT_PROCESS/ms{re:*}/PROCSTATUS
Rule# 1:
108
Activating and Deactivating Parameters

Using the PATROL KM for Event Management, you can perform the following parameter configurations:
s s
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 1 From the PATROL console, access the host KM menu commands as described in

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 1 From the PATROL console, access the host KM menu commands as described in

Chapter 3
109
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. 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.
The following agent configuration variable is created: AS/EVENTSPRING/PARAM_SETTINGS/THRESHOLDS/application class/__ANYINST__/parameter where application class and parameter represent the application class and parameter that you chose to deactivate. 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.
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 1 From the PATROL console, access the host KM menu commands as described in

110
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, select the Active checkbox. 5 To save the threshold properties, click Accept. 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. AS/EVENTSPRING/PARAM_SETTING/THRESHOLDS/application class/{re:*}/parameter name
3 Assign the rule the desired value. For more information on the syntax of the
THRESHOLDS rule, see THRESHOLDS on page 186. 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.
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_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.
1 From the PATROL console, access the host KM menu commands as described in
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 dont want to monitor to an exclude filter. Instance monitoring settings are stored in the following agent configuration variables:
s s
AgentSetup/ApplicationClass.FilterList Configuration Variable AgentSetup/ApplicationClass.FilterType Configuration Variable
To Add Instances You Want to Monitor to an Exclude List (Temporarily) 1 From the PATROL console, access the host KM menu commands as described in
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 1 From the PATROL console, access the host KM menu commands as described in
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.
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.
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:
s s s
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 dont want to monitor a particular application instance, you need to add it to the exclude filter.
To Exclude Instances from Monitoring 1 From the PATROL console, access the host KM menu commands as described in
2 Choose the KM menu command Event Management => Instance Filtering => Edit
Filter List.
114
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:
s s s
which application classes have filters defined the type of filter (include or exclude) the application instances in the filter
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 dont want to monitor to an exclude list. For more information, see Selecting Application Instances to Monitor on page 112.

You 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.
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 1 From the PATROL console, access the host KM menu commands as described in
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.
116
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. Table 26 Property Blackout Start Time Blackout End Time Blackout Days Merge Selected Blackout Periods with Pre-Existing Settings Blackout Properties Description the blackout start time the blackout end time the days that you would like the blackout to occur merges the current blackout out period with existing blackout periods for this object
Replace Existing Blackout Periods with replaces all existing blackout periods with Current Selection the defined blackout period
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:59 Blackout Days-->Fri 2. Blackout Start Time -->00:00:00 Blackout Stop Time --> 23:59:59 Blackout Days-->Sat 3. Blackout Start Time -->00:00:00 Blackout Stop Time --> 09:00:00 Blackout 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.
118
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 1 From the PATROL console, access the host KM menu commands as described in
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.
NOTE
The availability blackout options do not include the option to merge the blackout periods.
4 Define the blackout period properties, and click Accept.

This 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.
120
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 dont 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 1 From the PATROL console, access the host KM menu commands as described in
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:
s
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.
122
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 1 From the PATROL console, access the host KM menu commands as described in
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 1 From the PATROL console, access the host KM menu commands as described in
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 Variable __appl_class__ __param__ PATROL KM for Event Management Variables Description application class name 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.
124
Table 27 Variable
PATROL KM for Event Management Variables Description 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. 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.
__output__
__udefvar__
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: hostn = get("/hostname"); For more information about using PSL, see the PATROL PSL documentation.
Chapter 3
125
126
Chapter
4
128 128 129 130 130 130 132 135 136 138 140 140 141 141 141 142 143 143 144 144 145 145 146 146 147 148 149 149
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 . . . . . . . . . . . . . . . . . . . . . . . . Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting a Mail Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading the PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . . . . Defining the Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the Remote Agent NT1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying an E-mail Target for Low Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . Rewording the Notification Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sending E-mail Notification for CPU Usage that Includes Parameter Annotations Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of Annotated Data Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling Recovery Actions and Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Recovery Action Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Notification Command Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Recovery Action that Runs Under a Specified Account . . . . . . . . . . . Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing Recovery Action Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling Recovery Actions for ArchFreeSpace on Agent Computer . . . . . . . . . Defining the Recovery Action Type for Agent Computer . . . . . . . . . . . . . . . . . . Storing the Encrypted Password as a Pconfig Variable. . . . . . . . . . . . . . . . . . . . . Configuring the PSL Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary of Rules Created . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing the Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
Primary Notification Server NS1 Backup Notification Server NS2
NT1
NT2
NT3
Assumptions
For this scenario, assume the following:
s
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.
128
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 Step Task 1 2 3 4 5 6 7 8 9 10 Selecting a Mail Client Loading the PATROL KM for Event Management Sending E-mail Notification for Low Disk Space: Configuration Overview PATROL Product NA PATROL console Alternative PATROL Product NA None
Defining the Notification Servers PATROL console - (PATROL KM None for Event Management) Configuring the Remote Agent NT1 Copying notification server settings to NT2 and NT3 Specifying an E-mail Target for Low Disk Space PATROL console - (PATROL KM None for Event Management) PATROL Configuration Manager None
PATROL console - (PATROL KM PATROL for Event Management) Configuration Manager None
Copying e-mail targets from NS1 PATROL Configuration to NS2 Manager Rewording the Notification Messagee Copying reworded notification message rule from NS1 to NS2 Testing Notification
PATROL console - (PATROL KM PATROL for Event Management) Configuration Manager PATROL Configuration Manager PATROL console or PATROL Configuration Manager None 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.

Config => Notification Server.
130
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 admin@abc.com 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 dont 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

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.
132
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.
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.
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.
Chapter 4
133
To Assign Notification Servers for NT2 and NT3

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.
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
134
Specifying an E-mail Target for Low Disk Space

Currently, all e-mail notifications are sent to the admin@abc.com 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 networkadmin@abc.com. 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.
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.
Targets => Email => Remote Targets ALARM => Set For Parameters.
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.
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.
Chapter 4
135
Figure 27
EVENT MANAGEMENT ALERT VARIABLE:emailTargetsRemoteALARM Dialog Box
6 Enter the e-mail target networkadmin@abc.com and then click Accept.

When you perform this step, the following rule is created: /NT_LOGICAL_DISKS/__ANYINST__/LDldFreeSpacePercent/emailTargetsRe moteALARM The value of this rule is networkadmin@abc.com. 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.
136
To Reword the Default Notification Message

1 From the PATROL console, access the NS1 KM menu commands as described in
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.
EXAMPLE
%PARAMETER_STATUS%on%HOSTNAME%forparameter %PARAMETER_NAME%=%PARAMETER_VALUE% 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: ALARM on NT1 for parameter LDldFreeSpacePercent = 3.50
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.
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:
"/AS/EVENTSPRING/setParameterValue" = { REPLACE = "/NT_LOGICAL_DISKS/__ANYINST__/LDldFreeSpacePercent=ALARM" }
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 networkadmin@abc.com. 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.
138
3 Enter the PSL command shown below and click Apply.

set("/NT_LOGICAL_DISKS/C:/LDldFreeSpacePercent/value",1);
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 networkadmin@abc.com.
If a Problem Occurs
If the e-mail notification is not sent correctly, see Configuration Problems on page 198 for troubleshooting help.
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:
s
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.
140
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. 5 To save your changes, click Accept.
Chapter 4
141
Creating Recovery Action Rules

After you enable recovery actions and notification, you need to create the following recovery action rules.
s s
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.
2 Select the application class CPU, instance CPU, and parameter CPUCpuUtil. 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.
2 Select the application class CPU, instance CPU, and parameter CPUCpuUtil.
142

enter the following recovery action script:
__udefvar__=annotate_get(\/\.__appl_class__.\/\.__instance__.\/\.__param__);

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.
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
s
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.
144
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. Table 29 Step Task 1 2 Testing Recovery Action Script Enabling Recovery Actions for ArchFreeSpace on Agent Computer Defining the Recovery Action Type for Agent Computer Sending E-mail Notification for Low Disk Space: Configuration Overview PATROL Product OS (outside of PATROL) Alternative PATROL Product NA
PATROL console - (PATROL KM PATROL Configuration for Event Management) Manager PATROL console - (PATROL KM PATROL Configuration for Event Management) Manager None
3 4 5 6
Storing the Encrypted Password PATROL Developer Console as a Pconfig Variable Configuring the PSL Recovery Action Testing the Recovery Action
PATROL console - (PATROL KM PATROL Configuration for Event Management) Manager PATROL console None
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.
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. 5 To save your changes, click Accept.
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

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.

ArchFreeSpace.
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/arsCmdTy pe = 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.
encrypted_passwd = encrypt("oracle_password", "DES"); pconfig("REPLACE", "/MYCOMPANY/ORACLE/OSlogin", "oracle ".encrypted_passwd);
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.
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

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.

ArchFreeSpace.

enter the following PSL code:
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.
This PSL recovery action is stored in the following configuration variable:

/AS/EVENTSPRING/ORACLE_AVAILABILITY/test/ArchFreeSpace/arsCommand
148
Summary of Rules Created

At this point, the following rules have been created. Table 30 Rule
/AS/EVENTSPRING/ORACLE_AVAILABILITY/Test/ArchFreeSpace/arsAction = 6
Rules Created: Oracle Recovery Action Example
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__.
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.
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.
set("/ORACLE_AVAILABILITY/test/ArchFreeSpace/value",1);
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.
150
Chapter
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example: PATROL Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example: Rule Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example: PATROL KM for Event Management E-mail Rule . . . . . . . . . . . . . . . . NOTIFY_EVENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How the NOTIFY_EVENT and REMOTE_NOTIFY_EVENT are Triggered . . . Event Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Order of Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empty Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Variable userdefined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event Size Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NOTIFY_EVENT Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alert Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . arsAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . alertSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . allowOverrides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . loginDeniedIgnoredUsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . useEnvOnlyForCmds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . allowInfoRecoveryActions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . spoolDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . setParameterValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Local Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . alertResend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . alertLocalCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . arsCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . arsCmdType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . alertResetOnInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 153 154 154 156 156 156 156 156 157 157 157 161 161 162 163 164 164 165 165 166 166 167 167 168 168 169
Chapter 5
151
Remote Alert Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 NOTIFICATION_SERVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 RemoteAgentCommSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Notification Target Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 emailTargets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 pagerTargets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 customTargets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 ttTargets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Blackout Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 blackoutPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 __OVERRIDE__ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Notification Server Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 nsRemoteTargetSetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Custom Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 msgText . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 msgBody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 CustomId1 and CustomId2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 allowOperator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 appClassSettingsStatusFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 disableNotifyAnnotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 maxEventsToReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 snmpSettings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 snmpOid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Primary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Blackout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 pingCmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 pingOkString . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 pingPacketSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 pingAttempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 pingArgs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 checkerAccount.defaultAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Parameter Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 THRESHOLDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 paramSettingsStatusFlag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 processWildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Instance Filtering Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 FilterList Configuration Variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 FilterType Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
152
PATROL Objects
PATROL Objects
Before 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. Table 31 PATROL Objects Hierarchy Object host Description host computer of the objects that are being monitored type of objects that can be monitored actual instance of an application class Windows Example ntprod1 Unix Example sunprod1
Hierarchy (1=Highest) 1
2 3 4
application class application instance parameter
NT_LOGICAL_DISKS C:
FILESYSTEM root FSCapacity
specific parameter of an LDldFreeMegabytes application instance
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 32 Object host Example: PATROL Object Example Variable the Windows Server / hosts
application the logical disks /NT_LOGICAL_DISKS class application class of the Windows Server application the logical disk, C: instance parameter /NT_LOGICAL_DISKS/C:
the parameter /NT_LOGICAL_DISKS/C:/LDldFreeMegabytes LDldFreeMegabytes associated with the logical disk C:
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. E-mail User2 for any parameter in any instance of the logical disks application class (/NT_LOGICAL_DISKS) in alarm on this host. E-mail User3 for any parameter in alarm on this host for the logical disks application class instance C: (/NT_LOGICAL_DISKS/C:). 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: Rule Inheritance Action User4 receives an e-mail. Rule 4 is specific to the parameter and instance that are in alarm 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. User2 receives an e-mail. No rule is defined at the instance level for D:, so Rule 2, the application class rule, applies.
Rule 2:
Rule 3:
Rule 4:
Table 33
Object in Alarm /NT_LOGICAL_DISKS/C:/LDldFreeMegabytes /NT_LOGICAL_DISKS/C:/LDldIdleTimePercent
/NT_LOGICAL_DISKS/D:/LDldFreeMegabytes
/NT_CPU/CPU_0/CPUprcrProcessorTimePercent User1 receives an e-mail since none of the lower-level rules apply to this alarm.
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.
154
PATROL Objects
The general variable naming format is the following: category/object/rule Table 34 Variable category object PATROL KM for Event Management Variable Definition Definition a grouping of related rules that perform notification 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
The following example shows how to send an e-mail when an alarm condition occurs for a PATROL object: /AS/EVENTSPRING/ALERT/EMAIL/NT_LOGICAL_DISKS/C:/emailTargetsLocalALARM category: /AS/EVENTSPRING/ALERT/EMAIL is the category including rules that perform notification. /NT_LOGICAL_DISKS/C: is the PATROL object, an application instance, to which the rule is applied. 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, /AS/EVENTSPRING/ALERT/EMAIL/NT_SERVICES/__ANYINST__/ServiceStatus/emailTargetsLocal 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 /AS/EVENTSPRING/ALERT/EMAIL/winprod/NT_LOGICAL_DISKS/C:/emailTargetsLocalALARM the rule only applies for alarm conditions occurring on the Windows Server winprod.
object:
rule:
Chapter 5
155
NOTIFY_EVENT
NOTIFY_EVENT
This 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 its 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.
156
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:
s s s
the length is limited to 25k new-lines are replaced with -CRtabs 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:
s
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 Field Hostname
NOTIFY_EVENT Fields (Part 1 of 4) Message Replacement Variable Environment Variable %HOSTNAME% %IPADDRESS% %TCP_PORT% %UDP_PORT% AS_HOSTNAME AS_IPADDRESS AS_TCP_PORT AS_UDP_PORT Description Hostname of affected system (e.g., glamis) IP Address for hostname (e.g., 192.168.1.1) Affected agent TCP listening port (e.g., 3181) Affected agent UDP listening port (e.g., 3181)
IP Address TCP Port UDP Port
Chapter 5
157
NOTIFY_EVENT
Table 35 Field
NOTIFY_EVENT Fields (Part 2 of 4) Message Replacement Variable Environment Variable %APPCLASS% AS_APPCLASS Description Application Class name (e.g., ORACLE, FILESYSTEM, NT_SERVICES) Internal instance name (e.g., oracle_db1) Name of the instance as it appears on the PATROL console (e.g., oracle_db1) Instance name that is the parent container of instance (e.g., /CPU/CPU) Parameter name (e.g., CPUCpuUtil)
Application Class
Instance Name (sid) %APPINSTANCE% Icon Name %ICON_NAME%
AS_APPINSTANCE AS_ICON_NAME
Parent Instance
%PARENT_INSTAN AS_PARENT_INSTAN CE% CE %PARAMETER_NA ME% AS_PARAMETER
Parameter Name Parameter Status Parameter Value Alert Date
%PARAMETER_STA AS_PARAMETER_STA Parameter status at time of TUS% TUS alert (e.g., ALARM) %PARAMETER_VAL AS_PARAMETER_VAL Parameter value at the time UE% UE of alert (e.g., 99) %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 the affected system is set to (e.g. US/Eastern/EDT (Unix) or Eastern Daylight Time (NT)) 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 the last 10 parameter values. (e.g., 97.21)
Time Zone
%TIMEZONE%
AS_TIMEZONE
Last10 Parameter Values
%LAST10%
AS_LAST10
Average of Last 10
%AVE10%
AS_AVE10
158
NOTIFY_EVENT
Table 35 Field
NOTIFY_EVENT Fields (Part 3 of 4) Message Replacement Variable Environment Variable %LAST10TS% AS_LAST10TS Description Times the last 10 parameter values were collected. These map directly with the Last10 values. (Time in seconds since epoch.) Length of time, in minutes, from the first parameter value and the last 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 variable. This contains the information stored in the variable /_my_APPCLASS_APPINS TANCE_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.
Last10 Timestamps
Last10 Total Period
%LAST10TP%
AS_LAST10TP
Event Id
%EVENT_ID%
AS_EVENT_ID
User defined
%USERDEFINED%
AS_USERDEFINED
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) Lower threshold of current alarm range (V2.4.02 and later)
Alarm Min
%ALARM_MIN%
AS_ALARM_MIN
Alarm Max
%ALARM_MAX%
AS_ALARM_MAX
Upper threshold of current alarm range (V2.4.02 and later)
Chapter 5
159
NOTIFY_EVENT
Table 35 Field
NOTIFY_EVENT Fields (Part 4 of 4) Message Replacement Variable Environment Variable %CUSTOM_ID1% AS_CUSTOM_ID1 Description Custom identifier assigned to object (V2.4.02 and later)
Custom Id1
Custom Id2
%CUSTOM_ID2%
AS_CUSTOM_ID2
Custom identifier assigned to object (V2.4.02 and later)
PATROL Agent version PATROL Home Event catalog Event class Event status Event severity Event type
%AGENT_VERSION AS_AGENT_VERSION % %PATROL_HOME% AS_PATROL_HOME %EVENT_CATALO G% %EVENT_CLASS%
The version of the PATROL Agent running on the host. The PATROL installation directory.
AS_EVENT_CATALOG The PATROL event catalog file. AS_EVENT_CLASS The event class of the event. For example, 9 or 11. The status of the event. For example, Open.
%EVENT_STATUS% AS_EVENT_STATUS
%EVENT_SEVERITY AS_EVENT_SEVERITY The event severity. For % example, 4. %EVENT_TYPE% AS_EVENT_TYPE The type of event. For example, ALARM.
The following variables are not available from event details; they are provided as message placement and environment variables only at a notification server. Table 36 Notification Server Message Replacement Variables Environment Variable AS_NOTIFY_EVENT_ID AS_EVENT_TYPE AS_EVENT_STATUS Description Event Manager event id for the NOTIFY_EVENT (e.g., 5439) Event Manager event type of the NOTIFY_EVENT (e.g., ALARM) Event Manager event status of the NOTIFY_EVENT (e.g., OPEN)
Message Replacement Variable %NOTIFY_EVENT_ID% %EVENT_TYPE% %EVENT_STATUS%
160
Alert Rules
The following variables are available only as environment variables that can be used by a notification script. Table 37 Notification Server Environment Variables Description notification type reworded message Example e-mail, page dave@anyco.com High CPU on glamis at 99.54%
Environment Variable AS_NOTIFICATION_TYPE AS_NOTIFICATION_MSG AS_NOTIFICATION_FILE
AS_NOTIFICATION_TARGETS notification targets
filename on hostname that /usr/patrol/CPU_CPU_CPUC contains recovery action output puUtil_20020404111134.out
Alert Rules
Each 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 38 Rule Configuration Variables arsAction Rule arsAction
s s s s
/AS/EVENTSPRING/object/arsAction /AS/EVENTSPRING/object/arsActionINFORMATION /AS/EVENTSPRING/object/arsActionWARNING /AS/EVENTSPRING/object/arsActionALARM
Values
3 bit mask 0 - Do nothing 2 - Allow recovery actions 4 - 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 Rule Configuration Variable alertSystem Rule alertSystem
s s s s
/AS/EVENTSPRING/ALERT/object/alertSystem /AS/EVENTSPRING/ALERT/object/alertSystemINFORMATION /AS/EVENTSPRING/ALERT/object/alertSystemWARNING /AS/EVENTSPRING/ALERT/object/alertSystemALARM
Values
Remote Local Local, Remote None For a detailed description of these options, see Table 40 on page 163.
Support Menu Command Access
supported by PATROL KM for Event Management version 2.4.05 or later Event Management => Alert Settings => Notification System
162
Alert Rules
Table 40 Location LOCAL
Notification System Options Description 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
s s s
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. 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. PATROL KM for Event Management does not perform notification.
LOCAL, REMOTE NONE
allowOverrides
You can use the allowOverrides rule to disable the use of rule overrides (__OVERRIDE__). Table 41 Rule Configuration Variable Values Example Support allowOverrides Rule allowOverrides /AS/EVENTSPRING/allowOverrides 0 = do not allow rule overrides 1 = allow rule overrides (default) 1 supported by PATROL KM for Event Management version 2.4.05 or later
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.
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 dont 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 Rule Configuration Variable Values Examples Support Menu Command Access LoginDeniedIgnoredUsers Rule loginDeniedIgnoredUsers /AS/EVENTSPRING/loginDeniedIgnoredUsers comma delimited string patrol_checker,EventSpring,EventSpring_Availability_Check supported by PATROL KM for Event Management version 2.4.02 or later Not available
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. Table 43 Rule Configuration Variable Values Example Support Menu Command Access
164
useEnvOnlyForCmds Rule useEnvOnlyForCmds /AS/EVENTSPRING/useEnvOnlyForCmds 0 = run commands with command-line arguments (default) 1 = do not use command-line arguments 1 supported by PATROL KM for Event Management version 2.4.02 or later 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. Table 44 Rule Configuration Variable Values Example Support Menu Command Access useEnvOnlyForCmds Rule allowInfoRecoveryActions /AS/EVENTSPRING/allowInfoRecoveryActions 0 = recovery actions not enabled for INFORMATION events (default) 1 = recovery actions enabled for INFORMATION events 0 supported by PATROL KM for Event Management version 2.7or later None
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 45 Rule Configuration Variable Values SpoolDirectory Rule spoolDirectory /AS/EVENTSPRING/spoolDirectory directory path The default location is the directory specified in the PATROL_HOME environment variable.
Example Support
/usr/local/patrol_reports supported by PATROL KM for Event Management version 2.4.02 or later
Chapter 5
165
Local Alert Settings
setParameterValue
You can use the setParameterValue rule to set the value of an active parameter. Table 46 Rule SetParameterValue Rule setParameterValue
.
Configuration /AS/EVENTSPRING/setParameterValue Variable Format PARAMETER=VALUE,DELAY=N,...,PARAMETER=VALUE,DELAY=N

s
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 Support
/CPU/CPU/CPUCpuUtil=ALARM,.../CPU/CPU/CPUCpuUtil=CLEAR,DELAY =5 supported by PATROL KM for Event Management version 2.5.00 or later

You 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.
166
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. Table 47 Rule Configuration Variable Values Example alertResend Rule alertResend /AS/EVENTSPRING/ALERT/object/alertResend Alarm_Resends,Warning_Resends 2,1
Menu Command Access Event Management => Alert Settings => Local Alert Settings => Alert Resend
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 48 Rule Values Example Support Menu Command Access alertLocalCommand Rule alertLocalCommand notification script or program /usr/patrol/my_notify.sh supported by PATROL KM for Event Management version 2.4.05or later Event Management => Alert Settings => Local Alert Settings => Notification Command
Configuration Variable /AS/EVENTSPRING/ALERT/object/alertLocalCommand
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. Table 49 Rule arsCommand Rule arsCommand
Configuration Variable /AS/EVENTSPRING/object/arsCommand /AS/EVENTSPRING/object/arsCommandINFORMATION /AS/EVENTSPRING/object/arsCommandWARNING /AS/EVENTSPRING/object/arsCommandALARM Values Example Support Menu Command Access recovery script or program /usr/patrol/filesystem_recovery.sh supported by PATROL KM for Event Management version 2.4.05 or later 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.
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.
168
Remote Alert Settings
Table 50 Rule
arsCmdType Rule arsCmdType

s s s s
Configuration Variable
/AS/EVENTSPRING/object/arsCmdType /AS/EVENTSPRING/object/arsCmdTypeINFORMATION /AS/EVENTSPRING/object/arsCmdTypeWARNING /AS/EVENTSPRING/object/arsCmdTypeALARM
Values Example Support Menu Command Access
command type PSL supported by PATROL KM for Event Management version 2.4.05 or later Event Management => Alert Settings => Local Alert Settings => Recovery Action Command Type
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. Table 51 Rule Configuration Variable Values alertResetOnInit Rule alertResetOnInit /AS/EVENTSPRING/ALERT/alertResetOnInit 0 - Do not send reset alert 1 - Send reset alert
Menu Command Access Event Management => Alert Settings => Local Alert Settings => Send Reset on Init

You can use the Remote Alert Settings menu commands to specify the notification servers and the communication settings you want to use for remote notifications.
NOTE
The notification server must be running when you set up PATROL KM for Event Management alert rules on remote agents.
Chapter 5
169
NOTIFICATION_SERVER
You can use the following notification server configuration variables to identify the primary and backup notification servers for the remote agents.
s
NOTIFICATION_SERVER1.defaultAccountthe user name and password for the primary notification sever NOTIFICATION_SERVER2.defaultAccountthe user name and password for the backup notification sever NOTIFICATION_SERVER1hostname and port number of the primary notification server NOTIFICATION_SERVER2hostname and port number of the backup notification server
Table 52
Remote Alert Settings: Configure Notification Servers Configuration Variable /AS/EVENTSPRING/NOTIFICATION_SERVER1.defaultAccount (primary) /AS/EVENTSPRING/NOTIFICATION_SERVER2.defaultAccount (backup) user/encrypted password patrolns/FB0A195D062696
Configuration Variable Values Example
Menu Command Access Event Management => Quick Config => Remote Agent Table 53 Remote Alert Settings: Configure Notification Servers Configuration Variable /AS/EVENTSPRING/NOTIFICATION_SERVER1 (primary) /AS/EVENTSPRING/NOTIFICATION_SERVER2 (backup) host,agent port number ns1,3181
Configuration Variable Values Example
Menu Command Access Event Management => Quick Config => Remote Agent
RemoteAgentCommSettings
You can use the RemoteAgentCommSettings configuration variable to configure the remote communication settings for the following situations:
s s
the agent sending events to a notification server an availability monitor checking the availability of monitored agents
Table 54 Values
Remote Alert Settings: Remote Communication Settings Configuration Variable TCP UDP,timeout,retries
Configuration Variable /AS/EVENTSPRING/RemoteAgentCommSettings
170
Notification Target Rules
Table 54 Example
Remote Alert Settings: Remote Communication Settings Configuration Variable UDP,100,3 Event Management =>Alert Settings => Remote Alert Settings => Remote Comm Settings
Menu Command

You 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.
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.
emailTargets
You can use emailTargets rules to specify e-mail accounts as notification targets.
Chapter 5
171
Table 55 Rule:
Notification Targets: Email Target Configuration Variable emailTargets
Configuration /AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsLocalINFORMATION Variable /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/emailTargetsRemoteINFORMATIO N /AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsRemoteWARNING /AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsRemoteALARM /AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsRemote Values Example Menu Command Access email_target1,email_target2,mail_targetn patrol,admin@company.com Event Management => Alert Settings => Notification Targets => Email
pagerTargets
You can use pagerTargets rules to specify one or more pagers as notification targets. Table 56 Rule Configuration Variable Notification Targets: Pager Target Configuration Variable pagerTargets /AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsLocalINFORMATIO N /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/pagerTargetsRemoteINFORMATI ON /AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsRemoteWARNING /AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsRemoteALARM /AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsRemote pager_target1,pager_target2,pager_targetn adminpg Event Management => Alert Settings => Notification Targets => Pager
Values Example Menu Command Access
172
customTargets
You can use the customTargets rule to specify custom notification targets. Table 57 Rule Notification Targets: Custom Target Configuration Variable customTargets
Configuration /AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsLocalINFORMATI Variable ON /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/customTargetsRemoteINFORMA TION /AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsRemoteWARNIN G /AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsRemoteALARM /AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsRemote Values Example Menu Command custom_target1,custom_target2,custom_targetn glamis Event Management => Alert Settings => Notification Targets => Custom
ttTargets
You can use ttTargets rules to specify trouble ticket notification targets. Table 58 Rule Configuration Variable Notification Targets: TT Targets Configuration Variable 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 trouble_tix_target1,trouble_tix_target2,trouble_tix_targetn ttpatrol
Values Example
Menu Command Event Management => Alert Settings => Notification Targets => Trouble Ticket
Chapter 5
173
Blackout Settings
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.
Blackout Settings
You 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. Table 59 Rule Configuration Variable Values Blackout Periods Configuration Variable blackoutPeriod /AS/EVENTSPRING/BLACKOUT/object/blackoutPeriod 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
__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.
174
Notification Server Settings
Table 60 Values Example
Overrides Configuration Variable /AS/EVENTSPRING/__OVERRIDE__/object/rule day start stop=value_for_rule Sat 0 86399,Sun 0 86399=oncallpager
Menu Command Access Event Management => Alert Settings => Overrides
Notification Server Settings

You 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 61 Rule Configuration Variable Values Notification Server Settings: Remote Target Setting Configuration Variable nsRemoteTargetSetting /AS/EVENTSPRING/NS/nsRemoteTargetSetting
s
Ignoreremote 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. Overridenotification is sent only to the targets defined at the remote agent. Forwardremote 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 Settings
You 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 Rule msgText Configuration Variable msgText
Configuration /AS/EVENTSPRING/ALERT/MSG/object/msgText Variable /AS/EVENTSPRING/ALERT/MSG/object/msgTextINFORMATION /AS/EVENTSPRING/ALERT/MSG/object/msgTextWARNING /AS/EVENTSPRING/ALERT/MSG/object/msgTextALARM Values message_replacement_text message_replacement_variables message_replacement_text_and_variables %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
Example
NOTE
If you do not specify INFORMATION, WARNING or ALARM, the same message format is used for all events.
176
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). Table 63 Rule Configuration Variable msgBody Configuration Variable 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 message_replacement_text message_replacement_variables message_replacement_text_and_variables %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
Values
Example
NOTE
If you do not specify INFORMATION, WARNING or ALARM, the same message format is used for all events.
An example of a reworded message template is: %HOSTNAME% has CPU Processor time of %PARAMETER_VALUE% for time zone %TIMEZONE% for %OS_TYPE% At run time, the message could be displayed as: 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
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.
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. Table 64 Custom Configuration Variables /AS/EVENTSPRING/object/CustomId1 /AS/EVENTSPRING/object/CustomId2 custom_identifier financial_app supported by PATROL KM for Event Management version 2.4.02 or later Event Management => Alert Settings => Custom Identifiers => CustomID1 Event Management => Alert Settings => Custom Identifiers => CustomID2
Configuration Variable Values Example Support Menu Command Access
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.
178
Custom Settings
Table 65
allowOperator Variable /AS/EVENTSPRING/MENU_COMMANDS/allowOperator

s s s s s s s s s s s s s s s s s s s s s s s s s s
Configuration Variable 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
Support
supported by PATROL KM for Event Management version 2.5.00 or later
All configuration changes take affect immediately once they have been applied. The following are exceptions:
s s
arsAction, only in certain circumstances RemoteAgentCommSettings
These configuration settings are updated by restarting the PATROL Agent after applying the configuration change.
Chapter 5
179
Custom Settings
active
You can use the active configuration variable to set the status of an application class.
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 /AS/EVENTSPRING/APPLICATION_CLASSES/object/active 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) supported by PATROL KM for Event Management version 2.4.05.02 or later
Support
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 67
appClassSettingsStatusFlag Variable /AS/EVENTSPRING/APPLICATION_CLASSES/STATUSFLAGS/appClassSettingStatusF lag 0 = use KM defaults 1 = use PATROL KM for Event Management application class settings 2 = refresh active rules supported by PATROL KM for Event Management version 2.4.02 or later
Support
180
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. Table 68 Values Example Support disableNotifyAnnotations /AS/EVENTSPRING/disableNotifyAnnotations 0 = dont disable annotations (default) 1 = disable annotations 1 supported by PATROL KM for Event Management version 2.6.00 or later
Menu Command Access None
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. Table 69 Values Example Support disableNotifyAnnotations /AS/EVENTSPRING/maxEventsToReport Any integer value. The default value is 100. 100 supported by PATROL KM for Event Management version 2.7.00 or later
Availability
You can use the availability settings to specify the agents and hosts that PATROL monitors for availability.
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. Table 70 Values Example Add Target Configuration /AS/EVENTSPRING/AVAILABILITY/Targets(Targets2) host PATROL_Agent_port SNMP_port glamis 3181 161,mirage - 161
Menu Command Access Event Management => Availability => Add Target
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. Configuration Variable Values Example /AS/EVENTSPRING/AVAILABILITY/snmpSettings SNMP_Community SNMP_Timeout SNMP_Retries public,500,3
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. Configuration Variable Values Example /AS/EVENTSPRING/AVAILABILITY/snmpOid SNMP_ObjectID .1.3.6.1.2.1.1.3.0
182
Availability
Updated
Use the Updated configuration variable to indicate that changes have been made to the availability targets and availability checkers.
NOTE
The KM automatically sets the Updated variable to 1 whenever you make a change using the Availability menu command.
Table 71 Values
Add Target: Updated Flag Configuration /AS/EVENTSPRING/AVAILABILITY/Updated 0 - Ignore changes to Targets and Primary configuration variables 1 - Enable changes to Targets and Primary configuration variables
Primary
You can use the Primary configuration variable to specify the primary availability monitor. Table 72 Values Example Primary Configuration Variable /AS/EVENTSPRING/AVAILABILITY/Primary host_primary_monitor PATROL_Agent_port SNMP_port 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.
Blackout
You can use the Blackout configuration variable to specify time periods to stop monitoring of a host or an agent.
Chapter 5
183
Availability
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 Values Example
Blackout Configuration Variable /AS/EVENTSPRING/AVAILABILITY/Blackouts/host_port day1 start1 stop1, day2 start2 stop2 Sat 3600 7200,Wed 3600 7200
Menu Command Access Event Management => Availability => Blackout Periods
pingCmd
You can use the pingCmd configuration variable to specify the operating system command to use when checking host availability. Table 74 Values Example PingCmd Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingCmd absolute_path_to_OS_ping_command /usr/patrol/myping.sh
Menu Command Access Event Management => Availability => Ping Command
pingOkString
The pingOkString configuration variable is the string that appears in the output of the pingCmd. Table 75 Values Example pingOKString Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingOkString ping output bytes
184
Availability
pingPacketSize
The pingPacketSize configuration variable defines the packet size of the ping command in bytes. Table 76 Values Example Support pingPacketSize Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingPacketSize number of bytes; if not specified, the default value is 32 bytes 32 supported by PATROL KM for Event Management version 2.6.00 or later This variable is not supported on OpenVMS or iSeries.
pingAttempts
The pingAttempts configuration variable defines the number of pings attempted. Table 77 Values Example Support pingAttempts Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingAttempt number of attempts; if not specified, the default value is 2 attempts 2 supported by PATROL KM for Event Management version 2.6.00 or later This variable is not supported on OpenVMS or iSeries.
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.
Chapter 5
185
Parameter Settings
Table 78 Values Example Support
pingArgs Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingArgs ping command arguments -n 2 -|32 supported by PATROL KM for Event Management version 2.6.00 or later
checkerAccount.defaultAccount
You can use the checkerAccount.defaultAccount configuration variable to specify the account to use when performing pings against other PATROL Agents. Table 79 Values Example Checker Account Configuration Variable /AS/EVENTSPRING/AVAILABILITY/checkerAccount.defaultAccount username/PEM_encrypted_password 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
You 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.
186
Parameter Settings
Table 80
Parameter Settings: Thresholds Configuration /AS/EVENTSPRING/PARAM_SETTINGS/THRESHOLDS/object where object is the full parameter object name such as
Configuration Variable Value Example
/FILESYSTEM/root/FSCapacity
parameter_settings 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 The following table provides a detailed description of the THRESHOLDS configuration rule. Table 81 Item Understanding the THRESHOLDS Rule (Part 1 of 2) Description
/AS/EVENTSPRING variable folder /PARAM_SETTINGS variable folder /THRESHOLDS /NT_CPU /__ANYINST__ CPUprcrProcessorTi mePercent 1 0 0 0 0 0 0 1 80 85 0 0 variable folder application class a variable that indicates any instance of the application class. You could also specify a specific instance instead. parameter name indicates that the parameter is active Border Settings indicates that the border range is inactive the border begin range the border end range specifies when to trigger alarm; 0 means immediately on the first occurrence if the trigger value is non zero, this value specifies the number of occurrences before triggering an alarm specifies that the state is OK Alarm1 Settings indicates that the Alarm 1 alarm is active the Alarm 1 begin range the Alarm 1 end range specifies when to trigger alarm; 0 means immediately on the first occurrence if the trigger value is non zero, this value specifies the number of occurrences before triggering an alarm
Chapter 5
187
Parameter Settings
Table 81 Item 1 1 85 100 0 0 2
Understanding the THRESHOLDS Rule (Part 2 of 2) Description specifies that the state is WARN Alarm 2 Settings indicates that the Alarm 2 alarm is active the Alarm 2 begin range the Alarm 2 end range specifies when to trigger alarm; 0 means immediately on the first occurrence if the trigger value is non zero, this value specifies the number of occurrences before triggering an alarm specifies that the state is ALARM
interval
You can use the interval configuration variable to specify poll times for standard and collector parameters. Table 82 Parameter Settings: poll times Configuration /AS/EVENTSPRING/PARAM_SETTINGS/POLLTIMES/object/interval where object is the full parameter object name such as Configuration Variable /FILESYSTEM/root/FSCapacity Values Example Menu Command Access polltime_in_seconds 90 Event Management => Parameter Settings => Polltimes
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.
188
Parameter Settings
Table 83
Parameter Settings: Status Flags Configuration /AS/EVENTSPRING/PARAM_SETTINGS/STATUSFLAGS/object/ paramSettingsStatusFlag where object is the full parameter object name such as /FILESYSTEM/root/FSCapacity
Note: To apply the setting globally, omit the object reference, as shown below:
/AS/EVENTSPRING/PARAM_SETTINGS/STATUSFLAGS/paramSettingsStatusFlag 0 - PATROL KM for Event Management settings are ignored 1 - PATROL KM for Event Management parameter settings have been processed 2 - Refresh thresholds 4 - Refresh poll times 6 - Refresh thresholds and poll times
NOTE
You can use a special instance name, __ANYINST__, for all instances of a parameter.
processWildcards
You can use the processWildcards rule to enable the use of wildcards for instance names when specifying parameter thresholds and poll times. Table 84 Values Parameter Settings: poll times Configuration 1 = enable wildcards 0 = disable wildcards Example Menu Command Access Support 1 None supported by PATROL KM for Event Management version 2.700 or later
Configuration Variable /AS/EVENTSPRING/processWildcards
Chapter 5
189
Instance Filtering Settings
Instance Filtering Settings

You 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. Table 85 Values Example Menu Command Access Filter List Configuration Variable /AgentSetup/ApplicationClass.filterList list_of_application_instances C:,D:,E:,F: Event Management => Instance Filtering => Edit Filter List
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 86 Values Menu Command Access Filter Type Configuration Variable /AgentSetup/ApplicationClass.filterType Include Exclude Event Management => Instance Filtering => Edit Filter List
190
Chapter
Parameters
This chapter list PATROL KM for Event Management parameters and shows their default settings. The following topics are discussed: Parameter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Parameter Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Chapter 6
191
Parameter Summary
Parameter Summary
PATROL KM for Event Management parameters are in the following applications classes:
s s
AS_EVENTSPRING AS_AVAILABILITY
Table 87 lists PATROL KM for Event Management parameters. Table 87 Parameter AlertTest AgentLoginDenied PATROL KM for Event Management Parameters (Part 1 of 3) Description tests the notification systems and rules without forcing a production parameter into an alert state 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.
AS_EVENTSPRING Application Class
192
Parameter Summary
Table 87 Parameter
PATROL KM for Event Management Parameters (Part 2 of 3) Description 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. 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.
BlackoutEvents
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. 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.
EventCollector
collects the NOTIFY events on the monitored agent and sets the value of the following parameters:
s s s
NotifiedEvents EscalatedEvents BlackoutEvents
RefreshParamSettin updates parameter settings as required gs ResendAlertQueue RetriggerEventQue ue AlertTest resends specified alerts retriggers events that failed to be sent to a notification server
AS_AVAILABILITY Application Class tests the notification systems and rules without forcing a production parameter into an alert state
Chapter 6
193
Parameter Defaults
Table 87 Parameter
PATROL KM for Event Management Parameters (Part 3 of 3) Description
AvailabilityMonitor Collector that performs availability checks and sets the value of the following Coll parameters:
s s s
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 SnmpPingFailures indicates the host is unavailable using an ICMP ping indicates the SNMP Agent is unavailable
Parameter Defaults
Table 88 lists the default properties for each PATROL KM for Event Management parameter. Table 88 PATROL KM for Event Management Parameter Defaults (Part 1 of 2) Annotated N Y Y Y Y Y
Parameter AlertTest
Type Con
Alarm1 Alarm2 1-50 51-100
Border N/A
Schedule N/A
Icon Gauge
Units N/A
AgentLoginDenied NotifiedEvents
Con Con
N/A N/A N/A N/A
0-0 N/A
N/A N/A
Graph Graph
N/A N/A
194
Active
Parameter Defaults
Table 88
PATROL KM for Event Management Parameter Defaults (Part 2 of 2) Annotated Y Y N N N N N N Y N Y Y Y Y Y Y Y Y Y Y
Parameter BlackoutEvents EscalatedEvents EventCollector RefreshParamSettings ResendAlertQueue RetriggerEventQueue
Type Con Con Coll Std Std Std
Alarm1 Alarm2 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A 1 N/A 1 1 2
Border N/A N/A N/A 0-1000 N/A N/A N/A N/A N/A N/A
Schedule N/A N/A 30 seconds 1.5 minutes 10 minutes 2 minutes 2 minutes 3 seconds N/A N/A N/A
Icon Graph Graph N/A Graph Graph Graph N/A Graph Graph Graph
Units N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
AvailabilityMonitorCo Coll ll AgentPingFailures HostPingFailures SnmpPingFailures Con Con Con
Chapter 6
195
Active
Parameter Defaults
196
Chapter
Troubleshooting PATROL KM for Event Management

7
This chapter contains information for troubleshooting PATROL KM for Event Management. This chapter contains the following topics: Configuration Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cannot Send E-mail Notifications to Multiple Targets . . . . . . . . . . . . . . . . . . . . . Parameters are Unavailable or are Not Being Updated. . . . . . . . . . . . . . . . . . . . . Too Many E-mail Alerts Are Being Generated . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameters Show a Negative Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameter Annotations Show Incorrect Targets or Other Errors . . . . . . . . . . . . . AgentLoginDenied Parameter is in Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Availability Monitor is Not Pinging Frequently Enough . . . . . . . . . . . . . . . NOTIFY_EVENTS not Generated when Parameter is in Alarm . . . . . . . . . . . . . Parameters Setting Lost After Agent Restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notification Message not Sent from OpenVMS Server . . . . . . . . . . . . . . . . . . . . . AS_AVAILABILITY Application Not Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . When Using event_trigger2() Statements, Notifications Sent to Wrong Target Gathering Diagnostic Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Where to Find Diagnostic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining PATROL KM for Event Management Version Number . . . . . . . . 198 198 200 201 202 203 203 205 205 206 207 207 207 208 208 208 209
Chapter 7
197
Configuration Problems
This section contains troubleshooting information for the following common configuration problems: Problem Type Cannot Send E-mail Notifications to Multiple Targets Parameters are Unavailable or are Not Being Updated Too Many E-mail Alerts Are Being Generated Parameters Show a Negative Number Parameter Annotations Show Incorrect Targets or Other Errors AgentLoginDenied Parameter is in Alarm The Availability Monitor is Not Pinging Frequently Enough NOTIFY_EVENTS not Generated when Parameter is in Alarm Parameters Setting Lost After Agent Restart Notification Message not Sent from OpenVMS Server AS_AVAILABILITY Application Not Displayed Page 198 200 201 202 203 203 205 205 206 207 207
When Using event_trigger2() Statements, Notifications Sent to Wrong Target 207
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. Explanation The PATROL KM for Event Management is not configured to pass command-line arguments. Solution 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.
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.
198
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 1 From the PATROL console, access the host KM menu commands as described in
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.
5 To save your changes, click Accept. 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.
200
Explanation PATROL KM for Event Management is not configured correctly.
Solution 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.
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. Explanation Parameters and thresholds need tuning. Solution 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 Set the rule /AS/EVENTSPRING/ALERT/arsAction to 0. /AS/EVENTSPRING/ALER T/arsAction is set to 4. 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. Explanation The notification command is failing at the notification server. Solution 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:
s s s
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 Check the permissions on the script file. not have the proper permissions to execute the script file. The PATROL Agent on the notification server is not running. The remote notification event did not reach the notification server. Verify that the PATROL agent on the notification server is running. 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.
s
/AS/EVENTSPRING/alertSystem should be set to REMOTE. /AS/EVENTSPRING/NOTIFICATION_SERVER1.defaultA ccount 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.
202
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. Explanation The notification rules are not configured correctly. Solution 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.
AgentLoginDenied Parameter is in Alarm

The AgentLoginDenied parameter, which monitors failed login attempts to the agent, is in alarm. Explanation The notification server account is not valid. Solution 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==ipaddressoftheclientconnecting(e.g.,console,PatrolCli,remoteagent, etc.
Example)
patrol T:936.1389@192.168.1.233
To analyze the annotated data more closely, you can run this Unix command:
dump_hist-paramAgentLoginDenied-annotate|grep@|awk-F@{'print$2'}|sort | uniq
It returns the hosts that attempted to connect to the notification server.
204
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. Explanation Solution
The availability Monitor a maximum of 100 agents. monitor is monitoring too many 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.
NOTIFY_EVENTS not Generated when Parameter is in Alarm

A parameter alarms but a NOTIFY_EVENT is not sent to the notification server. Explanation Solution
The parameter is being set There is currently no workaround for this issue. to ALARM by way of an PSL command, not because Some KMs change the state of a parameter using a PSL command. it exceeded its threshold. 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 Take the following steps: catalog (StdEvents.ctg) is being used. 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. Explanation The allowsendparamonly variable exists in Solution
Remove the allowsendparamonly variable.For %PATROL_HOME%\common\patrol.d\pat instructions, see Removing the allowsendparamonly Variable on page 206. rol.conf file and is set to true. 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.
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:
allowsendparamonly=true
5 Save and close the file. 6 Reinitialize the agent.
206
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. Explanation The message subject line or body text contain too many characters. Solution 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 For more information about configuring notification rules, see not configured properly. Configuring Notification Servers on page 71.
AS_AVAILABILITY Application Not Displayed

The AS_AVAILABILITY application icon is not displayed in the PATROL Console. Explanation Availability targets have not been added. Solution 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.
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. Explanation Solution
The event_trigger2() statement obtains the application If this problem occurs, you will need to class, instance, and parameter name from the change your notification rules so that NOTIFY_EVENT details, not from the event origin. notifications are sent to the correct target. For more information see Event Details on page 156.
Chapter 7
207
Gathering Diagnostic Information

This 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. Type Installation logs System Output Window PATROL Event Manager parameter annotation data Location
%USERPROFILE%\Application Data\BMCINSTALL\
Description See Installation Logs on page 208. The system output window contains messages relating to the operation of KMs, including error messages. 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. These parameter annotations contains information about every notification related event that passes through the PATROL KM for Event Management.
See the documentation for you PATROL console. From the PATROL console, right-click the host and select Event Manager. From the PATROL console, access the host Event Management application and open one of the following parameters:
s s s
NotifiedEvents BlackoutEvents EscalatedEvents
Double-click the annotated data points on the graph.
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:
208
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
210
Appendix
Accessing Menu Commands, InfoBoxes, and Online Help

A
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Accessing Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Appendix A
211
Accessing KM Commands and InfoBoxes
Accessing KM Commands and InfoBoxes

Table 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
Console
To access menu commands
To access InfoBoxes 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 Microsoft In either the Desktop tree tab or Windows Servers work area, right-click a computer or application icon and choose KM Commands from the pop-up menu. PATROL Console for Unix
In the work area, right-click a With the middle mouse button, computer or application icon to click an application class or display a pop-up menu that parameter icon. contains KM-specific commands. 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 Windows Edition
PATROL Central Operator Web Edition
In the tree view area, right-click In the tree view area, right-click an application icon and choose a PATROL object and choose Knowledge Module Commands Infobox from the pop-up menu. from the pop-up menu.
212
PATROL for Microsoft Windows Servers Getting Started
Accessing Online Help

Table 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)
Console PATROL Console for Microsoft Windows Servers
To access product help From the console menu bar, choose Help => Help Topics => PATROL Knowledge Modules.
To access application class help 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.
To access parameter help

s
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 Choose Attributes => Right-click a parameter bar, choose Help On => Application Classes and icon and click Help On. Knowledge Modules. double-click the application name. Click Show Help in the Application Definition dialog box.
Appendix A
213
Table 0-2
Accessing Online Help (Part 2 of 2)
Console PATROL Central Operator Windows Edition
To access product help From the console menu bar, choose Help => Help Topics. In the Contents tab, click the name of your product. In the upper right corner of PATROL Central, click Help and choose PATROL KM Help.
To access application class help In the Operator tab of the navigation pane, select an application icon and press F1. In the tree view, right-click an application class and choose Help.
To access parameter help In the Operator tab of the navigation pane, select a parameter icon and press F1. In the tree view, right-click a parameter and choose Help.
PATROL Central Operator - Web Edition
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
A
accounts adminstrative rights required for 28 availability monitoring 92 console connection 28 domain 28 generating failed login alarms 204 operator 28 root 29 setting up for installation 27 Unix 28 Windows 27 action scripts, AlarmPoint 98 active (configuration variable) 180 ActiveX control 66 addresses default 72 email, multiple 198 paging 99 AgentLoginDenied 203 defined 192 resetting 204 troubleshooting 203 using annotation data 204 AgentPingFailures 194 agents applying settings to 111 assigning notification servers to 73 configuring 7375 maximum to monitor 61 monitoring for availability 8793 persistent connection to 75 protocol settings 79 tuning 91 where to install 32 alarm ranges default 194 setting 106 AlarmPoint benefits 95 integrating with 94103 java client 21, 96 notification script for 95
215
alarms generating notification for 128 resetting 204 triggering 106 tuning 201 alert condition 174 alertLocalCommand defined 167 using 99 alertResend defined 167 using 19, 20, 78 alertResetOnInit defined 169 using 19 alerts blacking out 115120 clearing outstanding 77 configuring 76 false 77 resending 78 troubleshooting 201 variables for 158 alertSystem defined 162 troubleshooting 202 using 19, 20, 72, 76 AlertTest 193 aliases, account 29 ALL_COMPUTERS.KM 43 allowInfoRecoveryActions 165 allowOperator 178 allowOverrides 163 allowsendparamonly variable 206 annotations disabling 181 parameter 194 troubleshooting 203, 208 using in recovery actions 140144 AP_PATROL_EmailActionScriptV521-01.ppx 98 AP_PATROL_FaxActionScriptV521-01.ppx 98 APAgent.xml 96 appClassSettingsStatusFlag 180 application classes AS_AVAILABILITY 23 AS_EVENTSPRING 23 hierarchy 23 icons 23 variable for 158 architecture 16 arguments command-line 164, 198 NOTIFY_EVENT 156 ping command 93 arsAction defined 161 troubleshooting 201 arsAction, continued using 19, 85, 99 arsCmdType defined 168 using 19, 142 arsCommand defined 168 using 19, 20, 142 AS/400 See also iSeries installing on 42 scripts 67 subject line limitations 80 AS_AVAILABILITY.km 55 defined 23 InfoBox items 24 loading 53 preloading 91 troubleshooting 207 AS_EVENTSPRING.km defined 23 InfoBox items 24 loading 53 AS_EVENTSPRING_ALL_COMPUTERS.km 53 AS_EVSLocalAlertNotify.bat editing 68 requirements for using 66 AS_EVSLocalAlertNotify.pl location 65 requirements for using 66 AS_EVSLocalAlertNotify.sh 65 AS_EVSLocalAlertNotifyAP.bat 99 AS_EVSLocalAlertNotifyAP.sh 99 availability blackouts 184 monitoring 8793 AvailabilityMonitorColl defined 194 troubleshooting 205 using 61
B
backing up notification scripts 69 backup availability monitor 89 backup notification servers 58 batch file 66 best practices 61 Blackout (configuration variable) 183 BlackoutEvents annotations 208 defined 193 troubleshooting 203 blackoutPeriod defined 174 using 19
216
blackouts, configuring 115120 Blat defined 65 troubleshooting 198 version tested with 66 BMC Software, contacting 2 body, notification message 80 border, parameter 105 Bourne shell 45 configuration variables, continued customTargets 173 disableNotifyAnnotations 181 emailTargets 171 filterList 190 filterType 190 interval 188 LoginDeniedIgnoredUsers 164 msgBody 177 msgText 176 NOTIFICATION_SERVER1.defaultAccount 170 nsRemoteTargetSetting 175 pagerTargets 172 paramSettingsStatusFlag 188 pingArgs 185 pingAttempts 185 pingCmd 184 pingOkString 184 pingPacketSize 185 Primary 183 processWildcards 189 RemoteAgentCommSettings 170 setParameterValue 166 snmpOid 182 snmpSettings 182 spoolDirectory 165 Targets 182 Thresholds 186 ttTarget 173 Updated 183 useEnvOnlyForCmds 164 userdefined 157 configuring alarm ranges 104 AlarmPoint 96 alarms 104 availability monitoring 8793 backup availability monitor 89 blackouts 115120 globally 134 notification servers 7173 ping command 93 poll times 107 primary availability monitor 87 recovery actions 120125 remote agents 7375 thresholds 104 connection, persistent 75 consoles connection accounts 28 supported 26 copying rules 134 custom installation option 35 customer support 3 CustomId1 and CustomId2 defined 178 using 19
C
C shell 45 cache, PATROL 43 changing account, availability monitoring 92 notification messages 79 notification targets 171 parameter thresholds 104 ping commands 93 poll times 107 what is being monitored 112 checkerAccount.defaultAccount defined 186 using 92 clearing AgentLoginDenied parameter 204 false alerts 77 client, java 21 collection period, setting 107 colormap option 45 command-line 198 commands menu 151 operating system 142 ping, changing 93 commas in variables 157 configuration variables __ANYINST__ 189 __OVERRIDE__ 174 active 180 alertLocalCommand 167 alertResend 167 alertResetOnInit 169 alertSystem 162 allowInfoRecoveryActions 165 allowOperator 178 allowOverrides 163 appClassSettingsStatusFlag 180 arsAction 161 arsCmdType 168 arsCommand 168 Blackout 183 blackoutPeriod 174 checkerAccount.defaultAccount 186 CustomId1 and CustomId2 178
217
customizing notification messages 79 ping command 93 scripts 6769 customTargets defined 173 using 21, 99 environment variables, continued setting for Help browser 45 using in notification command 200 EPD (Electronic Product Download) site 31 error messages 208 EscalatedEvents 193 annotations 208 troubleshooting 203 event catalog variable 160 event class variable 160 event severity variable 160 event status variable 160 event type variable 160 event_trigger2() statement 207 EventCollector 193 events ID, variables for 159 NOTIFY_EVENT 156 PATROL standard 19 REMOTE_NOTIFY_EVENT 156 size limitations 157 standard 205 translating 20 example e-mail rule 154 PATROL objects 153 ping command 93, 94 rule inheritance 154 usage scenarios 128150 using targets 136 wildcard usage 108 eXceed 45 excluding instances from monitoring 112 exit statement 202
D
date variables 158 default email account 72 default port number 27 default values, parameter 194 defining notification servers 58 remote agents 58 targets 60 where to place rules 61 dependencies 55 deploying settings 59 designing availability monitoring 61 notification servers 60 diagnosing problems 197209 disableNotifyAnnotations 181 disabling annotations 181 monitoring of specific instances 112 notification 85 parameters 109 rules 86 use of event management KM thresholds 112 displaying in console 55
E
editing notification messages 79 scripts 6769 electronic product download (EPD) site 31 emailTargets defined 171 using 19 enabling ftp 29 notification 141 parameters 109 PATROL KM for Event Management thresholds 112 recovery actions 121 enterprise console 59 environment variables LANG 45 PATH 45 PATROL_BROWSER 46
F
failed login 204 failover configuring 89 features 17 filtering objects to monitor 112 filterList defined 190 using 114 filterType defined 190 using 113 first time installation 37 fixes, installing 30 ftp, enabling 29
H
Help, online 211
218
hierarchy, rule 154 host macro 94 hostname variable 157 HostPingFailures 194 KMs, continued installing QuickStart packages 35 loading and unloading 52 preloading 52 upgrading from an earlier version 43 Korn shell 45
I
ICMP ping 194 icon name variable 158 icon, parameter 194 importing action scripts 98 inheritance, rule 154 installation custom option 35 log files 208 preparing for 30 setting up installation accounts 27 system requirements 26 typical option 35 Unix account requirements 28 Windows account requirements 27 installing AlarmPoint java client 96 for the first time 37 on AS/400 (iSeries) 42 patches 30 upgrading from an earlier version 43 where to install PATROL Agent 32 instance name __ANYINST__ 189 using wildcards to represent 107 variable 158 integration AlarmPoint 94103 Blat 65 PATROL Enterprise Manager (PEM) 20 interval collection, changing 107 configuration variable 188 IP address variable 157 iSeries See also AS/400 installing on 42 scripts 67 subject line limitations 80
L
LANG environment variable 45 license requirements 27 Linux scripts 64 supported versions 26 loading KMs with the PATROL Console for Unix 55 with the PATROL Console for Windows 54 local installation 31 local notification 162 location, rule 61 lock, account 203 login, failed 204 LoginDeniedIgnoredUsers 164 logs, installation 208
M
MAIL utility 67 mailx 64 Make Connection Persistent option 75 managed system role 32 MAPI scripts 67 maxEventsToReport 181 maximum agents to monitor 61 menu commands, accessing 211212 merging blackout settings 118 messages body 177 customizing 140 error log 208 rewording 79 subject line 176 migrating from earlier version 43 monitoring agent availability 8793 notification servers 60 specific instances 112 msgBody defined 177 using 19 msgText defined 176 using 19 multiple targets, email 198
J
java client, AlarmPoint 96
K
KMs determining versions of 209 installing individual 35
219
N
negative value, parameter 202 Netscape Navigator 44 new PATROL users easy install option 35 installing for the first time 37 NFS 29 notification local versus remote 162 scripts, using 6471 server 17, 58 system, configuring 72 types supported 69 notification messages body text 80 length 80 rewording 79 subject line 80 where to send from 72 notification scripts backing up 69 customizing 69 editing 67 specifying 72 testing 70 notification servers benefits of 58 configuring 7172 defining 58 monitoring for availability 60 primary and backup 58 protocol settings 79 providing security for 59 notification targets defining 72 types 70 NOTIFICATION_SERVER1 defined 170 using 73 NOTIFICATION_SERVER1.defaultAccount defined 170 troubleshooting 202 using 73 NOTIFICATION_SERVER2 defined 170 using 73 NOTIFICATION_SERVER2.defaultAccount 170 NotifiedEvents annotations 181, 208 defined 192 troubleshooting 203 usage example 143 NOTIFY_EVENT description 156 missing 205 triggering 156
NOTIFY_EVENT, continued troubleshooting 203 nsRemoteTargetSetting 175
O
objects, PATROL 153 OpenVMS ping command 94 scripts 67 subject line limitations 80 support for 26 troubleshooting 207 operating systems, support for 26 operator accounts 28 OS (operating system) command type 142 type, variable 159 OS(operating system) supported 26 output window, system 208 overrides allowing 163 variable 174
P
PACFG (PATROL Agent Configuration) utility 206 pagerTargets 172 parameters activating 105 AgentLoginDenied 192 AgentPingFailures 194 AlertTest 192, 193 AvailabilityMonitorColl 194 BlackoutEvents 193 default values 194 EscalatedEvents 193 EventCollector 193 HostPingFailures 194 list of 192 NotifiedEvents 192 RefreshParamSettings 193 ResendAlertQueue 193 RetriggerEventQueue 193 set value 166 SnmpPingFailures 194 variables for 158 paramSettingsStatusFlag defined 188 using 111 parent instance variable 158 partitions, installing on 29 patches, installing 30 PATH environment variable 45
220
PATROL Agents See also agents version of, variable for 160 where to install 32 PATROL Configuration Manager icon 22 using 134 PATROL Enterprise Manager (PEM) 59 PATROL Event Translator (PET) 20 PATROL objects 153 PATROL Script Language (PSL) 124 PATROL security 34 PATROL.conf 206 PATROL_BROWSER environment variable 46 PATROL_CACHE 43 pconfig variables 17 PEM (PATROL Enterprise Manager) 59 Perl scripts 65 permissions 202 persistent agent connection 75 PET (PATROL Event Translator) 20 pingArgs defined 185 using 93, 94 pingAttempts 185 pingCmd defined 184 OpenVMS 94 using 93 pinging arguments 93 commands 93 InfoBox items 24 on OpenVMS 94 problems with 205 variables 184186 pingOkString 184 pingPacketSize 185 planning availability monitoring 61 installation 30 notification 58 platforms, supported 26 poll times applying to agent 111 disabling 112 setting 107 practices, best 61 preloading KMs 52 preparing for installation 30 Primary (configuration variable) 183 problem resolution 197209 processWildcards defined 189 using 111 product application classes 23 architecture 16 capabilities 15 components 15 features 16 uninstalling in Windows environments 48 product support 3 protocol settings 79 PSL (PATROL Script Language) 124
R
ranges, alarm 106 recommendations, rule location 61 recovery actions about 121 allowing 161 configuring 120125 enabling 121 examples 144 rule location 63 testing 149 redundancy 58, 60 RefreshParamSettings 193 remote agents, assigning notification servers to 73 remote installation 31 REMOTE_NOTIFY_EVENT triggering 156 troubleshooting 203 RemoteAgentCommSettings defined 170 using 79 removing annotations 181 customized KM files 43 menu commands 43 notification 85 renaming notification scripts 69 requirements license 27 system 26 Unix account 28 Unix script 65 Windows account 27 Windows script 66 ResendAlertQueue 193 resending alerts 78 Reset AgentLoginDenied Alert menu command 204 restart, agent 206 RetriggerEventQueue 193 rewording default notification message 81 example 136 messages 79 variables 81
221
rules __OVERRIDE__ 174 See also configuration variables active 180 alertLocalCommand 167 alertResend 167 alertResetOnInit 169 alertSystem 162 allowOperator 178 allowOverrides 163 appClassSettingsStatusFlag 180 arsAction 161 arsCmdType 168 arsCommand 168 Blackout 183 blackoutPeriod 174 checkerAccount.defaultAccount 186 copying 134 CustomId1 and CustomId2 178 customTargets 173 disableNotifyAnnotations 181 e-mail 154 emailTargets 171 example 153 filterList 190 filterType 190 hierarchy 153 hierarchy of 154 inheritance 154 inheritance of 154 interval 188 LoginDeniedIgnoredUsers 164 loginDeniedIgnoredUsers 164 msgBody 177 msgText 176 notification server 170 nsRemoteTargetSetting 175 overriding 86 pagerTargets 172 paramSettingsStatusFlag 188 pingArgs 185 pingAttempts 185 pingCmd 184 pingOkString 184 pingPacketSize 185 Primary 183 processWildcards 189 RemoteAgentCommSettings 170 setParameterValue 166 snmpOid 182 snmpSettings 182 spoolDirectory 165 Targets 182 testing 84 Thresholds 186 ttTarget 173 Updated 183 rules, contined useEnvOnlyForCmds 164 using wildcards in 107 where to locate 61
S
scalability 205 scenarios 128150 schedule, parameter 195 scheduling interval, setting 107 scripts action 98 AlarmPoint 98, 99 AS/400 (iSeries) 67 backing up 69 batch file 66 customizing 69 editing 6769 Linux 64 OpenVMS 67 Perl 65 renaming 69 testing 70 Unix 64 using 6471 using exit statements in 202 Windows 65 security account 28 changing levels 34 notification server 59 SED Utility 143 Send Distribution utility 67 send_mapi.vbs 66 sendmail.vbs 66 servers deploying settings to 59 monitoring for availability 60 notification 71 setParameterValue defined 166 using 103 setting environment variables for Help browser 45 shells Bourne 45 C 45 Korn 45 SMTP scripts 67 snmpOid 182 SnmpPingFailures 194 snmpSettings 182 spoolDirectory 165 standard events catalogue 43 standard events, PATROL 19, 159, 205 StdEvent.ctg 43
222
StdEvents.ctg.EVS 205 stopping notification 85 the monitoring of objects 112 subject line back slashes in 81 length limitations 80 notification message 80 rewording 79 rewording variables 81 support, customer 3 supported platforms 26 system output window 208 system requirements 26
U
UDP Port variable 157 UDP protocol 79 umask setting 29 uninstalling 48 units, parameter 194 Unix account requirements 28 browser requirements 44 scripts 64 subject line limitations 80 using for availability monitoring 61 unloading KMs with the PATROL Console for Unix 57 with the PATROL Console for Windows 57 Updated (configuration variable) 183 upgrading 43 backing up scripts prior to 30 from an earlier version of the KM 43 useEnvOnlyForCmds changing value of 199 defined 164 troubleshooting 198 user account 45 User defined variables 159 userdefined configuration variable 157
T
tabs in variables 157 targets availability monitoring 88 custom 21 example 136 rules 171174 using multiple 198 where to locate 61 Targets (configuration variable) 182 TCP port variable 157 TCP protocol 79 technical support 3 telnet, enabling 29 testing AlarmPoint java client 97 notification scripts 70 notification using AlarmPoint 103 recovery actions 149 rules 84 thresholds applying to agent 111 configuration variable 186 disabling 112 PATROL KM for Event Management 104 rule for 187 setting 104 tuning 201 time variables 158, 159 Tivoli 59 Trigger NOTIFY_EVENT option 101 triggering alarms 106 troubleshooting 197209 ttTarget defined 173 using 70 typical installation option 35
V
variables alarm settings 159 alert 158 application class 158 date 158 disableNotifyAnnotations 181 event catalog 160 event class 160 event ID 159 event severity 160 event status 160 event type 160 hostname 157 icon name 158 instance name 158 IP address 157 maxEventsToReport 181 message-replacement 157161 OS type 159 parameter 158 parent instance 158 PATROL Agent version 160 PATROL_BROWSER 46 pconfig 17 pingArgs 186 pingAttempt 185
223
variables, continued pingPacketSize 185 TCP port 157 time 158, 159 UDP port 157 user-defined 159 using tabs or commas in 157 VB (Visual Basic) 65 verifying discovery 64 version, determining 209 Visual Basic (VB) 65 VMware, support for 29
W
What If? feature 84 wilcards 107 Windows accounts 27 scripts 65
224
Notes
*56925* *56925* *56925* *56925*
*52965*

PATROL Knowledge Module For Event Management User Guide - 2.7

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PATROL Knowledge Module For Event Management User Guide - 2.7

Uploaded by

Copyright:

Available Formats

PATROL KM for Event Management

Contacting BMC Software

United States and Canada

Outside United States and Canada

Restricted rights legend

Support by telephone or e-mail

Before contacting BMC Software

PATROL KM for Event Management

PATROL Knowledge Module for Event Management User Guide

PATROL Knowledge Module for Event Management User Guide

PATROL Knowledge Module for Event Management User Guide

Product Components and Capabilities

PATROL Knowledge Module for Event Management User Guide

Rules Stored as Pconfig Variables

PATROL Knowledge Module for Event Management User Guide

Sending Notification: Process Flow

Multiple. See steps 4 through 10.

Sending Alerts to an Enterprise Console: Process Flow

PATROL Knowledge Module for Event Management User Guide

Sending Pages using AlarmPoint: Process Flow

Using the PATROL Configuration Manager

Using the PATROL Configuration Manager

PATROL Configuration Manager Tasks

Tasks that Must be Completed Using PATROL KM for Event Management

PATROL Knowledge Module for Event Management User Guide

Application Classes and Instances

Application Classes and Instances

Application Class KM File

Application Class Hierarchy

Application Classes and Instances

Application InfoBox Items

To View the InfoBox on the PATROL Console for Unix

To View the InfoBox on the PATROL Console for Windows

KM Version the version of the PATROL KM for Event Management

PATROL Knowledge Module for Event Management User Guide

Installing and Migrating PATROL KM for Event Management

PATROL Installation Reference Manual

Table 7 Resource operating systems PATROL products

PATROL Knowledge Module for Event Management User Guide

Creating a Separate Account

Console Connection Accounts

PATROL Knowledge Module for Event Management User Guide

Virtual Machine Support Limitation

Preparing for Installation

Preparing for Installation

Backing up the Notification Script

Checking for Product Patches or Fixes Before Installing

PATROL Knowledge Module for Event Management User Guide

Preparing for Installation

Determining How to Install Products

Preparing for Installation

Determining Where to Install the PATROL Agent

Determining Where to Install KMs

PATROL Knowledge Module for Event Management User Guide

Preparing for Installation

PATROL Security Levels

PATROL Security Levels

Checking Security Levels

Assessing and Implementing a Different Security Level

PATROL Knowledge Module for Event Management User Guide

Typical and Custom Installation Types

Typical and Custom Installation Types