HP OpenView System Administration Handbook [Electronic resources] : Network Node Manager, Customer Views, Service Information Portal, HP OpenView Operations نسخه متنی

19.5 TEMPLATES

Most of the template configurations within OVO use the graphical user interface. The MoM templates do not have a GUI. The templates are in ascii format. Use an ASCII text editor to configure the template. MoM sample templates are pre-configured with the most popular multiple server scenarios. After the template is customized, check the template syntax with the utility opcmomchk.

19.5.1 Template Types

The template type defines the rules for message filtering and forwarding provided to the message agents and the message managers. The overall template types are

Time
Describes the criteria for what time the specific rules and conditions apply for message match or suppression.
Message forwarding
Describes the roles and responsibilities of the management servers and how agent and server processes handle messages based on match and suppress criteria.
Escalation
Describes criteria for sending a message to another server via an operator initiated escalation of a selected message.
Service
Describes the service hierarchy for use with Service Navigator. (Refer to the HP OpenView Service Navigator Concepts and Configuration Guide for additional information about Service Navigator.)

19.5.2 Management Server Templates

Templates on the management server provide instructions for message forwarding, service outage, service management, and escalations. The corresponding template names are

msgforw
escmgr
outage
service (use with Service Navigator; not covered in this chapter)

The template files listed will reside in the ./respmgrs directory and must have the names as shown.

The allnodes template is created on the manager and distributed to the managed node. If you require special rules within the node template for some nodes and not others, copy and rename the allnodes file with a unique file name. This is covered in more detail in Section 19.5.4.1.

19.5.2.1 Template Activation

Perform MoM template activation on the server with either a server process restart or session restart. See the template descriptions for the proper method to activate the template. Perform template distribution to activate MoM template on the managed node, which triggers the agent to read the MoM configuration file.

19.5.3 Managed Node Templates

MoM templates for certain scenarios (such as backup-server and follow-the-sun) reside on the managed node and define message-forwarding rules and secondary server authorization. The message agent reads the template during agent startup. The mgrconf file is the MoM template on the managed node after it has been distributed from the OVO server. Do not modify this file manually.

19.5.4 Template Distribution

The MoM template distribution process is the same process used for other templates. Through the GUI, select

ActionsAgentsInstall/Update Templates . Use the

opcragt command (with the appropriate options) for command line template distribution.

Prior to distribution, locate the customized template in the production directory (respmgrs). During distribution, the distribution manager will check for new or updated templates in the respmgrs directory.

19.5.4.1 Template File Names that Change after Distribution

The MoM template for the managed node is either called allnodes or a name that represents the IP address converted to hex number format. If the name is allnodes, this template is distributed to all the selected managed nodes during distribution. If the name of the template is a converted IP address for one of the nodes, it means that the configuration is different from the allnodes file. The IP address template file is only distributed to the node with the IP address that is the same as the hex number of the template file.

19.5.4.2 Convert IP Address to Hex Number

A utility program,

opc_ip_addr , is available in the directory /opt/OV/bin/OpC/install to help with the math conversion of the IP address.


#/opt/OV/bin/OpC/install/opc_ip_addr lotus
lotus=192.168.16.2=c0a81002

19.5.4.2 Rename the allnodes File for a Specific Node

Here is an example of the process to change the name of the file for distribution to a specific node:


# ls l /etc/opt/OV/share/conf/OpC/mgmt_sv/respmgrs
total 6
-rrr   1 root       sys           2098 Aug 14 15:23 allnodes
drwx   2 root       sys             96 Dec  2  2000 lastdistr
# cp allnodes c0a81002
# ls -l
total 12
-rrr   1 root       sys           2098 Aug 14 15:23 allnodes
-rrr   1 root       sys           2098 Aug 14 15:25 c0a81002
drwx   2 root       sys             96 Dec  2  2000 lastdistr

After adding the custom changes to the new file c0a81002, distribute to the managed node (lotus in the prior example) either with the GUI or with the command

opcragt .

19.5.5 Template Syntax

The templates are written with a syntax that describes how the agent will handle the messages that are filtered (for match or suppress conditions) by the template. The logic of the template is organized from the top with a section to define time criteria. The message must match the time criteria (if it is specified) in addition to the other template conditions. The time criteria is set to #none if it does not apply.

Each section of the template begins with a section label in all capital letters. The section label is plural and the subsections' labels are singular. Multiple sub-sections can follow a section label. Descriptions and comments help make the templates easier to understand. Comments follow the symbol (#). Two good rules-of-thumb are to use comments liberally throughout the template and use offset lines for readability. The symbol "e" used in the syntax descriptions represents an empty string. An "OR" condition is represented by the symbol "|". Days of the week are spelled out. The time is represented by a twenty-four-hour format. Dates are specified by the month (two-digits), the day, (two-digits), the year (four digits).

19.5.5.1 Time Template

A sample time template "followthesun" and the syntax chart are shown here for reference. The template is followed by brief descriptions of the syntax. A time template defines generic time ranges (e.g DAYTIME = 8:00-18:00). These definitions have to be referenced in message rules later in the template file in order to become active. You may want to specify that Database messages during DAYTIME are sent to another manager. The time template configuration is illustrated here:


TIMETEMPLATES
# time template 1
TIMETEMPLATE "shift1"
DESCRIPTION "Time Template 1 "
# Time template for shift1
# this includes the time from 17:00 to 24:00  and from  0:00 to 6:00
# on the weekday Monday to Friday
TIMETMPLCONDS
TIMETMPLCOND
TIME FROM 0:00 TO 6:00
WEEKDAY FROM Monday TO Friday
TIMETMPLCOND
TIME FROM 17:00 TO 24:00
WEEKDAY FROM Monday TO Friday
TIMETEMPLATE "shift2"
DESCRIPTION "Time Template 2 "
# Time template for shift2
# this includes the time from 6:00 to 17:00
# on the weekday Monday to Friday
TIMETMPLCONDS
TIMETMPLCOND
TIME FROM 6:00 TO 17:00
WEEKDAY FROM Monday TO Friday
# time template 3
TIMETEMPLATE "shift3"
DESCRIPTION "Time Template 3 "
# Time template for shift3
# this includes the time from 0:00 to 24:00 (the whole day)
# on the weekday Saturday and Sunday
TIMETMPLCONDS
TIMETMPLCOND
TIME FROM 0:00 TO 24:00
WEEKDAY FROM Saturday TO Sunday

19.5.5.2 Keywords for the Time Templates

TIMETEMPLATES
Define one or more time templates in the section labeled TIMETEMPLATES.
TIMETEMPLATE
Define the individual templates with the key TIMETEMPLATE and include elements for message match or suppress time. Give each time template a unique name and DESCRIPTION surrounded by double quotes.
TIMETMPLCONDS
Multiple time template conditions can follow the section label.
TIMETMPLCOND
Define the match or suppress time criteria. Valid time criteria are based on Universal Standard Time (UST). (Reference Appendix C for more information on UST.)
TIMECONDTYPE
The start of the time filter criteria begins with the key TIME FROM and ends with the key TO. The time is further defined by the specification of additional parameters within the time condition type WEEKDAY ON the DAY (of the week or multiple days) or the exact DATE.

19.5.5.3 Time Template Syntax

The full keyword syntax list is shown here.


timetmpls     ::=
<timetmpls> TIMETEMPLATE <string>
DESCRIPTION   <string>
<conditions> | e
conditions ::=
TIMETMPLCONDS <timetmplconds> | e
timetmplconds ::=
<timetmplconds> TIMETMPLCOND <timetmplcond> | e
timetmplcond ::=
[TIMECONDTYPE <timecondtype>]
[TIME FROM  <time> TO <time>]
[WEEKDAY <weekday>]
[DATE  <exact_date>] | e
timecondtype ::=
Match| Suppress
time ::=
<hh>:<mm>
weekday ::=
ON <day> | FROM <day> TO <day>
exact_date ::=
ON <date> | FROM <date> TO <date>
day ::=
Monday|Tuesday|Wednesday|Thursday|Friday|Saturday|Sunday
date ::=
<mm>/<dd>/<yyyy> | <mm>/<dd>/*

19.5.5.4 Message Template

The sample template "followthesun" is shown here. The responsible manager configuration template sections with brief syntax descriptions immediately follow the template.The following illustration is the second part of the template file that was described in Section 19.5.5.1.


#
# Responsible Manager Configurations for follow-the-sun functionality
#
RESPMGRCONFIGS
RESPMGRCONFIG
DESCRIPTION "responsible managers M1 "
SECONDARYMANAGERS
SECONDARYMANAGER
NODE IP 0.0.0.0 "M1"
DESCRIPTION "secondary manager M1"
SECONDARYMANAGER
NODE IP 0.0.0.0 "M2"
DESCRIPTION "secondary manager M2"
SECONDARYMANAGER
NODE IP 0.0.0.0 "M3"
DESCRIPTION "secondary manager M3"
ACTIONALLOWMANAGERS
ACTIONALLOWMANAGER
NODE IP 0.0.0.0 "M1"
DESCRIPTION "action allowed manager M1"
ACTIONALLOWMANAGER
NODE IP 0.0.0.0 "M2"
DESCRIPTION "action allowed manager M2"
ACTIONALLOWMANAGER
NODE IP 0.0.0.0 "M3"
DESCRIPTION "action allowed manager M3"
MSGTARGETRULES
MSGTARGETRULE
DESCRIPTION "target rule description "
MSGTARGETRULECONDS
# for all messages
MSGTARGETMANAGERS
MSGTARGETMANAGER
# target manager from 17:00 to 24:00 and 00:00 to 6:00
# from Monday to Friday
TIMETEMPLATE "shift1"
OPCMGR IP 0.0.0.0 "M1"
# target manager from 6:00 to 17:00
# from Monday to Friday
MSGTARGETMANAGER
TIMETEMPLATE "shift2"
OPCMGR IP 0.0.0.0 "M2"
# target manager on the whole weekend
MSGTARGETMANAGER
TIMETEMPLATE "shift3"
OPCMGR IP 0.0.0.0 "M3"

19.5.5.4 Keywords for Responsible Manager Configuration

RESPMGRCONFIGS
Begins the description of the configuration for the responsible managers (primary, secondary, and action-allowed or escalation).
RESPMGRCONFIG
Begins the responsible manager configuration.
DESCRIPTION
A string containing a short manager description.
SECONDARYMANAGERS
A secondary ITO manager for an agent has permission to take over responsibility and to become the primary ITO manager for an agent.
SECONDARYMANAGER
Begins the configuration for a specific secondary manager.
NODE
The NODE IP of the SECONDARYMANAGER.
DESCRIPTION
A string that contains the description of the SECONDARY MANAGER.
ACTIONALLOWMANAGERS
An ITO manager that is allowed to execute actions (via the ITO Action Agent) on the managed node and to which the action response (such as command broadcast) is sent. Only the primary ITO manager has the possibility to configure "action allowed" managers for an agent.
NODE
The NODE IP of the SECONDARYMANAGER.
DESCRIPTION
A string containing a short description of the SECONDARY MANAGER.
MSGTARGETRULE and MSGTARGETRULES
Rules to configure the MSGTARGETMANAGER.
DESCRIPTION
A string containing the description of the MSGTARGETRULE.
MSGTARGETMANAGER and MSGTARGET MANAGERS
Define a manager to which the agents send messages and action responses belonging to the OVO messages (result of automatic actions). Only the primary OVO manager has the possibility to configure "message target" managers for an agent. An OVO message is sent to exactly one OVO manager. This is also used to escalate messages from one manager to another manager.
TIMETEMPLATENAME
The name of the corresponding timetemplate.
OPCMGR
The NODE IP of the ITO Manager.
MSGCONTROLLINGMGR
Attribute for a "message target" manager in order to be able to switch control of a message themselves
NOTIFYMGR
Attribute for a "message target" manager in order to notify themselves. This is set by default if no attribute is defined for the "message target" manager.
ACKNONLOCALMGR
Attribute for a message rule to force a direct acknowledgement of a notification message on a "source" management server.
MSGTARGETRULECONDS, MSGTARGETRULECOND
These conditions tell the agent to which manager the specific messages have to be sent based on message attributes and/or time. The message agent evaluates the message target conditions by reading the file mgrconf (for example, on HP- UX 11.x: /var/opt/OV/conf/OpC/mgrconf). If the mgrconf file does not exist, the messages are sent according to the info stored in the /var/opt/OV/conf/OpC/primmgr file. If the primmgr file does not exist, messages are sent according to the info stored in the opcinfo (or equivalent schema) file.
DESCRIPTION
A string containing the description of the Messagetargetrule Condition. The message target conditions are also used to specify the escalation rules. In this case, the ITO manager evaluates the file /etc/opt/OV/share/conf/OpC/mgmt_sv/respmgrs/escmgrs and escalates the message to the appropriate target managers.
SEVERITY
Six types of the severity are available: Unknown, Normal, Warning, Minor, Major or Critical
NODE
A node can be given in different ways, for example: NODE IP 0.0.0.0 hpbbn; If the node is defined in the format IP <ipaddress> or IP <ipaddress> <string> you should normally use the ipaddress "0.0.0.0". The real ipaddress will then be resolved by the name services. It also useful to set the <string> containing the name of the system to $OPC_PRIMARY_MGR and the <ipaddress> to "0.0.0.0".
APPLICATION
A string containing the application name, such as "Omniback."
MSGGRP
A string containing the name of the message group, such as "Backup."
OBJECT
A string containing the name of the object, such as "/dev/cartridge."
MSGTYPE
A string containing the description of the message type.
MSGCONDTYPE
Two condition types are possible:
Match
True when this msgtype matched.
Suppress
True when this msgtype is not matched.

19.5.5.5 Forwarding All Messages with Time Criteria

The template syntax for forwarding all messages with no message filtering rules is shown as follows in the sample template. The segment of the template shows that the MSGTARGETRULECONDS is left with only a placeholder to indicate that all messages are forwarded and that other rules may apply, but there are no message filters based on message attributes. (In other words, the example demonstrates, that all messages go to manager M1 during "shift1." At other times subsequent rules apply.) MSGTARGETMANAGERS identifies the servers to which the messages are forwarded. The message target manager criteria will apply to the messages that occur during the time window called "shift1" in the TIMETEMPLATE. The MSGTARGETMANAGER includes the unique node identifier OPCMGR to which the messages are forwarded. The use of the IP 0.0.0.0 means that the local name resolution process should be used. The local name resolution could be the hosts file, NIS or DNS. The unique name of the server is on the line labeled OPCMGR IP 0.0.0.0 "M1". Replace the M1 with the actual server name. The OPCMGR message target could also be represented with the variable "$OPC_PRIMARY_MGR".


MSGTARGETRULES
MSGTARGETRULE
DESCRIPTION "target rule description "
MSGTARGETRULECONDS
# for all messages
MSGTARGETMANAGERS
MSGTARGETMANAGER
# target manager from 17:00 to 24:00 and 00:00 to 6:00
# from Monday to Friday
TIMETEMPLATE "shift1"
OPCMGR IP 0.0.0.0 "M1"

If the time for sending messages is twenty-four hours, seven days per week, use the special variable $OPC_ALWAYS.

19.5.5.6 Forwarding Some Messages without Time Criteria

The following example template example.M2 defines a MSGTARGETRULECOND condition for messages that have a MSGGRP (message group) attribute "databases." If the message group condition matches, the message is sent to the MSGTARGETMANAGER every time it occurs. The 24x7 clock is defined with the TIMETEMPLATE label by using the variable $OPC_ALWAYS.


MSGTARGETRULES
MSGTARGETRULE
DESCRIPTION "database messages"
MSGTARGETRULECONDS
MSGTARGETRULECOND
DESCRIPTION "Condition 1"
MSGGRP "databases"
MSGTARGETMANAGERS
MSGTARGETMANAGER
# every time
TIMETEMPLATE "$OPC_ALWAYS"
OPCMGR IP 0.0.0.0 "M1"

19.5.5.7 Forwarding Messages to the Primary Manager

The template example.M2 time template "shift1" defines the hours during which all other messages MSGTARGETRULE and MSGTARGETCONDS are both empty. When no message target rule or message target condition is defined, all the unmatched events are sent to the MSGTARGETMANAGER. The name of the target manager is represented with the variable $OPC_PRIMARY_MGR, which means to send the messages to the current primary manager.


MSGTARGETRULE
DESCRIPTION "other messages"
MSGTARGETRULECONDS
MSGTARGETMANAGERS
MSGTARGETMANAGER
TIMETEMPLATE "shift1"
OPCMGR IP 0.0.0.0 "$OPC_PRIMARY_MGR"
# the actual manager name is stored
# in an extra config file on the agent

19.5.5.8 Message-forwarding Syntax

The full keyword syntax is shown below.

Respmgrconfigs ::=
<respmgrconfigs> RESPMGRCONFIG DESCRIPTION <string> <respmgrconds> | e
respmgrconds ::=
SECONDARYMANAGERS <secondmgrs> ACTIONALLOWMANAGERS <actallowmgrs> 
[MSGTARGETRULES
 <msgtargetrules>]
secondmgrs ::=
<secondmgrs> SECONDARYMANAGER NODE <node> [DESCRIPTION <string>] | e
actallowmgrs ::=
<actallowmgrs> ACTIONALLOWMANGER NODE <node>[DESCRIPTION
<string>] | e
msgtargetrules ::=
<msgtargetrules> MSGTARGETRULE DESCRIPTION <string> <msgtargetrule> | e
msgtargetrule ::= MSGTARGETRULECONDS <mtrconditions>
MSGTARGETMANAGERS <msgtargetmgrs> |
MSGTARGETRULECONDS <mtrconditions>
MSGTARGETMANAGERS <msgtargetmgrs> ACKNONLOCALMGR
mtrconditions ::=
<mtrconditions> MSGTARGETRULECOND DESCRIPTION <string> <mtrcond> | e
mtrcond ::=
<mtrcond> SEVERITY <severity> |
<mtrcond> NODE <nodelist> |
<mtrcond> APPLICATION <string> |
<mtrcond> MSGGRP <string> |
<mtrcond> OBJECT <string> |
<mtrcond> MSGCONDTYPE <msgcondtype> | e
msgtargetmgrs  ::=
<msgtargetmgrs> MSGTARGETMANAGER TIMETEMPLATE <string> OPCMGR
 <node> |
<msgtargetmgrs> MSGTARGETMANAGER TIMETEMPLATE <string> OPCMGR
<node> MSGCONTROLLINGMGR |
<msgtargetmgrs> MSGTARGETMANAGER TIMETEMPLATE <string> OPCMGR <node>
 NOTIFYMGR | e
severity ::=
Unknown | Normal | Warning | Minor | Major |Critical
nodelist ::=
<node> | <nodelist> <node>
msgcondtype ::=
Match | Suppress
node ::=
IP <ipaddress> | IP <ipaddress> <string> |OTHER <string>
String ::=
"any alphanumeric string"
ipaddress ::=
<digits>.<digits>.<digits>.<digits>

19.5.6 Sample MoM Templates

The sample templates provided out-of-the-box are described here for reference. Refer to the

OpenView Operations Concepts Guide for more information.

escmgr template
Example template for the escalation feature. It is the template of management server M1. Example scenario: There are two management servers, M1 and M2. Management server M2 is allowed to escalate each message, at any time, to management server M1.
hierarchy template
Example template for escalation of messages to the Central Server MC. It is the template of management server MX (where X stands for 1,2,3…).
backup-server template
Example template for configuring a backup server. This template applies to management server M1. Example scenario: There are two responsible management servers, M1 and M2, where management server M2 is a possible backup server for management server M1.
followthesun template
Example template for the follow-the-sun feature. It is the template of management server (installation server) M2 for managed node A. Example scenario: There are three different responsible management servers, M1, M2, and M3. The responsibilities for node A are defined as follows: management server M1 is responsible for node A on weekdays from Monday to Friday from 17:00 to 24:00 and 0:00 to 6:00; management server M2 is responsible for node A on weekdays from Monday to Friday from 6:00 to 17:00; management server M3 is responsible for node A on weekends, Saturday and Sunday, from 0:00 to 24:00.
service template
Example template for service-oriented message distribution (competence centers). It is the template of management server M1 for all managed nodes. Example scenario: There are three management servers,
Database Service Center (DBSVC),
Application Service Center (APSVC), and a
Local Manager (M1). Independent of the time, each managed node of the Local Manager M1 sends its events as follows: events of "DATABASE" to Database Service Center DBSVC, and events of the applications "FINANCE" and "CAD" to APSVC. Other events (without "DATABASE," "FINANCE," and "CAD") are sent to the Local Manager M1.
example.m2 template
Example template for a combination of follow-the-sun and service center features. It is the template of management server (primary manager) M2 for managed nodes C and D. Example scenario: There are three different responsible management servers, M1, M2, and M3 and two managed nodes, C and D. The primary manager for these nodes is management server M2. In the period from 6:00 to 18:00, Node C and Node D send their events (without DB events) to the primary manager. In the period from 18:00 to 6:00, Node C and Node D send their events (without DB events) to management server M3. The DB events of both nodes are always sent to the competence center M1.
example.m3 template
Example template for the follow-the-sun feature. It is the template of the management server (primary manager) M3 for managed nodes E and F. Example scenario: There are two responsible management servers, M2 and M3, and two managed nodes, E and F. The primary manager for these nodes is management server M3. In the time period from 6:00 to 18:00, Nodes E and F send their events to the responsible manager M2. In the period from 18:00 to 6:00 Node E and Node F send their events to the management server M3.
hierarchy.agt template
Example template for the hierarchical management feature. It is the template for all nodes of management server M1. Example scenario: There are two management servers, M1 and MC. Management server M1 is configured as the primary manager for all nodes. Management server MC is configured as an action-allowed manager for all nodes. This allows the Management server MC to perform actions on the distributed managed node.
hierarchy.sv template
Example template for the hierarchical management feature. It is the template of the local managed node M1. Example scenario: There are two management servers, M1 and MC. This template makes sure that all regional management server (M1) messages are sent to the central management server MC.
hier.specmgr template
Example template for hierarchical management configuration. It is the template of the central/regional management server. Example scenario: There are regional management servers (for example, M1) and one central management server MC. All SNMP messages are sent to the $OPC_PRIMARY_MGR .and all other messages are sent to the central management server MC.
hier.time.spec template
Example template for hierarchical management configuration. Example scenario: This template is similar to the hier.specmgr template but it is time-based. There are two shifts: daytime (8:00 - 18:00) and nighttime (not between 6:00 - 18:00). During the daytime, all SNMP messages are sent to the $OPC_PRIMARY_MGR. All other messages are sent to the central management server MC. During the nighttime all messages are sent to the central management server MC.
hier.time.all template
Example template for the hierarchical management feature. This template describes a message scenario for use on the local management server M1. Example scenario: There are regional management servers (for example M1) and one central management server MC. There are two shifts: daytime (8:00 - 18:00) and nighttime (not between 6:00 - 18:00). During the daytime all messages are sent to the $OPC_PRIMARY_MGR .and during the nighttime all messages are sent to the central management server MC.
msgforw template
Example template for the message-forwarding feature. Template msgforw of local management server. Example scenario: There are five management servers dbexpert, dbnotify, applinfo, master, and the local management server. All DATABASE messages are sent to the management servers dbexpert, dbnotify, and the local management server. The control of the message is passed to dbexpert. On the local management server, the DATABASE messages are acknowledged directly. All messages concerning CAD applications are sent to the management servers applinfo for information (no control). All critical messages coming from nodes x1 or x2 are sent to management server master for information (no control).