SPECTRUM Alarm Notification Manager (SANM) User...

SPECTRUM Alarm Notification Manager (SANM)

User GuideDocument 1308

NoticeCopyright Notice Copyright © 2002-present by Aprisma Management Technologies, Inc. All rights reserved worldwide. Use, duplication, or disclosure by the United States government is subject to the restrictions set forth in DFARS 252.227-7013(c)(1)(ii) and FAR 52.227-19.

Liability Disclaimer Aprisma Management Technologies, Inc. (“Aprisma”) reserves the right to make changes in specifications and other information contained in this document without prior notice. In all cases, the reader should contact Aprisma to inquire if any changes have been made.

The hardware, firmware, or software described in this manual is subject to change without notice.

IN NO EVENT SHALL APRISMA, ITS EMPLOYEES, OFFICERS, DIRECTORS, AGENTS, OR AFFILIATES BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS) ARISING OUT OF OR RELATED TO THIS MANUAL OR THE INFORMATION CONTAINED IN IT, EVEN IF APRISMA HAS BEEN ADVISED OF, HAS KNOWN, OR SHOULD HAVE KNOWN, THE POSSIBILITY OF SUCH DAMAGES.

Trademark, Service Mark, and Logo Information SPECTRUM, IMT, and the SPECTRUM IMT/VNM logo are registered trademarks of Aprisma Management Technologies, Inc., or its affiliates. APRISMA, APRISMA MANAGEMENT TECHNOLOGIES, the APRISMA MANAGEMENT TECHNOLOGIES logo, MANAGE WHAT MATTERS, DCM, VNM, SpectroGRAPH, SpectroSERVER, Inductive Modeling Technology, Device Communications Manager, SPECTRUM Security Manager, and Virtual Network Machine are unregistered trademarks of Aprisma Management Technologies, Inc., or its affiliates. For a complete list of Aprisma trademarks, service marks, and trade names, go to:

http://www.aprisma.com/support/secure/manuals/trademark-list.htm

All referenced trademarks, service marks, and trade names identified in this document, whether registered or unregistered, are the intellectual property of their respective owners. No rights are granted by Aprisma Management Technologies, Inc., to use such marks, whether by implication, estoppel, or otherwise. If you have comments or concerns about trademark or copyright references, please send an e-mail to [email protected]; we will do our best to help.

Restricted Rights Notice (Applicable to licenses to the United States government only.)This software and/or user documentation is/are provided with RESTRICTED AND LIMITED RIGHTS. Use, duplication, or disclosure by the government is subject to restrictions as set forth in FAR 52.227-14 (June 1987) Alternate III(g)(3) (June 1987), FAR 52.227-19 (June 1987), or DFARS 52.227-7013(c)(1)(ii) (June 1988), and/or in similar or successor clauses in the FAR or DFARS, or in the DOD or NASA FAR Supplement, as applicable. Contractor/manufacturer is Aprisma Management Technologies, Inc. In the event the government seeks to obtain the software pursuant to standard commercial practice, this software agreement, instead of the noted regulatory clauses, shall control the terms of the government's license.

Virus Disclaimer Aprisma makes no representations or warranties to the effect that the licensed software is virus-free. Aprisma has tested its software with current virus-checking technologies. However, because no antivirus system is 100-percent effective, we strongly recommend that you write protect the licensed software and verify (with an antivirus system with which you have confidence) that the licensed software, prior to installation, is virus-free.

Contact Information Aprisma Management Technologies, Inc., 273 Corporate Drive, Portsmouth, NH 03801 USA

Phone: 603.334.2100U.S. toll-free: 877.468.1448Web site: http://www.aprisma.com

http://www.aprisma.com/support/secure/manuals/trademark-list.htm

http://www.aprisma.com

3

Contents

Preface .......................................................................................................................... 7

Chapter 1: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

The alarm-monitoring process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

AlarmNotifier and SANM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

AR System Gateway and SANM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Attention! and SANM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Chapter 2: Creating an Alarm Notification Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

The Policy Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Starting the Policy Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Creating a new policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Naming a policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Specifying filters for a policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Saving a policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Filter parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

SpectroSERVER Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Model Type Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Model Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Device Location / Device Organization / Device Topology . . . . . . . . . . . . . . . . . . . . . 20

IP Subnet/Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Inserting IP network, subnet addresses, or IP address ranges into the filter . . . . . . 20Editing IP Subnet/Range values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Deleting IP Subnet/Range Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Alarm Severity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Alarm Cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Device Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Alarm Age . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Notification Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

The Auto-Edit Parameter Values Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Printing a policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Chapter 3: Editing an Alarm Notification Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Editing filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Adding a new filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Duplicating a filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Deleting a filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Editing parameters within a filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 SPECTRUM Alarm Notification Manager (SANM) User Guide

Contents

Add another parameter to the filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Negate parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Make negative parameter values positive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Delete one or more parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Delete the parameter itself . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Edit alarm age . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Edit notification data entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Saving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapter 4: Associating Policies and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

The association process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

The role of the Default Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Associating a policy with an application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Adding application names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Deleting application names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Deleting policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 5: Scheduling Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

The Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Scheduling associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Editing scheduled association commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Editing tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Chapter 6: Monitoring SANM Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

SANM related events in the SPECTRUM Event Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

SANM related event codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Tracing policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Specifying tracing for a SANM-enabled application . . . . . . . . . . . . . . . . . . . . . . . . . . 45

The summary trace file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

The detailed trace file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Chapter 7: The SANM Resource File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Resource file parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Resource file backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Chapter 8: SANM and AlarmNotifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Enhancing AlarmNotifier with SANM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Starting SANM-enabled AlarmNotifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Alarm Management parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Generate Alarm Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Add Events To Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Receiving alarms from the cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Contents

SPECTRUM Alarm Notification Manager (SANM) User Guide 5

Acknowledging alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Clearing alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

SANM-enable script parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

E-mail notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Sending data to a third-party application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

SANM-enabled .alarmrc parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Chapter 9: SANM and SPECTRUM’s AR System Gateway . . . . . . . . . . . . . . . . . . . . . . . 61

Enhancing AR System Gateway with SANM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Starting the AR System Gateway Automatic Trouble Ticket Generator . . . . . . . . . . . . . . . 62

SANM-enabled resource file parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Trouble ticket form field options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Chapter 10: Using SANM in a Distributed SpectroSERVER Environment . . . . . . . . . . . 65

Managing SANM policies across multiple landscapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Creating SANM policies on many landscapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Creating SANM policies on one landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Determining the landscapes that are currently monitored . . . . . . . . . . . . . . . . . . . . . . . . 67

Index 69


Contents

7

Preface

This guide is intended for users who are working with SPECTRUM’s Alarm Notification Manager.

What is in this book

This guide contains the following chapters:

• Chapter 1: Overview - This chapter provides an introduction to SPECTRUM’s Alarm Notification Manager.

• Chapter 2: Creating an Alarm Notification Policy - This chapter describes how to create alarm notification policies with the SANM Policy Administrator.

• Chapter 3: Editing an Alarm Notification Policy - This chapter describes how to edit an existing alarm filtering policy using the SANM policy administrator.

• Chapter 4: Associating Policies and Applications - This chapter describes how to associate alarm notification policies with alarm processing applications and how to manage associations.

• Chapter 5: Scheduling Associations - This chapter describes how to schedule associations between alarm notification policies and SANM-compatible applications using the SANM Policy Administrator Scheduler.

• Chapter 6: Monitoring SANM Processes - This chapter describes how to track SANM events using the SPECTRUM Event Log and trace files.

• Chapter 7: The SANM Resource File - This chapter describes each of the parameters in SANM’s resource file.

• Chapter 8: SANM and AlarmNotifier - This chapter describes how AlarmNotifier and SANM operate together.

• Chapter 9: SANM and SPECTRUM’s AR System Gateway - This chapter describes the increased functionality and policy-based alarm filtering capabilities of SANM when teamed with the SANM-enabled AR System Gateway.

• Chapter 10: Using SANM in a Distributed SpectroSERVER Environment - This chapter describes how SANM operates in a distributed SpectroSERVER environment.


Preface

Text Conventions

The following text conventions are used in this document:

Document Feedback

Please send feedback regarding SPECTRUM documents to the following e-mail address:

[email protected]

Thank you for helping us improve our documentation.

Online Documents

SPECTRUM documents are available online at:

http://www.aprisma.com/manuals

Check this site for the latest updates and additions.

Element Convention Used Example

Variables

(The user supplies a value for the variable.)

Courier and Italic in angle brackets (<>)

Type the following:

DISPLAY=<workstation name>:0.0 export display

The directory where you installed SPECTRUM

(The user supplies a value for the variable.)

<$SPECROOT> Navigate to:

<$SPECROOT>/app-defaults

Solaris and Windows directory paths

Unless otherwise noted, directory paths are common to both operating systems, with the exception that slashes (/) should be used in Solaris paths, and backslashes (\) should be used in Windows paths.

<$SPECROOT>/app-defaults on Solaris is equivalent to <$SPECROOT>\app-defaults on Windows.

On-screen text Courier The following line displays:

path=”/audit”

User-typed text Courier Type the following path name:

C:\ABC\lib\db

Cross-references Underlined and hypertext-blue

See “Document Feedback” on page 8.

References to SPECTRUM documents (title and number)

Italic SPECTRUM Installation Guide (0675)

mailto:[email protected]

http://www.aprisma.com/manuals

9

Chapter 1: Overview

SPECTRUM Alarm Notification Manager (SANM) enhances the functionality of SPECTRUM’s alarm processing applications, including AlarmNotifier, the AR System Gateway, and Attention!. These applications respond in various ways (e-mail notifications, trouble tickets, etc.) to alarms generated by SPECTRUM. SANM’s Policy Administrator, an alarm filter configuration tool, enables you to specify and associate alarm notification policies with applications. A policy enables you to specify the types of alarms you want an alarm-processing application to receive and to filter out the alarms that you consider unimportant.

The alarm-monitoring processThe following sections describe how SPECTRUM, alarm-processing applications, and SANM work together in the alarm-monitoring process.

Figure 1-1: Alarm-Monitoring Process

SPECTRUM polls the network elements modeled in SPECTRUM, updating the information stored about the status of each element in the SpectroSERVER database.

Alarms

SANM

Alarms

Policy Administrator

Filtered

FilteringSchedulingAssociating

AlarmNotifier

SpectroSERVER

Database

SpectroSERVER

Database SpectroSERVER

Database

DistributedSpectroSERVERS

AR System Gateway Attention!


Chapter 1: Overview

SPECTRUM generates an alarm based on a trap received from the network or when it detects a critical status change in a network-element model. In SpectroGRAPH, the model icon’s condition panel changes from green to another color that indicates the relative severity level of the alarm. SPECTRUM posts information about the alarm in the Enterprise Alarm Manager window and the event information for the alarm in the Event Log window.

Data about alarms that SPECTRUM has generated is passed along to SANM. SANM’s Policy Administrator lets you create and associate alarm notification policies with alarm-processing applications. In addition, SANM’s Policy Administrator Scheduler automates the association process by enabling you to schedule application and policy associations.

SANM passes the alarm information to alarm-processing applications only when the types of alarms specified in the policies occur. SANM provides additional alarm-management commands and adds to the feature set included with each particular alarm processing application.

AlarmNotifier and SANM

Alarms filtered by SANM can be sent to SPECTRUM’s AlarmNotifier application. When both of these applications are installed, AlarmNotifer gains some additional capabilities:

• SANM’s alarm-filtering policies can be applied to individual instances of AlarmNotifer. These filtering policies allow you to limit alarm notifications to only those alarms based on the criteria in the filter.

• AlarmNotifier can generate notifications for alarms from all landscapes in a distributed SpectroSERVER environment.

• Additional commands are available that allow you to acknowledge and clear alarms from AlarmNotifier.

• An additional startup command allows you to start multiple instances of AlarmNotifier which can be associated with a different SANM alarm notification policy.

• Additional startup commands allow you to create summary or detailed trace files.

• AlarmNotifer scripts have additional parameters that contain information about troubleshooting alarms.

• The AlarmNotifier resource file has additional parameters which allow you to obtain further information about alarms.

• You can use SANM to automatically associate a different policy with AlarmNotifier at a specified time.

Instructions on each of these enhancements can be found in the section on “SANM and AlarmNotifier” on page 51.

The alarm-monitoring process


AR System Gateway and SANM

Alarms filtered by SANM can be sent through the AR System Gateway to a Remedy Troubleticketing system. Using SANM provides the AR System Gateway with some enhanced capabilities:

• SANM’s alarm-filtering policies can be applied to the alarms sent to the ARS Gateway. These filtering policies are more advanced than the ARS Gateways’ base-level filtering capabilities.

• In a SANM-enabled environment with a single SpectroSERVER, all network information is collected and filtered through SANM’s Policy Administrator. This feature provides greater control over network alarm filtering and the ability to provide more information in the SPECTRUM Trouble Ticket.

• The SANM-enabled AR System Gateway with multiple SpectroSERVER capability has the ability to monitor alarms from multiple SpectroSERVERs. In a distributed environment, SANM enables the user to monitor alarms from multiple SpectroSERVERS using a single AR System Gateway process.

For more information on these enhancements, see “SANM and SPECTRUM’s AR System Gateway” on page 61.

Attention! and SANM

Attention! is a client/server network monitoring and notification system. The tool alerts system managers of critical system and network events via alphanumeric or numeric pagers, telephone, e-mail, PA announcements, electronic message boards, as well as custom notification techniques. SANM can be used as a foundation for an integration between SPECTRUM and Attention!. For more information about Attention!, refer to http://attentionsoftware.com.

http://attentionsoftware.com


Chapter 1: Overview

13

Chapter 2: Creating an Alarm Notification Policy

This chapter describes how to create alarm notification policies with the SANM Policy Administrator.

In this chapter

• “The Policy Administrator” on page 13

• “Starting the Policy Administrator” on page 14

• “Creating a new policy” on page 14

• “Filter parameters” on page 19

• “Printing a policy” on page 26

The Policy Administrator SANM’s Policy Administrator is a configuration tool that enables you to create, save, and implement alarm notification filtering policies. A policy allows you to filter the SPECTRUM alarms that are sent to one or more of the alarm processing applications.

Each policy must specify at least one filter. The filter criteria is based on one or more parameters, which include: SpectroSERVER Host, Landscape, Model Type Name, Model Name, Device Location, IP Subnet, Alarm Severity, and Alarm Cause.

You can also specify an aging interval for an alarm specified in a policy filter. The Alarm Age parameter value is the length of time an alarm must exist before SANM allows notification of the alarm to the SANM-compatible application associated with a policy.

Comments or the names of e-mail recipients can also be included with each alarm by using the Notification Data parameter.

After you create a policy, you associate it with one or more alarm processing applications. SANM then enforces that policy on all alarms and allows the application(s) access only to those alarms that meet the policy criteria.



Note: The information displayed in the Policy Administrator is always current. SANM dynamically updates the information in this window whenever you install and run new SANM-enabled applications, create, delete, or associate policies, or add new application names to the Applications section.

Starting the Policy AdministratorYou can open the Policy Administrator via the command line or from SpectroGRAPH.

To open the Policy Administrator via the command line:

1. From a terminal window (Solaris) or bash shell (Windows NT/2000), navigate to the <$SPECROOT>/SANM directory.

2. Start up the Policy Administrator in one of the following ways:

• If you want to use the default resource file, .sanmrc, enter:

./PolicyAdmin

• If you want to use a modified version of the default resource file, enter:

./PolicyAdmin -r <resource file>(See “The SANM Resource File” on page 49 for information about the .sanmrc resource file.)

To open the Policy Administrator Window from SpectroGRAPH:

1. Select the SANM Policy Administrator option from the Tools menu.

Creating a new policy

There are three main tasks involved in creating a new policy:

1. “Naming a policy” on page 14.

2. “Specifying filters for a policy” on page 15.

3. “Saving a policy” on page 19.

Naming a policy

To name a new policy, see Figure 2-1 on page 15 and follow these steps:

1. Type the name of the new policy in the text box next to the New Policy button.

2. Click the New Policy button.

It is recommend that you assign a policy name which suggests when and under what circumstances the policy is used (e.g., ciscoRtrPM). This will make it easy to select and implement policies from a collection of saved policies.



Figure 2-1: Naming a New Policy

The new policy name appears in the Alarm Notification Policies section, and the Open Policy window (Figure 2-2 on page 16) opens.

Specifying filters for a policy

You can define one or more filters (maximum of 100) for a policy. A policy requires at least one filter. A filter can include one or more parameters, and each parameter can include one or more parameter values.

To specify filters, see Figure 2-2 on page 16 and follow these steps:

1. Click the Create button in the Open Policy window. A filter box labeled Filter 1 appears.

You can make a copy of any existing filter in this policy by clicking on the filter to highlight it and clicking on the Duplicate button. The duplicate filter can then be modified. This is useful if you would like to create a filter that is similar to one that has already been created.

2. Click the Parameter button in Filter 1 to show the list of parameters that you can include in that filter.

1 2



Figure 2-2: Specifying Filters in the Open Policy Window

3. Select a parameter from the Parameter list (Figure 2-3 on page 17). For more information on each parameter, see “Filter parameters” on page 19.

An Add Filter Values dialog box for the parameter opens.

Note: As a general rule, select more inclusive parameters before less inclusive parameters. Parameters are listed in descending order of inclusiveness (i.e., SpectroSERVER Host... Model Type Name... Alarm Severity). If you choose a less inclusive parameter first, you will not be able to select certain more inclusive parameters.

For example, if you first specify the Location parameter, World, which is one of the default location views modeled in all SpectroSERVERS, you will not be able to then select a particular SpectroSERVER or Landscape parameter. Because you have specified that you want notification of alarms from all World locations, you have precluded selecting a particular SpectroSERVER or Landscape providing a world view of a particular network or network segment.

4. The Add Filter Values dialog box allows you to choose one or more values for the parameter. To insert a parameter value into the filter, use either of the following methods:

• Click the OK button to insert values in the filter and close the dialog box.

• Click the Apply button to insert the values in the filter and leave the dialog box open for more selections. Then click the OK or Cancel button to close the dialog box after you have finished applying values to the filter.

To locate a value from a lengthy list, you can use the Search field in the Add Filter Values dialog box.

1

2

Policy Name



To filter out values except those which contain specific characters, you can click the Search button to toggle to the Filter button. Then type the characters in the Add Filter Values dialog box. Only values which contain those characters appear in the list. The Filter function is not case-sensitive.

Note: In the Windows environment, the Policy Administrator allows a maximum of 32,767 model names to be displayed in the Add Filter Values view. If you filter only on model names, and the resulting list exceeds 32,767 models, the application shuts down.

Solution: To reduce the number of models within a list, filter models by model type or landscape first, and then filter by model name.

Figure 2-3: Selecting Parameters for a Filter

Note: The parameter-selection procedures in this section are described based on the assumption that the Auto-Edit Parameters Values option in the Options menu is ON, the default setting. If you turn Auto-Edit OFF, the parameter selection process will differ slightly. See “The Auto-Edit Parameter Values Option” on page 25 for more information.

5. Continue to select parameters and parameter values until you have added all the necessary parameters to your filter.

Multiple values can be selected by pressing the Control key, then selecting individual values. Each selected value will be highlighted for inclusion.

The IP Subnet and Alarm Cause parameters require special considerations. If you are adding these parameters, see “IP Subnet/Range” on page 20 and “Alarm Cause” on page 22 for more information.

6. Specify the Alarm Age (optional) using the increment and decrement arrow buttons in the Age field (Figure 2-4 on page 18).

You can specify an alarm age from 0 hours to 23 hours, 59 minutes. An alarm age of 0 means that the alarm notification is forwarded immediately. See “Alarm Age” on page 23 for more information.

34



7. Specify the Notification Data (optional) for this filter (Figure 2-4: Specifying Alarm Age and Notification Data Parameters).

You can customize the information in this field for each application. If an alarm passes a filter, SANM sends the Notification Data from that filter to the application. If multiple filters pass the alarm, the application will receive a series of Notification Data entries in a string. See “Notification Data” on page 23 for more information.

Figure 2-4: Specifying Alarm Age and Notification Data Parameters

8. Repeat Steps 1-7 to create additional filters.

Figure 2-5 shows an example policy with multiple filters.

Figure 2-5: Sample Policy

67

Filter parameters


Saving a policy

Saved policies are listed in the Policy Administrator window’s Alarm Notification Policy section.

To save a policy:

1. Select the Save or Save As option from the File menu (Figure 2-6 on page 19).

Figure 2-6: Saving a Policy

The Save As dialog box (Figure 2-7 on page 19) opens if you select the Save As option. Type the name of the policy in the Enter Policy Name field, and then click the OK button.

Figure 2-7: Save As Dialog Box

2. Close the Open Policy window by selecting the Close option from the File menu.

The saved policy is listed in the Policy Administrator window’s Alarm Notification Policies section. You can now associate the policy with one or more applications.

Filter parametersWhen creating a filter, there are several different parameters that can be used as filtering criteria. Each of these parameters is explained below.

SpectroSERVER Host

This parameter allows you to specify the SpectroSERVER host(s) on which the alarm must be generated in order for SANM to pass the alarm to the alarm processing application.

Landscape

This parameter allows you to specify the landscape(s) on which the alarm must be generated in order for SANM to pass the alarm to the alarm processing application.

1

2

Policy names must be unique. If you enter a duplicate name, an error message appears.



Model Type Name

This parameter allows you to specify the model type name(s) for which the alarm must be generated in order for SANM to pass the alarm to the alarm processing application.

Model Name

This parameter allows you to specify the model names for which the alarm must be generated in order for SANM to pass the alarm to the alarm processing application.

Device Location / Device Organization / Device Topology

These parameters allow you to filter alarms based on where the device is located in the Location, Organization, or Topology view when the alarm is created.

These parameters use the following model attributes for the filter criteria:

• Device Location: LocationModelNameString 0x129e9

• Device Organization: OrganizationModelNameString 0x129e8

• Device Topology: TopologyModelNameString 0x129e7

If the string used for the filter criteria is contained in the value of the model attribute, then the filter criteria has been met. For example, if you have three containers named “Backbone”, “Engineering Backbone”, and “Sales Backbone”, and you filter on “Backbone” you will get all three containers, because “Backbone” is found in all three container names.

The attribute values are computed at alarm creation time, so if an alarm is generated, and then the model is moved to where it now meets the criteria of the filter, the alarm will not be passed to the alarm processing application.

IP Subnet/Range

The IP Subnet/Range parameter allows you to specify an IP network address, an IP subnet address, or a range of IP addresses within a subnet. The alarm must be generated within the specified network, subnet, or IP address range in order for SANM to pass the alarm to the alarm processing application.

Inserting IP network, subnet addresses, or IP address ranges into the filter

To insert values:

1. Type the value in the text field using one of the following formats:

• IP network address (Class A, B, or C)

- x.0.0.0 for a Class A network (x = 1 – 127)

- x.y.0.0 for a Class B network (x = 128 – 191)

- x.y.z.0 for a Class C network (x = 192 – 223)

• IP Subnet address

- x.y.z (e. g., 134.148.10)

- x.y.z.0 (e. g., 134.148.10.0)

Filter parameters


• IP Address Range

- x.y.z.a - x.y.z.m (e.g., 134.148.10.55 - 134.148.10.72)

2. Insert the value(s) into the IP Subnet/Range list using either of the methods described in “Specifying filters for a policy” on page 15.

Note: If you do not enter the IP address value(s) in the correct format, an error message box displaying the correct format opens.

Editing IP Subnet/Range values

You can edit IP Subnet/Range values included in the IP Selection list before you close the Add Filter Values dialog box. Once the dialog box has been closed, the values cannot be edited, it must be deleted and a new one inserted into the filter.

To edit a value:

1. Select the value in the Add Filter Values dialog box.

The value appears in the text field. The Update button is enabled once you make any change to the existing value.

2. Modify the value in the text field, and then click the Update button.

This replaces the old value in the IP Subnet/Range list above with the edited value. (If you click the Add button at this point, the new value is added to the list along with the old value rather than replacing the old value.)

3. Insert the new value into the filter by clicking Apply to continue editing other values or by clicking the OK button to close the box.

Deleting IP Subnet/Range Values

You can delete IP Subnet/Range values in the Add Filter Values dialog box and in the Open Policy window.

Add Filter Value Dialog Box

You can delete a value in the Add Filter Values dialog box list any time you are working with the box. The delete operation does not remove values you have previously added to IP Subnet/Range list in the Open Policy window with the Apply button. It removes instead values you have added to the IP Subnet/Range Selection list in the Add Filter Values dialog box.

To delete an IP Subnet/Range value in the Add Filter Values dialog box:

1. Select the value you want to delete.

2. Click the Delete button.

The value disappears from the Subnet/Range Selection list in the Add Filter Values dialog box (but not from the IP Subnet list in the Open Policy window).

Deleting values in the Open Policy window

The values you delete from the IP Subnet/Range list in the Open Policy window are removed from the filter for the policy.



To delete a value:

1. Select the IP Subnet/Range value you want to delete from IP Subnet/Range list in the Open Policy window.

2. Click Delete in the Parameter Operations section.

The value disappears from the IP Subnet/Range list.

Alarm Severity

This parameter allows you to specify the alarm severity that the alarm must have in order for SANM to pass the alarm to the alarm processing application.

Alarm Cause

The Alarm Cause parameter allows you specify the alarm probable cause ID(s) that the alarm must have in order for SANM to pass the alarm to the alarm processing application. When you select an ID, the description of the probable cause associated with the ID appears in the adjacent text section.

Figure 2-8: Alarm Cause Selection

You can search for or filter on Alarm Causes using the Search/Filter button shown in Figure 2-8 on page 22. To toggle between searching and filtering, click on the button and select the appropriate option. Type the search or filter criteria in the text box next to the Search/Filter button. The Next button allows you to move to the next Alarm Cause in the list.

When you select multiple IDs, the text related to the most recently selected ID is displayed.

Search/Filter

Filter parameters


Device Type

This parameter allows you to specify the device types for which the alarm must be generated in order for SANM to pass the alarm to the alarm processing application. For information on assigning a device type value to a model via the Device Type Identification application, see the Modeling with GnSNMPDev Toolkit (1316) guide.

Alarm Age

The Alarm Age parameter for a policy filter specifies the time an alarm must exist before the alarm notification is passed to the application that is associated with the policy. Some alarms do not require attention because they are cleared within minutes, and thus can be filtered out using the Alarm Age parameter. Figure 2-9 on page 23 shows an example of a filter with an alarm age of 5 minutes.

If you have a policy with multiple filters with different Alarm Age values, the Policy Administrator uses the minimum value. For example, if a policy contains two filters—one with an Alarm Age of 5 minutes and the other with an Alarm Age of 10 minutes—and the alarm passes both filters, SANM will let the alarm age for 5 minutes before notifying the application.

Existing alarms are aged from the time SPECTRUM generates the alarm (specified by the timestamp for the alarm). For example, if an existing alarm is 3 minutes old when you start a SANM-enabled application that is able to receive the alarm and the filter in the policy with which the application is associated specifies a 5 minute alarm age, SANM lets the alarm age 2 minutes before notifying the application.

Figure 2-9: Alarm Age Section of the Filter

Note: Synchronize the times on all SpectroSERVERs in a SANM-enhanced distributed SpectroSERVER environment to ensure precise aging.

Notification Data

The Notification Data parameter is an application-specific parameter. The type of data you provide it may vary, depending on how the SANM-enabled application uses the Notification Data. You can use the information in this parameter for passing along information that may assist you in debugging policies, for notifying troubleshooting personnel about alarms, or for other application-specific purposes. The user’s guide for each SANM-enabled application suggests ways to use this parameter.

It is important to understand that SANM sends a filter’s Notification Data to the application only if an alarm passes that particular filter. If the policy contains several filters that pass the alarm,

Alarm

Click increment arrowsto increase interval.

Click decrement arrowsto decrease interval.



SANM concatenates the Notification Data string from these filters, separating each string with a colon (:). The data from the first filter that passes the alarm appears first in the string, the second filter appears next, and so on.

SANM passes the concatenated strings as an entire string to an application. The application then displays the entire string as a single Notification Data parameter. What begins as several strings of data from the various filters ends up as a single string of data in the SANM-enabled application.

To illustrate the process, let us assume that you create a policy consisting of three filters that include the following Notification Data information:

Filter1 Notification Data — Adams or WashingtonFilter2 Notification Data — Roosevelt, CarterFilter3 Notification Data — Clinton, Kennedy or Nixon

If an alarm passes Filter1 and Filter3 of the policy, SANM would send the following string to the application for the application’s Notification Data parameter:

Entering information in the Notification Data parameter:

1. Click the User icon on the filter panel in the Open Policy window.

A User Selection dialog box (Figure 2-10 on page 25) opens. It lists authorized SPECTRUM users (user models created in the SpectroSERVERS that SANM monitors) and their e-mail addresses.

2. Select the names or e-mail addresses from the user list that you want forwarded to the SANM-enabled application. To select a name, click USER. To select an e-mail address, click EMAIL.

If you select multiple names or e-mail addresses, insert a separator between each. To do this, either click the or button or the and (,) button or type the separator (“or” or “,”) directly in the text field. (The program will not let you choose another name from the user list until you first insert a separator.) SANM does not interpret the separators in any special way. It just passes the separators to the application.

Note: If you change an e-mail address in the SPECTRUM User Editor, this change does not propagate to SANM policies that already use the e-mail component of the Notification Data parameter. You must manually update the policy to make this change.

3. Type directly in the text field if you want to insert a comment or other information that the application could use.

4. Click the OK button to insert the information in your filter and close the User Selection dialog box.

Adams or Washington : Clinton, Kennedy or Nixon

Filter 1 Filter 3

Filter parameters


Figure 2-10: Selecting User Names for Notification Data

Note: The Policy Administrator does not check if Notification Data entries are valid. When entering names or e-mail addresses of SPECTRUM users, be sure to type them exactly as they appear listed in the SPECTRUM User Editor.

The Auto-Edit Parameter Values Option

The Auto-Edit Parameter Values option (Figure 2-11 on page 25) from the Open Policy window’s Options menu enables you to control the order in which you insert parameters and parameter values into the filter.

Figure 2-11: Auto-Edit Parameter

When Auto_Edit Parameter Values is enabled, parameter selection works this way:

• When you select one parameter in the Parameter list, the Add Filter Values dialog box for that parameter opens.

• Then you select the desired values for that parameter and insert them into the filter.

• You repeat this process (selecting one parameter and then its values in the Add Filter Values dialog box) until the filter is completed.



When Auto_Edit Parameter Values is disabled, parameter selection works this way:

• The Policy Administrator allows you to select the parameters from the Parameter list all at once. Notice that the Add Filter Values dialog box does not automatically appear when you select a parameter.

• As you click each parameter, an empty parameter box appears in the filter.

• After the parameter boxes are inserted in the filter, you click the parameter name at the top of the parameter box to bring up that parameter’s Add Filter Values dialog box.

• Then you select the desired values for that parameter and insert them into the filter.

• You continue by clicking on each parameter name at the top of the empty parameter box to bring up the Add Filter Values dialog box for that parameter until the filter is completed.

Printing a policyYou can print the information related to a specific policy to a text file. The information printed to the text file includes the policy name, landscape information, and filter information. Follow these steps to print a policy to a text file:

1. From the Policy Administration window, select the policy you want to print from the Alarm Notification Policies list.

2. Click the Open Policy button to display the Open Policy window for the selected policy.

3. Choose the File > Print to File command.

4. Type the name of a new text file or choose an existing text file in the Select a Destination File dialog box.

5. Click the Open button. Once SPECTRUM has completed the print to file operation, a message appears indicating that the policy has been printed.

27

Chapter 3: Editing an Alarm Notification Policy

This chapter describes how to edit an existing alarm filtering policy using the SANM policy administrator.

In this chapter

• “Editing filters” on page 27

• “Editing parameters within a filter” on page 28

• “Saving” on page 29

Editing filtersTo edit an existing filter, you must enable the Filter Operations buttons as shown in Figure 3-1 below. Once these buttons are enabled, you can add a new filter, duplicate a filter, or delete a filter.

Figure 3-1: Enabling Filter EditingTo edit a filter, click in the Filter box background. This enables the Filter Operations buttons.



Adding a new filter

To create the first filter in a policy, click the Create button.

To insert additional filters to an existing policy, select a filter’s background area to enable filter operations, and then click the Create button. A new filter appears in the window.

Duplicating a filter

Select the filter, and click the Duplicate button. The duplicate filter appears in the window.

Deleting a filter

Select the filter you want to delete, and then click the Delete button.

Editing parameters within a filterTo edit an existing parameter with a filter, you must enable the Parameter Operations buttons as shown in Figure 3-2 below.

Figure 3-2: Enabling Parameter Editing

Add another parameter to the filter

Click the Parameter button and select another parameter. If the parameter is grayed-out, you cannot include it in the filter. The Policy Administrator does not allow incompatible parameter values in the same filter. You must create a new filter if you need the unavailable parameter or delete the parameter that is blocking it.

To edit a parameter, click on one of the parameter values in the list box. This enables the Parameter Operations buttons.

Saving


Negate parameter values

Select a parameter value and click the Negate button. Notice that the Policy Administrator negates all the values listed under the parameter. You cannot have positive and negative values within the same parameter.

Make negative parameter values positive

Select a negative parameter value and click the Negate button. Notice that the Policy Administrator makes all the negative values listed under the parameter positive. You cannot have positive and negative values within the same parameter.

Delete one or more parameter values

Select one or more values in a parameter, and then click Delete in the Parameter Operations section. Deleting all parameter values deletes the parameter.

Delete the parameter itself

Select one or more values in a parameter, Click Select All and then the Delete button in the Parameter Operations section. When you delete all the values in the parameter box, you delete the parameter itself.

Edit alarm age

Use the increment and decrement buttons to specify a new Alarm Age value.

Edit notification data entries

In either the Open Policy window or the User Selection dialog box, click the cursor in the Notification Data text field and then delete or add text as desired. If the complete entry is not visible, click the cursor in the text and then use the arrow keys from the keyboard to scroll the text into view. You can also select User Names and separators from the User Selection dialog box.

SavingYou can edit a policy before or after you save it, regardless of whether or not it is associated with an application. If the policy is associated with an application, SANM begins enforcing the new policy as soon as you save your changes.

Important: The Archive Manager must be running and successfully connected to the SpectroSERVER for modified policies to take immediate effect.

31

Chapter 4: Associating Policies and Applications

This chapter describes how to associate alarm notification policies with alarm processing applications and how to manage associations.

In this chapter

• “The association process” on page 31

• “The role of the Default Policy” on page 32

• “Associating a policy with an application” on page 32

• “Adding application names” on page 34

• “Deleting application names” on page 35

• “Deleting policies” on page 35

After you create an alarm notification policy, you can associate the policy with one or more alarm processing applications. An association between a policy and an application remains in effect until you associate another policy with that application or delete the associated policy.

Before you begin associating policies with applications, read the sections “The association process” on page 31 and “The role of the Default Policy” on page 32, to understand exactly how the association process works, and the Default Policy’s role in that process.

The association processYou can associate policies with any application listed in the Policy Administrator window’s Applications section.

Although you can associate a single policy with multiple applications, each application can be associated with only one policy at a time. SANM enforces only one policy at a time on the application. If you want a particular application to process different alarms, you must associate another policy with the application. You can do this manually at the time you want to implement the new policy, or you can use the Scheduler to schedule the new association automatically at the time and date you specify.



To run the same application with different policies, you have to start multiple instances of the application, each with a unique name, and then associate the different policies with them. For example, the Policy Administrator recognizes AlarmNotifier1 and AlarmNotifier2 as different applications. Once you create unique names for the application, you can associate a unique policy with each instance of the application.

To change the policy an application is associated with, you associate the Default Policy or another policy with the application. If you delete the policy instead, SANM associates the Default Policy with the application.

If you edit a policy that is associated with multiple applications, you change the policy for all applications with which it is associated. You do not have to reassociate the policy with the applications.

The role of the Default PolicySANM associates the Default Policy with an application whenever you start up a SANM-enabled application the first time or if a policy that was associated with an application is deleted. You can also explicitly associate the Default Policy with an application at any time.

When you first install SANM and run SANM-enabled applications, SANM associates a Default Policy with the applications. This initial Default Policy is a null policy; it does not filter alarms or carry out any of the other aspects of a policy. In other words, alarm processing applications associated with the Default Policy receive information about every alarm that occurs on every landscape in the landscape map in the SpectroSERVER to which SANM is connected.

SANM does allow you to modify the initial Default Policy so that it is no longer a null policy. Even though you can edit the policy, it is still associated by default with applications that are not associated with other policies.

Before you delete policies, check to see if the Default Policy has been modified to include filters. The Policy Administrator does warn you that the policy you are deleting is currently associated with one or more applications. It does not, however, warn you that the Default Policy has been modified.

If you do not want the Default Policy associated with an application, you should associate a different policy with the application before deleting the policy that is currently in effect.

The Default Policy cannot be deleted, it can only be modified.

Associating a policy with an applicationYou can associate policies with applications before or after the applications have been started (or even installed). To associate a policy with an application, see Figure 4-1 on page 33 and follow these steps:

1. Select an application from the Policy Administrator window’s Applications section list. Applications that have not been started since SANM was installed are not listed in the Applications section. See “Adding application names” on page 34 for information about adding application names to the Policy Administrator before they are started.

Associating a policy with an application


2. Select the policy you want to associate with the application you selected from the Policy Administrator window’s Alarm Notification Policies section list.

3. Click the Associate button.

The application and the policy appear in the Associated Policies section at the top of the window. This policy remains in effect for the application until you either associate another policy with the application or you delete this policy and SANM associates the Default Policy with the application.

Figure 4-1: Associating a Policy with an Application

12

3

Default AssociationListed Here

New AssociationListed Here



Adding application namesIf you want to associate a policy with an application before SANM has knowledge of the application’s presence on the system where SANM is installed then you must add an application name to the application list. If SANM is installed on a system and the application has not been started on that system, then SANM will not have any knowledge of its presence, and the application will not be listed.

After you manually add the application name to the Applications section list, you can associate a policy with it, and the policy will take effect for the application when it is started.

To add an application name to the Applications section list, see Figure 4-2 on page 34 and follow these steps:

1. Type an application name in the text box next to the Add Application button.

2. Click the Add Application button.

The application name you specified appears in the Applications section list.

Figure 4-2: Naming a New Application

21

New ApplicationListed Here

Deleting application names


Deleting application namesIf you want to remove an entry listing an application you are no longer using:

1. Select the application name you want to delete from the Policy Administrator window’s Applications section list.

2. Click the Delete button on your keyboard.

The application name is removed from the Applications section list.

If the application is associated with a policy, the application and the policy with which it is associated are removed from the Associated Policies section list as well.

Note: When the application is running and you delete the application name from the Policy Administrator, the policy with which the application is associated remains in effect for the application until you shut down the application. When you restart the application, the application name reappears in the Applications section list and is associated with the Default Policy and the Associated Policies section list.

Deleting policiesTo delete a policy, follow these steps:

1. Select the policy name you want to delete from the Policy Administrator window’s Alarm Notification Policies section list.

2. Click the Delete button on your keyboard.

If the policy is not associated with an application, the policy is removed from the Alarm Notification Policies section list. If the policy is associated with an application, SANM also deletes the policy from the Associated Policies section list and associates the Default Policy with the application.

Note: Remember that the Default Policy may or may not be a null policy, depending on whether you or other users have modified it. Be sure to check if the Default Policy has been modified before you delete policies that are associated with an application.

37

Chapter 5: Scheduling Associations

This chapter describes how to schedule associations between alarm notification policies and SANM-compatible applications using the SANM Policy Administrator Scheduler.

In this chapter

• “The Scheduler” on page 37

• “Scheduling associations” on page 38

• “Editing scheduled association commands” on page 41

The SchedulerThe Scheduler automates the association process, enabling you to implement the alarm notification policies you want whenever you want. For example, if you want an application to take action in response to a particular type of an alarm during the evening, you might create a special evening policy and schedule the association of this policy with your particular application for 6 PM daily. You could also schedule the association of a different daytime policy with the same application for 7 AM daily. The Scheduler performs the associations at the specified times. Without the Scheduler, you would have to manually associate a new policy every time you wanted to filter alarms in a different way.

You can view the results of any operation performed by the Scheduler in the SPECTRUM Event Log. “Monitoring SANM Processes” on page 43 describes the Event Log and other methods available for monitoring the implementation of alarm notification policies.

Note: Windows Considerations — Before using the Scheduler, Windows users should make sure that the Task Scheduler Service is setup properly. See the SPECTRUM Installation Guide (0675) for information on setting up the Windows Task Scheduler service.



Scheduling associationsSee Figure 5-1 and follow these steps to access the Scheduler:

1. Select an application in the Policy Administrator window’s Applications section.

Do not select the policy that you are going to associate with the application at this point. You do this from the Scheduler window.

2. Click the Schedule Association button.

The window lists pending scheduled associations. Notice that some buttons in the Scheduler window are disabled when you first open it and later when you are working within it. A disabled button indicates that its corresponding option is not available at that particular time for the operation you are performing.

3. Click the Associate button in the Scheduler window.

The Modify Association dialog box (Figure 5-1 on page 38) opens.

Figure 5-1: Modify Association Dialog Box

4. Select the policy listed in the Modify Association box to associate with the application you selected in the Policy Administrator window before you invoked the Scheduler.

5. Click the OK button to close the Modify Association dialog box.

The Command field now indicates the association you just specified. You should see an association command string that looks like this:

Directory/SANM/associate -p “A-Policy” -a “AlarmNotifier” -ph 0x2200027 -ah 0x2200444

The Scheduled Entries list remains empty until you specify when you want the association to occur.

1

3

2

Scheduling associations


6. Select a Frequency option, Hourly (Solaris only), Daily, Once (the default option), Weekly, or Monthly.

The Frequency section displays the configuration box for the frequency option (Figure 5-2 on page 40) you selected.

7. Specify the time and date or both for the selected frequency option.

• The Once option allows you to specify the month, day, and starting time of a single operation. On Solaris you can schedule the association on any day between the current date and one year later. On Windows NT/2000 you can schedule the association on any day between the current date and one month later.

• The Hourly option allows you to specify the minutes after the hour to schedule an association each hour. You can schedule the association to occur at any point from the beginning of each hour (00) to 59 minutes after the hour. (Not available for Windows NT/2000 users.)

• The Daily option allows you to specify the time of day (hour:minute) you want to schedule an association each day.

• The Weekly option allows you to specify the day of the week and the time of day you want to schedule an association each week.

• The Monthly option allows you to specify the day of the month and the time of day you to schedule an association each month.



Figure 5-2: Frequency Options: Hourly, Daily, Once, Weekly, Monthly

1. Click the Add button to insert the scheduled association command to the Scheduled Entries list.

2. The entry appears in the list (Figure 5-3 on page 41).

3. Click the Save button to send the entry or entries to the scheduled operations queue on your system (crontabs directory for Solaris, Schedule service for Windows NT/2000) when you are finished.

5

Frequency Section

4

Editing scheduled association commands


4. Click the Close button to close the Scheduler window.

Note: You must open a new Scheduler window each time you want to schedule an association between a particular application and a policy.

Figure 5-3: Adding and Saving the Scheduled Association

Editing scheduled association commandsYou can edit a scheduled association command entry in the following ways:

• Change the policy and the frequency option specified in the entry before or after you save it.

• Delete an entry before or after you save it.

A scheduled entry consists of two parts, the scheduled time at the beginning of the line followed by the command specification, which is enclosed in quotes. Policies and applications are identified by their names and their model handles. Figure 5-4 shows the parts of a Scheduled Entry.

Figure 5-4: Parts of a Scheduled Entry

To make editing easier, enlarge the Scheduler window to view a larger portion of an entry, as shown in Figure 5-5 on page 42, so that you can confirm that the changes you make to an entry are correct. Click the Modify button when you have finished changing an entry. If you want to revert back to the entry’s original configuration, close the window without saving your changes or click the Reset button to revert back to most recently saved version of the window. See “Editing tasks” on page 42 for more information.

6

7 8

/5.2/SANM/associate -p “SamplePolicy” -a “AlarmN Mon Nov 22 1999 at 01:00 “/usr/data/Spectrum/5.2/SANM/ass

Hourly at XX: 30 “/Spectrum/SANM/associate -p “EveryHalfHour” -a “AlarmNotifier” -ph 0x22006b6 -ah 0x220065e”

Scheduled Time

command Application Name Application Model Handle

Policy Model HandlePolicy Name



Figure 5-5: Scheduled Entry in the Scheduler Window

Editing tasks

The following paragraphs outline how to edit a scheduled entry.

To edit the frequency, date, or time:

Select the entry you want to modify in the Scheduled Entries list. Then click the Frequency button and choose a frequency (Once, Hourly, Daily, Weekly, or Monthly). After you choose a different frequency or modify the existing frequency, click the Modify button. The modified entry changes in the Scheduled Entries list. Click the Save button to save the entry to the scheduled operation queue on your system.

To delete an entry from the Scheduled Entries field or the scheduled queue:

Select the entry you want to delete in the Scheduled Entries list. Then click the Remove button. The Scheduler deletes the entry from the Entries section. Click Save before you close the Scheduler window to delete the entry from the scheduled operation queue on your system.

To view the entries that have been applied to the scheduled queue:

Click the Reset button. The Scheduler rereads the scheduled queue and displays saved entries in the Scheduled Entries list.

To discard unsaved changes:

Click the Reset button. The Scheduler discards the unsaved entries and displays the scheduled queue entries in the Scheduled Entries list.

To apply any changes to entries in the scheduled queue:

Click the Save button.When you use the Once frequency to schedule an association, the Scheduler performs the task and then updates the entry in the Scheduled Entries field so that the task is scheduled at the same time the following year.

Mon Nov 22 1999 at 01:00 “/usr/data/Spectrum/5.2/SANM/associate -p “SamplePolicy” -a “AlarmNotifie

43

Chapter 6: Monitoring SANM Processes

This chapter describes how to track SANM events using the SPECTRUM Event Log and trace files.

In this chapter

• “SANM related events in the SPECTRUM Event Log” on page 43

• “Tracing policies” on page 45

SANM related events in the SPECTRUM Event LogThe SPECTRUM Event Log lists events that occur on a SpectroSERVER. When a user or the Scheduler performs a SANM operation, the results of the operation appear in the Event Log along with other SPECTRUM events. The Event Log contains the following information about the event:

• Date and time of the operation

• Application name and policy name

• User’s host and user’s name

• Explanation of the event

• Event code

Figure 6-1 on page 44 shows an example Event Log with a variety of SANM-related entries listed.

Refer to the SPECTRUM Event Log User Guide (2583) for information on accessing and working with the Event Log.



Figure 6-1: SPECTRUM Event Log

SANM related event codes

Each SANM related event code corresponds to a particular SANM operation or operation failure. Use the following SANM event codes to locate SANM operation entries or filter out all but specific SANM operation entries in the SPECTRUM Event Log.

Event Code Event

00d70000 Application registered with SANM

00d70001 Application unregistered with SANM

00d70002 Association created

00d70003 Association failed

00d70004 Scheduled association created

00d70005 Scheduled association failed

00d70006 Policy created

00d70007 Policy creation failed

00d70008 Policy modified

00d70009 Policy modification failed

00d7000a Application created

00d7000b Application creation failed

00d7000c Policy deleted

00d7000d Policy deletion failed

00d7000e Application deleted

00d7000f Application deletion failed

Scheduled Association

Policy Modified

PolicyCreated

PolicyDeleted

Tracing policies


Tracing policiesTo get information about how a policy is working for a SANM-enabled application, you can specify at application start-up the creation of a detailed or summary trace file for the application. A detailed trace file indicates which filters in a policy alarm did and did not match when they were evaluated against that policy. A summary trace indicates the time an alarm notification is passed to the associated application when that application is started. A summary trace file does not include information about alarms that do not meet the criteria specified in a policy.

A record of policy-based actions by SANM can be used as a decision making tool. The results may confirm that you have the correct policy in effect for an application, or they may compel you to refine your policy, especially if you discover that you are inadvertently excluding alarms that should be passed to an application.

Specifying tracing for a SANM-enabled application

In order to turn tracing on, you need to specify several parameters when starting up the alarm-processing application. See “Starting SANM-enabled AlarmNotifier” on page 51 and “Starting the AR System Gateway Automatic Trouble Ticket Generator” on page 62 for the specific syntax options.

When tracing is not specified, each SpectroSERVER in a distributed environment participates in the alarm-filtering process with SANM, reducing the amount of network traffic that would occur between SpectroSERVERs and alarm-notification applications if SANM were solely responsible for filtering alarms. When you specify tracing, however, SANM alone does the filtering, increasing network traffic between the SpectroSERVER(s) and the alarm-notification application(s). To maintain an optimal network traffic volume, use trace file options only when necessary.

The summary trace file

The summary trace file includes a summary of all alarm notifications (set, cleared, updated) sent to the application, as shown in Figure 6-2. Notice that the summary trace file does not indicate the alarms that failed to pass the policy.

Figure 6-2: Summary Trace File05/24/2000 15:48:44 SANM Trace Entry 1

Notification sent to AlarmNotifier for Alarm 52 set on landscape 0x540000___________________________________________________________________05/24/2000 15:48:44 SANM Trace Entry 2

Notification sent to AlarmNotifier for Alarm 21 updated on landscape 0x540000___________________________________________________________________05/24/2000 15:48:44 SANM Trace Entry 3

Notification sent to AlarmNotifier for Alarm 26 cleared on landscape 0x540000



The detailed trace file

A detailed trace file includes entries for alarms that meet and do not meet the criteria specified in a policy. An entry for an alarm includes the alarm’s attribute values that are compared to the filter parameter values. An arrow symbol under the MATCH heading between the ALARM VALUE and the FILTER VALUE headings indicates a match. The arrow is absent if the values do not match.

Figure 6-3 shows an example of a trace file that indicates that an alarm passed a policy. Figure 6-4 on page 47 shows an example of an alarm that did not match a policy’s filter criteria.

Figure 6-3: Detailed Trace File – Alarm Passed

AlarmNotifier Trace Entry 305

Applying first_shift to Alarm 8982 set on landscape 0x540000Applying Filter 1, tag: Abner or Abbott

ALARM VALUES MATCH FILTER VALUES----------- ----- -------------LANDSCAPE LANDSCAPE

0x540000 --> 0x540000remaining values ignored

MODEL TYPE MODEL TYPEPingable --> Pingable

remaining values ignored

DEVICE LOCATION DEVICE LOCATIONWorld:USA:NorthEast: --> USA

ALARM SEVERITY ALARM SEVERITYCRITICAL MAINTENANCE

SUPPRESSEDMAJOR

--> CRITICALremaining values ignored

ALARM CAUSE ALARM CAUSE0x10007 0x10005

--> 0x10007

SPECTROSERVER HOST SPECTROSERVER HOSTcoffee --> coffee

remaining values ignored--------------------------------------------------------------

FILTER 1 PASSEDAlarm Passed Policy

Notification sent to AlarmNotifier for Alarm 8982 set on landscape 0x540000

Tracing policies


Figure 6-4: Detailed Trace File – Alarm Failed

AlarmNotifier Trace Entry 306

Applying first_shift to Alarm 8986 set on landscape 0x540000Applying Filter 1, tag: Abner or Abbot

ALARM VALUES MATCH FILTER VALUES----------- ----- -------------LANDSCAPE LANDSCAPE

0x540000 --> 0x540000remaining values ignored

MODEL TYPE MODEL TYPEPingable --> Pingable

remaining values ignored

DEVICE LOCATION DEVICE LOCATIONWorld:USA:NorthEast: --> USA

ALARM SEVERITY ALARM SEVERITYINTIAL MAINTENANCE

SUPPRESSEDMAJORCRITICALremaining values ignored

ALARM CAUSE ALARM CAUSE0x10004 0x10005

0x10007

SPECTROSERVER HOST SPECTROSERVER HOSTcoffee --> coffee

remaining values ignored--------------------------------------------------------------

FILTER 1 FAILEDAlarm Failed Policy

Notification NOT sent to AlarmNotifier for Alarm 8986 set on

Alarm AttributesDid Not MatchThese Filters

49

Chapter 7: The SANM Resource File

This chapter describes each of the parameters in SANM’s resource file.

Resource file parametersThe SANM resource file .sanmrc is located in the <$SPECROOT>\SANM directory. It contains operating parameters that define the various defaults that SANM uses. You can modify these parameters at any time. If you choose to modify them, make a backup copy of the file first.

Parameter Description

LANDSCAPE The initial landscape to which SANM connects. If LANDSCAPE is not defined, as in a SpectroGRAPH-only installation, SANM will default to another entry in the VNM Landscape Map. An informational window will display, showing the default landscape handle.

VNM_MAIL_TIMEOUT The minimum time (in milliseconds) that the MailService waits for a response from the SpectroSERVER before the request is canceled. The default value is 60,000 milliseconds (one minute).

VNM_CONNECT_TIME_LIMIT The minimum delay (in milliseconds) before an initial TCP connect request between the application and a SpectroSERVER will time out. The default value is 60,000 milliseconds (one minute).


Chapter 7: The SANM Resource File

Resource file backupsWhen you re-install SPECTRUM or upgrade to another version of SPECTRUM, the install process automatically saves your .sanmrc file to a backup directory. Versions of the .sanmrc resource file you have saved under another name, .sanmrc1 or .sanmrc2 for example, are retained in the <$SPECROOT>/SANM directory along with the default resource file provided by the re-installation or upgrade.

The backup .sanmrc file is saved to the following directory:

<$SPECROOT>/Install-Tools/SAVES_<date>/<time>/SANM

POLICY_LANDSCAPE When a landscape is specified using this parameter, that landscape becomes the only landscape searched for policy models and monitored for policy changes.

If the landscape is down, no policies can be retrieved or created until the landscape is back up. Filtering will continue using the last known policy. Any scheduled policy associations will not occur if the landscape is down.

If no landscape is specified, all landscapes within a distributed environment are searched for policy models and monitored for policy changes.

Either all SANM applications and Policy Administrator should be configured to use a single landscape for policies, or all SANM applications and Policy Administrator should be configured to use all landscapes.

See “Managing SANM policies across multiple landscapes” on page 65 for further details.


51

Chapter 8: SANM and AlarmNotifier

This chapter describes how AlarmNotifier and SANM operate together.

In this chapter

• “Enhancing AlarmNotifier with SANM” on page 51

• “Starting SANM-enabled AlarmNotifier” on page 51

• “Alarm Management parameters” on page 53

• “Acknowledging alarms” on page 53

• “Clearing alarms” on page 54

• “SANM-enable script parameters” on page 55

• “SANM-enabled .alarmrc parameters” on page 59

Enhancing AlarmNotifier with SANMAlarmNotifier gains additional capabilities when you install SANM on your system. These capabilities include additional start-up options which allow for specifying application names and for creating trace files, alarm acknowledge and alarm clear commands, and script and resource file parameters. SANM also allows AlarmNotifier to operate in a distributed environment.

Starting SANM-enabled AlarmNotifierAlarmNotifier is located in the <$SPECROOT>/Notifier directory. By default, this directory contains the following files:

.alarmrc

AlarmNotifier

ClearScript

README

SetScript

UpdateScript



SANM-enabled AlarmNotifier includes the following additional files and directory:

AlarmAck — The program that acknowledges an alarm.

AlarmClear — The program that clears an alarm.

SANM — The link to the <$SPECROOT>/SANM directory.

trace — A directory for trace files.

To start AlarmNotifier, you will use the AlarmNotifier command found in this directory. The additional SANM startup parameters are explained below.

AlarmNotifier [-r <resource file] [-n <application>][-tl summary|details [-tn <trace file>] [-ts < size>]]

-r: This option allows you to specify a resource file other than the default resource file .alarmrc.

SANM Enabled Parameters

-n: This option allows you to override the application name value specified by the APPLICATION parameter in the resource file and specify a different name for an AlarmNotifier application instance. This option enables you to start multiple instances of AlarmNotifier, each of which you can associate with a different SANM alarm-filtering policy. If a name is not assigned to the APPLICATION parameter in the resource file, you must use the -n option at start-up to specify an application name.

-tl: This option allows you to activate tracing at a specified level, summary or details. A summary trace file contains a list of the alarms that were sent to AlarmNotifier. A detailed trace file contains both a description of the alarms that occurred and the reasons why each alarm passed or failed the current alarm-filtering policy. The default format for an AlarmNotifier trace file is the application name together with the date (in the MMDDYYYY format) the trace file was created (AlarmNotifier_04172000, for example).

-tn: This option, which must be used with the -tl option, allows you to specify a trace file name other than the default name provided when only the -tl option is used.

While using the trace file option, by default, the output file is written to the $SPECROOT/Notifier/trace directory. To explicitly name the output file and path, use the [-tn filename] option. If “filename” is a relative path, trace output will be written to a file relative to the current directory. If “filename” is an absolute path, trace output will be written to the absolute path specified.

-ts:This option, which must be used with the -tl option, allows you to specify the number of lines in the trace file. The application writes this number of lines to the file and then wraps around to the beginning of the file. Entries are numbered sequentially and there is an “END OF TRACE” line after the last entry in the file. The default number of lines in a trace file is 10,000.

Alarm Management parameters


Alarm Management parametersThe Alarm Management Model Information view allows users to control some aspects of Alarm Management. Two parameters in this view, Generate Alarm Events and Add Events to Alarms, have an impact on how AlarmNotifier will process alarm event updates. These parameters are explained below. For complete information on the Alarm Management view, see the Distributed SpectroSERVER Guide (2770).

To access these parameters in the Alarm Management Model Information view:

1. Click on the VNM model icon in the SpectroGRAPH to highlight it.

2. Choose Views > Icon Subviews > Configuration to bring up the Landscape Configuration view.

3. In the Configure/Information list box, choose AlarmMngt and click OK.

Generate Alarm Events

This option enables/disables the generation of alarm change events (i.e., occurrences of alarms being generated, updated, or cleared). It is set to Enable by default.

Note: If the Generate Alarm Events option is disabled, the user will not see Alarm History in the Enterprise Alarm view.

Add Events To Alarms

This option controls whether alarm change events are added to each alarm. If disabled, the result is that alarm change events will not be displayed under the Events tab of the Alarm Manager. By default, this option is set to “disabled.”

Receiving alarms from the cache

If the Archive Manager is not consistently providing the events associated with reported alarms due to high traffic, you can retrieve alarm events from the event cache rather than the Archive Manager. To do this, you must set the Store_Originating_Event attribute to True. Keep in mind that the event cache can only provide the AlarmNotifier with a single event that created the alarm. To set the attribute and receive alarms from the cache:

From the Alarm Management view, change to edit mode add a new attribute field for the Store_Originating_Event attribute. Change the value from FALSE to TRUE, and save.

Acknowledging alarmsThe AlarmAck command allows you to acknowledge alarms. It can be used at any shell command prompt to acknowledge specific alarms or it can be incorporated into a script. AlarmAck returns a value of “0” if the operation is successful. Otherwise, it returns a non-zero value.

You can use the AlarmAck command to acknowledge a particular alarm using the following syntax:

AlarmAck -a <alarm> -l <landscape>



Where:

-a: The alarm ID.

-l: The landscape handle for the landscape where the alarm occurred. (Available only for distributed SpectroSERVER environments)

You can use the AlarmAck command to acknowledge all alarms for a model using the following syntax:

AlarmAck -m <model handle>

Where:

-m: The model handle for the model with the alarm condition(s).

Clearing alarmsThe AlarmClear command clears user-clearable alarms. To determine if an alarm is user-clearable, check the value of the UserClearable parameter in alarm notifications. It can be used at any shell command prompt to clear specific alarms or it can be incorporated into a script. AlarmClear returns a value of “0” if the operation is successful. Otherwise, it returns a non-zero value.

You can use the AlarmClear command to clear alarms using the following syntax:

AlarmClear -a <alarm> -l <landscape>

Where:

-a: The alarm ID number.

-l: The landscape handle of the landscape where the alarm occurred.

SANM-enable script parameters


SANM-enable script parametersThe SetScript, UpdateScript, and ClearScript scripts each have additional parameters when run on a machine that has SANM installed. These parameters are defined in the table below.

Table 8-1: SANM Enabled Script Parameters

E-mail notifications

When you use an AlarmNotifier script to send an e-mail notification, you must set the value for the VARFORMAIL parameter in the script. This parameter specifies who the e-mail notification should be sent to.


FlashGreen “True” or “False.” This parameter appears in ClearScript notifications but not in SetScript or UpdateScript notifications. True indicates that the cleared alarm is exhibiting the “flash green” condition in SpectroGRAPH (the “flash green” option for the model is enabled in SpectroGRAPH, and the GET_FLASH_GREEN parameter in the .alarmrc resource file is set to “true”). See the SPECTRUM Menus (2519) guide for information on enabling the “flash green” option in SpectroGRAPH. Note that even though this field is not displayed by SetScript and UpdateScript notifications, the parameter is actually passed to these scripts, and because it is invalid, it has the default value of False in each script.

Location The location model that contains the network element for which the alarm is set, updated, or cleared if the element is modeled in the SpectroGRAPH Location Hierarchy view. The location model that contains the model for the errant network element appears in a hierarchical list of location models separated by colons. For example, an alarm for a model contained in Room 222 on the first floor of the Boston building in the northeast region of the United States would appear as follows:

USA:Northeast:BostonBldg:FirstFloor:Room222

See SPECTRUM Views (2517) for information on Location Hierarchy views.

AlarmAge The length of time, specified in the filter(s) in a SANM policy, that SANM retains an alarm from an instance of AlarmNotifier that is associated with that policy. If the alarm has to pass multiple filters with different ages, then SANM uses the shortest, non-zero alarm age interval.

NotificationData A list of notification data entries (names of persons), specified in the filter(s) in a SANM policy, that SANM passes to an instance of AlarmNotifier that is associated with that policy. AlarmNotifier scripts can be configured to initiate e-mail notifications to those persons specified by notification data entries.

ProbableCause The probable cause text associated with the alarm.

EventMessage The message about the event(s) associated with the alarm. This field is blank if the alarm generated by SPECTRUM does not have associated events or if the event does not include additional information about the alarm.



When you are using SANM-enabled AlarmNotifier, you can use the NotificationData parameter defined in the table above to set the value for VARFORMAIL. If you use NotificationData as the value for VARFORMAIL, e-mail is sent to the person(s) specified in the NotificationData parameter in the SANM policy that is associated with the instance of AlarmNotifier that invokes the script. For example, if the Notification Data entry is formatted as follows:

John: Mary or Sue: Lynn, Jeff

Then e-mail is sent to John, Mary, Lynn, and Jeff, but not to Sue, because AlarmNotifier interprets the colon as an “and” operator and does not act upon the “or” operator.

Other possible values for the VARFORMAIL parameter are RepairPerson or Both. The RepairPerson option is the only option available for AlarmNotifier when it is not running with SANM. Both indicates that the e-mail notification is sent to the designated RepairPerson and to the person specified by the NotificationData parameter.

For more information on configuring an AlarmNotifier script to send an e-mail notification, see the AlarmNotifier User Guide (1503).

Sending data to a third-party application

You can customize or replace the SetScript, ClearScript, or UpdateScript in order to create an integration with a third-party application.

If you choose to create your own script or executable, it is important to understand which arguments are passed from SPECTRUM to the receiving script or executable. In order for your script or executable to work properly, it must receive all of the arguments passed to it by SPECTRUM in the correct order.

Note: Any SPECTRUM attribute of the model involved in the alarm can be passed to AlarmNotifier and used in a script. See the AlarmNotifier User Guide (1503) for instructions.

Table 8-2 on page 57 shows the argument number, name, and format of each argument passed to each script when the USE_NEW_INTERFACE .alarmrc parameter is set to TRUE. Table 8-3 on page 57 shows the argument number, name, and format of each argument passed to each script when the USE_NEW_INTERFACE .alarmrc parameter is set to FALSE. When USE_NEW_INTERFACE is set to TRUE, the Status, PCause, and EventMsg arguments are sent as environmental variables and argument order is therefore affected.

Note: See the AlarmNotifier User Guide (1503) for information on the USE_NEW_INTERFACE .alarmrc parameter.

SANM-enable script parameters


Table 8-2: Arguments Passed when USE_NEW _INTERFACE is Set to TRUE

Table 8-3: Arguments Passed when USE_NEW _INTERFACE is Set to FALSE

Argument Name Format

1 Date mm/dd/yyyy

2 Time hh:mm:ss

3 Model Type Text

4 Model Name Text

5 Alarm ID Integer

6 Severity Text

7 Cause Text

8 Repair Person Text

9 Server Text

10 Landscape Hexadecimal

11 Model Handle Hexadecimal

12 Model Type Handle Hexadecimal

13 IP Address xxx.xxx.xxx.xxx

14 Security String Text

15 Alarm State Text

16 Acknowledged Text

17 Clearable Text

18 Flash_Green Text

19 Location Text

20 Age Integer

21 Notifdata Text


1 Date mm/dd/yyyy

2 Time hh:mm:ss

3 Model Type Text

4 Model Name Text

5 Alarm ID Integer

6 Severity Text

7 Cause Text

8 Repair Person Text



Note: If USE_NEW_INTERFACE is set to FALSE, you must use the following syntax in your script to read data from the PCause and the EventMsg argument into a variable: <variablename>=`echo "$2" | tr '\350' '\012' | tr '\351' '"'` This is required in order to avoid problems with the script's parsing of the extra data caused by new lines or other special characters.

9 Status Text

10 Server Text

11 Landscape Hexadecimal

12 Model Handle Hexadecimal

13 Model Type Handle Hexadecimal

14 IP Address xxx.xxx.xxx.xxx

15 Security String Text

16 Alarm State Text

17 Acknowledged Text

18 Clearable Text

19 Flash_Green Text

20 PCause Text

21 Location Text

22 Age Integer

23 Notifdata Text

24 EventMsg Text


SANM-enabled .alarmrc parameters


SANM-enabled .alarmrc parametersThe AlarmNotifier resource file, .alarmrc, has several additional parameters when run on a machine that has SANM installed. These parameters are defined in the table below.

Table 8-4: SANM-Enabled .alarmrc Parameters

APPLICATION The application name that identifies this AlarmNotifier application. If you use multiple AlarmNotifier applications on your network, differentiate between applications by using unique application names such as AlarmNotifier1 or AlarmNotifier2. This allows you to use unique SANM alarm-notification policies with each application. If you use the -n option when invoking AlarmNotifier, the APPLICATION parameter value is ignored. The default value is AlarmNotifier.

GET_LOCATIONS True (the default value) or False. This parameter allows you to specify whether or not you want to be notified of the location of the device that the alarm is on. If you are not interested in location information, set this parameter to “false.” A “false” setting will override any location specified as a filter parameter in an alarm-notification policy. This will reduce the network traffic.

GET_PROBABLE_CAUSES True (the default value) or False. This parameter allows you to specify whether or not you want to receive the Probable Cause text associated with each alarm. If you are not interested in Probable Cause information, set this parameter to “false.” This will improve the performance of AlarmNotifier.

GET_EVENTS True (the default value) or False. This parameter allows you to specify whether or not you want to receive the Event message which may be associated with each alarm. If you are not interested in event information, set this parameter to “false.” This will reduce network traffic generated by AlarmNotifier and improve its performance.

GET_FLASH_GREEN True (the default value) or False. This parameter allows you to specify whether you want to receive the Flash Green status of a model. ClearScript is the only script that displays the Flash Green status. When Flash Green is enabled for a model, the model continues to flash green even after alarms have been cleared. This signals that alarms have occurred even though they no longer exist. If the value of GET_FLASH_GREEN is set to “false,” the Flash Green status is always passed to the ClearScript as false. If set to “true,” the Flash Green status is correctly passed as either false or true.



MSG_TIMESTAMP_FORMAT The format for the timestamp on all SANM messages. The maximum length of the output string is 127 characters. Any characters other than the conversion strings will be output as text in the timestamp. The default setting is %X %x:. Note that the colon (:) character will be output at the end of the timestamp.

For example, to output the date/time for the current locale and the time-zone name, the string %x %X %Z would be entered as the value.

If left blank, no timestamp will be output on the messages.

If an incorrect string is entered, that string will appear as text in the output.

POLICY_LANDSCAPE This setting allows you to specify the landscape AlarmNotifier will use for all SANM policy definitions. This parameter works in conjunction with the POLICY_LANDSCAPE setting in SANM’s .sanmrc file.

For more information see “Managing SANM policies across multiple landscapes” on page 65.

SHOW_ALL_EVENTS False (the default value) or True. This parameter allows you to specify whether you want to receive the most recent event for an alarm or all events generated for that alarm.

If SHOW_ALL_EVENTS is False, AlarmNotifier will only forward the most recent event. For example, if an alarm was created based on a given event, and then someone updated the status of that alarm therefore generating another event related to that alarm, AlarmNotifier would only receive the status of that second event. The purpose of this is to eliminate events that may have already been forwarded. This is especially important if the size of the message is relevant, i.e. if the event message will be sent via a page.

61

Chapter 9: SANM and SPECTRUM’s AR System Gateway

In this chapter

• “Enhancing AR System Gateway with SANM” on page 61

• “Starting the AR System Gateway Automatic Trouble Ticket Generator” on page 62

• “SANM-enabled resource file parameters” on page 63

• “Trouble ticket form field options” on page 64

Enhancing AR System Gateway with SANMThe SANM-enabled AR System Gateway benefits from the increased functionality and policy-based alarm filtering capabilities of SANM.

In a SANM-enabled environment with a single SpectroSERVER, all network information is collected and filtered through SANM’s Policy Administrator. This feature provides greater control over network alarm filtering and the ability to provide more information in the SPECTRUM Trouble Ticket.

The SANM-enabled AR System Gateway with multiple SpectroSERVER capability has the ability to monitor alarms from multiple SpectroSERVERs. In a distributed environment, SANM enables the user to monitor alarms from multiple SpectroSERVERs using a single AR System Gateway process.

SANM-enabled filtering provides more capabilities than the default AR System Gateway installed filtering. SANM policy-based filtering adds to the filtering system the options of scheduling and managing alarms on a distributed network.

If SANM is installed, the SANM policies replace the AR System Gateway base-level filter (e.g., Policy Administrator replaces Alarm Filtering).

For complete information on the AR System Gateway, see the AR System Gateway User Guide (0708).



Starting the AR System Gateway Automatic Trouble Ticket Generator

When the machine with the AR System Gateway installed is booted and Remedy is found on the system, the first instance of the AR System Gateway Automatic Trouble Ticket Generator is automatically started by SPECTRUM’s Process Control program, processd. In a SANM-enabled environment with more than one Remedy Server, a unique instance of the AR System Gateway is required for each Remedy Server that will be receiving alarm information. Additional instances of the Automatic Trouble Ticket Generator must be started manually using the arsgated.pl command.

The AR System Gateway may be launched using the arsgated.pl command alone or with various options, some of which are SANM-enabled. A list of the command options and their descriptions are shown in the table below.

Table 9-1: arsgated.pl Command Options

CommandOption

Description

-p This option allows the user to specify a password other than that in the resource file. If a password is required and not specified on the command line with the -p option or in the resource file, the user will be prompted for the password.

-r This option allows the user to specify a resource file other than the default resource file (.arsgrc or .manualrc).

-n This option allows the user to override the APPLICATION parameter in the resource file and specify a unique name for each instance of the AR System Gateway process, such as AR System Gateway1 or AR System Gateway2. This enables the user to launch multiple instances of the AR System Gateway process and to execute unique policies with each instance of the process. If a value has not been assigned to the APPLICATION parameter, the user must use the -n option at startup. This option is available only with SANM.

-tl This option allows the user to turn on tracing at the specified level—either summary or details. This helps the user debug SANM policies by creating a summary or detailed trace for these policies. A summary trace file contains a list of the alarms that were sent to the application. A detailed trace file contains both a description of the alarms that occurred and the reasons why each alarm passed or failed the current alarm notification policy. This trace option is available only with SANM.

-tn This option (available only when used with the -tl option) allows the user to specify the name of the trace file. The AR System Gateway process creates the trace file in the trace subdirectory and gives the trace file a name consisting of the application name with the date appended to it (AR_System_Gateway_022800, for example) unless the user specifies the trace file name with the -tn option. This trace option is available only with SANM.

-ts This option (available only when used with the -tl option) allows the user to specify the number of lines in the trace file. The application writes this number of lines to the file and then wraps around to the beginning of the file. Entries are numbered sequentially and there is an “END OF TRACE” line after the last entry in the file. The default number of lines is 10,000. This trace option is available only with SANM.

SANM-enabled resource file parameters


SANM-enabled resource file parametersThe parameters listed and described in the table below are added to the AR System Gateway’s resource file, .arsgrc, when SANM is installed.

Table 9-2: SANM-Enabled Resource File Parameters

SANM-Enabled Parameter Description

LOCATION_FIELD_ID Location of the model for which the alarm was generated. When a field ID is specified, the location is entered into the specified field for the form listed in the FORM_NAME parameter.

NOTIFICATION_DATA_FIELD_ID List containing notification data for each Alarm Filter that the alarm passed. When a field ID is specified, the notification data list is entered into the specified field for the form listed in the FORM_NAME parameter.

ASSOCIATED_EVENT_FIELD_ID The associated event text for each alarm that passed the filter. When a field ID is specified, the associated event text is entered into the specified field for the form listed in the FORM_NAME parameter.

AGE_FIELD_ID Length of time (in seconds) the alarm aged before reporting a Trouble Ticket. When a field ID is specified, the alarm age is entered into the specified field for the form listed in the FORM_NAME parameter.

APPLICATION Application name that identifies this instance of the AR System Gateway process (arsgated). If multiple AR System Gateway processes are running on the network, use unique application names such as AR System Gateway1 or AR System Gateway2. This allows the use of unique policies with each instance of the AR System Gateway process. In this case, enter the unique application name as the parameter value. If the -n parameter is used when invoking the arsgated command, the value given in the .arsgrc file is ignored.

MSG_TIMESTAMP_FORMAT The format for the timestamp on all SANM messages. The maximum length of the output string is 127 characters. Any characters other than the conversion strings will be output as text in the timestamp. The default setting is %X %x:. Note that the colon (:) character will be output at the end of the timestamp. The LOCALE setting for the system is used for the time.

For example, to output the date/time for the current locale and the time-zone name, the string %x %X %Z would be entered as the value.

If left blank, no timestamp will be output on the messages.

If an incorrect string is entered, that string will appear as text in the output.



Trouble ticket form field optionsWhen you are working with a SANM-enabled AR System Gateway, the following additional trouble ticket form fields are available.

Table 9-3: Form Field Options

POLICY_LANDSCAPE This setting allows you to specify the landscape to which AR System Gateway will look to for all SANM policy definitions. This parameter works in conjunction with the POLICY_LANDSCAPE setting in SANM’s .sanmrc file.

For more information see “Managing SANM policies across multiple landscapes” on page 65.

SHOW_ALL_EVENTS False (the default value) or True. This parameter allows you to specify whether you want to receive the most recent event for an alarm or all events generated for that alarm.

If SHOW_ALL_EVENTS is False, AlarmNotifier will only forward the most recent event. For example, if an alarm was created based on a given event, and then someone updated the status of that alarm therefore generating another event related to that alarm, AlarmNotifier would only receive the status of that second event. The purpose of this is to eliminate events that may have already been forwarded. This is especially important if the size of the message is relevant, i.e. if the event message will be sent via a page.

Field Data Type

LengthorValues

EnteredBy

Description and resource file parameter

Field ID

Age Integer NA Gateway Length of time (seconds) alarm aged before reporting trouble ticket. (AGE_FIELD_ID)

NA

Location Character max Gateway Location of the model for which the alarm was generated.(LOCATION_FIELD_ID)

536870922

Notification Data

Character 255 Gateway A list containing notification data for each alarm filter that the alarm passed.(NOTIFICATION_DATA_FIELD_ID)

536870923

Event Character max Gateway A list of either the most recent event for an alarm or all events generated for that alarm (depends on the value for SHOW_ALL_EVENTS).

536870924

SANM-Enabled Parameter Description

65

Chapter 10: Using SANM in a Distributed SpectroSERVER Environment

This chapter describes how SANM operates in a distributed SpectroSERVER environment.

In this chapter

• “Managing SANM policies across multiple landscapes” on page 65

• “Determining the landscapes that are currently monitored” on page 67

A Distributed SpectroSERVER (DSS) environment allows you to divide SPECTRUM’s network management tasks among several SpectroSERVERS. When you create a network model with multiple SpectroSERVERs, it is possible for SANM to access information from more than one SpectroSERVER at the same time.

A landscape is the SPECTRUM term for a network domain that is managed by a single SpectroSERVER. When SANM operates in a distributed environment, it monitors alarms from all landscapes.

Even though different landscapes may model each other in a DSS environment, SANM-enabled applications do not receive duplicate alarm information.

Because SANM evaluates alarms across VNMs in a DSS environment, you will probably want to limit the type of alarm notifications that you receive. If you work in a DSS environment, you can limit the number of alarm notifications by carefully defining the Landscape, Subnet IP Address, and Device Location parameters in the alarm notification policy.

Managing SANM policies across multiple landscapesThere are two ways to configure SANM in a distributed environment. You can create SANM policies on any landscape and allow SANM to read all policies from all landscapes, or you can create all SANM policies on one landscape and only allow SANM to read policies from that landscape. In either case, alarm-processing applications from any landscape can be associated with the SANM policies.



Creating SANM policies on many landscapes

You can set up a distributed environment so that SANM policies can be defined and managed on any SpectroSERVER in the distributed environment. Alarm-processing applications on any SpectroSERVER in the distributed environment have access to all of these policies.

To set up this configuration:

1. The POLICY_LANDSCAPE parameter in the .sanmrc file must have no value associated with it.

2. Change the POLICY_LANDSCAPE parameter in the alarm-processing application’s resource file (.alarmrc, .arsgrc, etc.) must also have no value associated with it.

3. Restart the SpectroSERVER where SANM is installed and restart the alarm-processing applications so that the changes to the resource file parameters will be read.

4. Open SANM’s policy administrator. Note that all policies that have been created within the distributed environment are available and all alarm-processing applications in the distributed environment are available for association.

Creating SANM policies on one landscape

If you set up a distributed environment so that all policies for all landscapes are defined and managed from a single SpectroSERVER, alarm-processing applications can be installed on any of the SpectroSERVERS in the distributed environment. By setting the appropriate values in the application’s resource file, the application finds the server that contains the SANM policy definitions and associates it with the appropriate policy. This configuration cuts down on the initial traffic exchanged on the network as alarm processing applications and SANM policies are associated, and it also makes managing SANM policies easier on an ongoing basis.

Note: It is not possible to migrate or move a SANM policy from one landscape to another. If you would like to institute this configuration and already have policies defined on various landscapes, you must recreate these policies on the single landscape from which you will be managing SANM policies.

To set up this configuration:

1. Change the POLICY_LANDSCAPE parameter in the .sanmrc file to the landscape handle of the SpectroSERVER where SANM is installed and policies will be created and managed.

2. Change the POLICY_LANDSCAPE parameter in the alarm-processing application’s resource file (.alarmrc, .arsgrc) to the landscape handle of the SpectroSERVER where SANM is installed. This tells the application where to look for defined policies.

3. Restart the SpectroSERVER where SANM is installed and restart the alarm-processing applications so that the changes to the resource file parameters will be read.

4. Open SANM’s policy administrator. Note that the only policies available are the policies that have been created on this landscape. All alarm-processing applications which have their POLICY_LANDSCAPE parameter set to the landscape handle of this landscape will be seen in the applications list.

Determining the landscapes that are currently monitored


Determining the landscapes that are currently monitored You can use the following methods to determine which landscapes are monitored by SANM:

• Use the SPECTRUM Command Line Interface (CLI) application to connect to the SpectroSERVER to which SANM is connected, and then type show landscapes on the command line. The CLI application displays a list of all the landscapes modeled in that server. See Command Line Interface (0664) for more information.

• Open the Open Policy window from SANM’s Policy Administrator window, and then select Landscape from the Parameter list from a filter. An Add Filter Values dialog box appears, listing available landscapes.

• Open any one of the detailed trace files you may have specified for SANM-enabled applications. A trace file indicates the connection status of each landscape in the landscape map for the SpectroSERVER to which SANM is connected to that SpectroSERVER. Trace files are stored by default in a trace directory in a SANM-enabled application’s home directory. See “Tracing policies” on page 45 for more information about the trace files.

69

Index

Symbols.alarmrc resource file

SANM-enabled parameters 59.arsgrc

SANM-Enabled 63.manualrc

SANM-Enabled 63.sanmrc file 14, 49

backups 50

AAdd Filter Values dialog box 17

adding values 21Apply button 16applying changes in 16Cancel button 16closing 16deleting values in 21finding value from lengthy list 16modifying parameter values 21OK button 16Search button 16Update button 21

Aging, specify for an alarm in a filter 23Alarm Age 17

specifying 29Alarm Age parameter in a filter 23Alarm management 53Alarm Monitoring Process

overview of 9Alarm Probable Cause ID parameter 22AlarmAge, SANM-enabled script parameter 55AlarmNotifier

SANM-enabled functionality 51

Alarmsacknowledging 53clearing 54generated by SPECTRUM 10the events that caused 55

APPLICATION parameter, override option 52APPLICATION, SANM-enabled .alarmrc

parameter 59Applications

adding 34associating policies with 32deleting 35multiple instances of 32naming 34

arsgated.pl 62Associations

scheduling 37Auto-Edit Parameter Values option 17, 25Automatic Trouble Ticketing 62

CCLI

show landscapes command 67using to connect to initial landscape 67

Command field, in Scheduler window 38

DDaily option for scheduled associations 39Default Policy

modifying 32, 35Default resource file 14Delete

filters 28parameter values 29


Index

parameters 29policies 35

Device Type 23Distributed SpectroSERVERs 65

determining landscapes monitored 67

EEvent codes 44EventMessage, SANM-enabled script

parameter 55

FFilter

adding parameters to 28creating 15deleting 28negating parameters in 29

Filters, with different Alarm Age values 23FlashGreen, SANM-enabled script parameter 55

GGET_EVENTS, SANM-enabled .alarmrc

parameter 59GET_FLASH_GREEN, SANM-enabled .alarmrc

parameter 59GET_LOCATIONS, SANM-enabled .alarmrc

parameter 59GET_PROBABLE_CAUSES, SANM-enabled

.alarmrc parameter 59

HHourly option for scheduled associations 39

IIP Subnet parameter 20

deleting 21editing 21inserting IP addresses into filters 20

LLandscape map

determining landscapes from which SANM receives alarms 67

LANDSCAPE, resource file parameter 49

when not defined 49Location, SANM-enabled script parameter 55

MModel handle

specified for policy in scheduled entry 41Monthly option for scheduled associations 39MSG_TIMESTAMP_FORMAT, SANM-enabled

.alarmrc parameter 60

N-n command option 52New application name 34Notification Data 18, 23

customizing 18error checking in 25string format 24

NotificationData, SANM-enabled script parameter 55

NotificationData, VARFORMAIL parameter value in scripts 56

OOnce option for scheduled associations 39Open Policy window 16

adding parameters 28creating filters 15Delete button 22deleting filters 28deleting parameter values 29duplicating filters 28enabling filter operations 27opening Add Filter Values dialog box from 17opening parameter list 15Options menu 25Parameter Operations section 22Save As command 19saving policies in 19selecting all parameters 29specifying "not true" parameter values 29User icon 24

Option, scheduled association frequency 39Options menu

Auto-Edit Parameter Values 17, 25

PParameter


Alarm Severity 13deleting 29deleting values in 29Device Location 13IP Subnet 13Landscape 13Model Name 13Model Type Name 13Probable Cause 13SpectroSERVER Host 13

Policyassociating with applications 32creating a new 14deleting 35editing 27effect on associated application(s) when

edited 32naming 14saving 19tracing 45unique name requirement 19

Policy Administratorfunctions of 13starting using non-default resource file 14

Policy Administrator windowSchedule Association button 38Selection icon 35User Selection dialog box 25

POLICY_LANDSCAPE 60PolicyAdmin -r, start-up command with resource

file option 14PolicyAdmin, start-up command 14ProbableCause, SANM-enabled script

parameter 55

R-r command option 14, 52Resource file 49

backups 50

SSANM

event codes 44Policy Administrator 13resource file 49trace files 67with distributed SpectroSERVERs 65

SANM Policy Administrator option 14SANM-enabled applications 23SANM-enabled commands

AlarmAck 53Save

policy 19scheduled association 40

Save As dialog box 19Scheduled association

modifying 41removing from scheduled entry queue on host

platform 42saving 40

Scheduled Entries list 40Scheduler 37

accessing 38format of entries in 41frequency options 39

Scheduler windowAdd button 40Associate button 38Close button 41closing 41Frequency button 42Modify button 41, 42Remove button 42Reset button 42Save button 40, 42

show landscapes command 67SHOW_ALL_EVENTS 60, 64SpectroGRAPH

displaying alarm conditions 10flash green option 55

SPECTRUM, role in alarm-monitoring/notification process 9

Starting Automatic Trouble Ticket Generation 62 to ??

T-tl command option 52-tn command option 52Tools menu in SpectroGRAPH 14Trace file

detailed 46summary 45

Trace files 67effect on SPECTRUM’s role in alarm-

monitoring 67Trace log options 52Tracing policies 45Tracing, effect on network traffic 45Trouble Ticket Generation

Starting Automatic 62 to ??-ts command option 52


Index

UUser icon 24

VVNM_CONNECT_TIME_LIMIT, resource file

parameter 49VNM_MAIL_TIMEOUT, resource file

parameter 49

WWeekly option for scheduled associations 39Windows NT/2000 37Windows NT/2000 requirements 39

SPECTRUM Alarm Notification Manager (SANM) User...

Documents

Transcript of SPECTRUM Alarm Notification Manager (SANM) User...