لطفا منتظر باشید ...
14.6 POLICIES
Policies are the heart of the agent configuration. They give the agent intelligence via management rules that enable the agent to intercept events or collect data from information sources. A policy includes a complete set of rules (also called conditions) to handle a single information source such as a logfile. Information for the policies is generally created through the GUI. The policy instructs the agent on how to access the source, and what the "rule" is for managing the source (for example, what events to act on or suppress). The default policy templates are installed on the management server. Many policies are ready to configure out-of-the-box due to the
Smart Plug-In (SPI) concept used to develop the policies. Refer to Chapter 15, "Smart Plug-Ins," for more information on SPIs. It may be necessary to copy and customize a default policy. For example, you may need multiple policy groups with different monitoring, alarm, and notification thresholds for multiple node groups. After the policy is customized, it is assigned and distributed to the managed node or node group. Prior to distribution to the DCE-based managed node, the policy is also called a template. During distribution the template is converted to a policy. Verify the policies that are deployed with the command
ovpolicy . This section refers to templates in order to be consistent with the configuration components inside the GUI.
14.6.1 Working with Policy Templates from the GUI
As we have seen in a previous section of this chapter, the template interface in the GUI is called Message Source Templates. After you decide which template type you need, the next steps include:
Select that template type from a default group or add a new template group.
Create a new template in the template group or copy and rename an existing template into the new group.
Add your customizations.
Assign the template to the node.
Distribute the template.
Look at the template customization concepts.
Select Window
Message Source Templates to bring up the Template Window, as shown in Figure 14-4. The default templates are listed on the right side. If you double click on the template group name, the left panel displays the detailed list of templates for the group selected from the listing on the right side.
Figure 14-4. The Message Source Templates interface is used to configure the rules/policies for the agent.
This section provides descriptions of the different template types. Each template type provides a primary template window. After the primary template is configured, add conditions to each template. The conditions determine what "rule" is used to generate a message and if the message is forwarded to the management server or suppressed. When working with the template GUI, you can obtain on-line Help information for each field of a template. Place the cursor in any field of a template to make this the active field and select the F1 key on the keyboard. This opens the HELP interface for the specific field.
14.6.1.1 Logfile Templates
The task of application monitoring extends to periodic evaluation of the entries in an application's logfile (or other event information file). The entries in the logfile are evaluated one line at a time. During parsing, the agent examines a list of conditions for each line of the file. When a match is found between a line in the logfile and a condition, the condition statement triggers further processing as required (for example, to produce a message or execute actions). The parsing of the lines in the logfile continues until a match condition is found and then processing of the logfile stops.
There are two types of log files, ASCII and binary. The list here describes the features of the OVO logfile configuration environment shown in Figure 14-5 and 14-6.
OVO reads an ASCII log file without help from other programs.
Binary log files require the help of an outside program to extract the content into ASCII format. OVO will read the information from the newly created ASCII file. For an example, examine the Bad logins logfile.
In the match conditions section of the template, OVO expects a syntax (similar to grep or sed) to parse each line in the logfile.
When a pattern match is found, a message is created using the information found in the attributes section of the template.
The conditions determine if the event will be suppressed or if the event will be passed to the server in the form a message.
The conditions will cause one of two things to happen when a pattern match is found. Send a message or Suppress the event.
A shortcut to the pattern match syntax is built into the Template Conditions window. Place your mouse inside the pattern match field and press the right mouse button. This opens a pop-up menu with the pattern match syntax. This also works in the object pattern field for a monitor template condition and the variable bindings of the trap template. This allows you to easily convert a typical input line into the required OVO pattern: For example, to copy an input line from your file and paste it into the match field, highlight the portions of the input pattern you need to replace with a regular expression. Right-click and select the particular regular expression "constructor" which will then replace your highlighted portion of the input line.
You can test the pattern match syntax against a logfile from the Conditions window by using the test pattern matching button at the bottom of the screen. Provide the name of the logfile. Your pattern will be tested for match and unmatched lines in the logfile. This allows you to immediately correct the pattern syntax to ensure that you filter the correct information. You can test a list of conditions from the Message and Suppress Conditions window.
Figure 14-5. Logfile Template window contains the information about a specific template.
Figure 14-6. Logfile Template Conditions window is used to configure the rules that apply to the agent.
14.6.1.2 Monitors
A monitor program is used to collect information from a monitored object and send the results of the data collection to the monitor process using the
opcmon command (or API). The information is evaluated against the values in a monitor template, shown in Figure 14-7, to determine if the monitor value violates the threshold.
Figure 14-7. The Monitor Template window is used to describe the attributes of a monitor.
During execution, the monitor template is used by the monitor program to send or suppress messages. The process to accomplish this task is summarized in the following list.
The monitor process (opcmona) executes an external program or script to determine the status of system or application run-time parameters. For an example, examine the swap_util monitor template.
The external program or script (called a monitor program) submits the value to the agent using the program called opcmon. Refer to the man page for more details about the opcmon program.
The agent compares the value against the threshold (high or low) configured in the template.
A message is generated based on the threshold criteria.
A list of conditions (see Figure 14-24) determines if a message is sent to the server or suppressed.
Figure 14-24. The System Logfile Message and Suppress Conditions window lists the match and suppress conditions in the order they are applied to the messages.
Figure 14-8. The Monitor Condition window shows an example for cpu utilization.
It is possible for OVO to access MIB variables, MS Performance Monitor Logs, and Embedded Performance Component Collections. These sources do not require a script or call to opcmon to their variable values. Select the Program Button on the template window (see Figure 14-4). The other options in the list are MIB Object or External.
The program option without the path assumes that the monitor program is distributed to the managed node along with the policy. The MIB Object requires the MIB ID. External programs provide data to OVO via the program API opcmon. For example, with MS Performance Logs use syntax similar to the following in the Program Monitor field:
NTPerfMon\\FTP Server\\Current Connections\\_Total
This determines what the number of current FTP connections.
When collecting metric data via the embedded performance component, use syntax similar to the following in the Program Monitor field:
OVPERF\\CODA\\GLOBAL\GBL_CPU_TOTAL_UTIL
The name of the monitor used in the monitor script or monitor program must match the name of the monitor template. Example: opcmon monitor_name=value. The monitor_name and the monitor template name must match.
14.6.1.3 Messages
Message interception is the process of providing parameters to the
opcmsg command (or API) that will submit the information to the message interceptor for processing and then to the message agent for delivery to the management server. The message command can be executed at the command line or included inside a script or program.
The message and suppression options are summarized in the following list. An example message template window is shown in Figure 14-9.
The command (or API)
opcmsg submits messages to the message template.
The message template is configured to check for the attributes of the incoming message.
If the message from the
opcmsg command matches the template conditions, a message is created and sent to the server
The message can be suppressed if the conditions list of the template contains the rule for suppressing messages.
You can test the pattern match for messages from the command line with the command /opt/OV/bin/OpC/opcmsg. If you want to match specific criteria of a message, include the message attributes on the command line. Example: opcmsg sev=major a=myapp o=process_name msg_g=customer msg_t="Application not running" In this example a=application, o=object, msg_g=message group, msg_t=message text. The required opcmsg d parameters are application, object, and message text; the others are optional.
There are more command line parameters (see the man page). The options in the example have the following meaning: The parameters correspond to the fields in the message browser as follows: sev=Severity, a=Application, o=Object, msg_g=Message Group, msg_t= Message Text. See Figure 14-6 for a pattern match syntax example.
If you add a parameter to the command line that is not configured in the template, the message will show in the browser as unmatched after the following criteria are met. In cases where the template condition attribute is left blank, this is treated as a match. The empty condition field is treated as "anything goes." Only after all conditions have been examined (in an effort to match) and no match happens, OVO will look at a template "Option" value (such as Forward unmatched messages). If the forward unmatched is enabled, then the unmatched message is sent to the server.
Figure 14-9. The Message Template window is used to define a message.
14.6.1.4 Traps
The SNMP trap originates on a device and is an indication of an event that has occurred on the device. If the trap destination at the device is configured to send events to the OVO trap interceptor (opctrapi) running on a managed node or the management server, the trap is processed and converted into a message based on the trap template conditions. An example trap template and trap condition window is shown in Appendix C for resource information about SNMP.
Figure 14-10. A Trap Template instructs the trap process (
opctrapi ).
Figure 14-11. Trap Template Condition.
Chapter 1, "Introduction to NNM, CIV, and SIP," for more information about SNMP.
If the criteria for the trap are matched by the configuration of the trap template, a message is generated.
The message will contain the attributes configured in the template.
The message suppression rule could also apply.
The OVO trap template contains over 300 readily available trap conditions that the management server handles.
If the OVO node is configured with a trap template, it forwards the traps it receives to the server in the form of a message (if the suppression rule is not applied).
14.6.1.5 Schedule template
During operations, daily, weekly, or monthly routine tasks are generally scheduled via the UNIX cron process. OpenView has an internal environment similar to the cron process. Configure a schedule template, as shown in Figure 14-12, to execute programs and commands at scheduled times. One example of using the schedule plate is recurring download of the database history using the opchistdwn command.
Figure 14-12. Schedule Templates are used to execute programs or commands are predetermined (scheduled) intervals.
14.6.1.6 Message Forwarding Templates
A message forwarding template (msgforw) instructs the agent to send messages to another server if necessary. This template configuration is covered in more detail in Chapter 19, "Enterprise Management Flexibility with Multiple Servers."
14.6.1.7 Outage Template
The outage template instructs the server buffer to log into the database or ignore messages from the managed nodes based upon service level arrangements or maintenance schedules. This template configuration is covered in more detail in the HP OpenView Operations Concepts Guide.
14.6.1.8 Message Regrouping Template
Messages that arrive on the management server contain a message group attribute. It is possible using the message regroup template to override the message group attribute. If the message is regrouped, it will contain the regrouped message attribute. This feature allows someone who is in on different team to see the regrouped messages. The regroup template is located on the management server. Select
ActionServerRegroup to open the regroup template conditions window shown in Figure 14-13.
Figure 14-13. The Regroup Condition changes the original message group attribute on messages that match the regroup condition.
14.6.2 Working with Template Files
Configuration of the templates is done primarily through the GUI. OVO flexible management templates and other specialized templates (such as Service Navigator or Service Hours) are created and modified with a text editor. Refer to Chapter 20 for more information on flexible management templates.
14.6.2.1 Template Format
A brief description of the sections of a typical logfile template is included here for reference. The template has the same information that is required when configuring a template from the GUI. The template name, description, logfile path, and so on are required parameters. The exefile is the file to be executed (as described in Section 14.1.2, "The Agent Processes"). The entries in the logfile are always read from the beginning (ALWAYS FROM BEGIN) and the file is closed after it is read (CLOSE AFTER READ). The default message attributes will set the message SEVERITY, APPLICAITION, MSGGRP, and OBJECT as they are to appear in the message browser. The SERVICE_NAME describes the service that this event will be associated with and is used by the Service Navigator service engine process to update the service views. The file includes a detailed look at the conditions for the template and includes the condition text. The pattern syntax used throughout the template forms the basis upon which the lines in the logfile will be parsed. The default OBJECT attribute is changed to the "<user>" that is the variable defined in the CONDITION TEXT. The message TEXT displays the user name of the failed login, the terminal, host, time, and date of the failed login.
14.6.3 Template Administrator
Planning, organizing, development and implementation of the templates can be a very big job. The configuration, customized scripts, and deployment strategy for the templates requires a dedicated effort. Sometimes the OpenView Administrator is responsible for these tasks in addition to other important duties. However, in many environments an OpenView Template Administrator coordinates template development activities.
Configure the Template Administrator account from the User Bank. Select
WindowUser BankActionUserAdd . See Figure 14-14. The Template Administrator manages, and creates the templates that will be deployed into the OVO domain. This OVO account is provided a limited GUI console environment during its OVO session. The GUI interface is the Message Source Template window. See Figure 14-15.
Figure 14-14. User configuration interface for the Template Administrator account.
Figure 14-15. Template Administrators work from the GUI for message source templates.
The Template Administrator must inform the OVO Administrator when templates are ready for distribution. The distribution function is performed only from the OPC Administrator GUI or from the command line at the server as root.
Only one OVO Administrator session is allowed at a time, but there can be multiple Template Administrator sessions working in parallel.
14.6.4 Template Groups
The first step in the process for creating customized template is to create a new template group. This helps organize the templates into logical groups. The default templates are links to one source file. You can see the same template name in multiple template groups. When you change the template in one group it also changes in the other groups. It is the same file. A good practice for template management is to create new template groups, create new templates, or make copies and rename the source templates. With this method during an upgrade, your custom templates are protected. Also, when creating a new template group, provide a name for the template group that will place it alphabetically before the standard template groups. OVO matches the names of the template groups in the order of the template group layout. The template groups are also organized according to the installed SPIs. However, if necessary you can create your own template group as outlined in Section 14.6.4.
14.6.4.1 Process to Create a New Template Group
Follow these steps to create a new template group:
Open the Message Source Template window.
On the left side of the screen, double-click
Top Level .
Move the mouse to the upper right corner, click and hold down the right-mouse button, and click
Add Logfile .
In the menu list, select
Add Group .
If you open the Logfile Template window, click
Cancel and try again.
Enter a Template Group Name and Description; click
OK as shown in Figure 14-16.
Figure 14-16. Use the Add Template Group window to create a unique template group.
Figure 14-17 shows the new template group Customer_1 in the Message Source Template Window.
Figure 14-17. The name of the custom template group is listed with other templates in the Message Source Templates window (partial view of the window).
14.6.4.2 Copy and Paste Templates into a Template Group
To use a default template as a baseline for creating your own customized templates, use the following procedure:
In the Message Source Template window, the template or template group select (click once to highlight it). This is the template you should copy. Select from the menu
Edit
Copy .Select the New Message Source Template Group and select from the menu
Edit
Paste .The template appears in the list. At this point you have created another link to the original template from your new template group. In the next steps, you will create a new name for your copy of the original template and it will no longer be a link to the original.
Select the template or template group (click-once to highlight).
Select
Copy from the list of options on the right side of the window.
Change the name of the template and select
OK (or you could begin to work on the template modifications). Just remember to give the template a new name.
When the copy is complete, you'll see the new template and the original.
Remove the original template from the New Template Group. Select the template and Click-Delete From Group. Be careful: Do not remove the default templates from the Default groups.
You now have a new template group that contains a renamed version of the original template.
Close the Message Source Template 2 window and select
Note
If you need to restore the default configuration, a copy is created during installation and stored in the directory /var/opt/OV/share/tmp/OpC_appl/defaults.
14.6.5 Template Assignment
Check the template to node assignments shown in the Define Configuration window. For example, select the Node Bank and
ActionsAgentsAssign Templates . After the template assignment is confirmed, click OK. If you need to assign a template, follow the steps in the next list. At this time, the template assignment has made no changes to the agent. The template becomes active on the agent only after distribution of the policy to the managed node.
14.6.5.1 Template to Node Assignment
Select the node in the Node Bank.
Select
Actions
AgentsAssign Templates .If from the previous copy/paste example the template is still selected in the Message Source Template Window, after the Add Configuration window opens you will see the selected templates or template groups in the list, on the right side. Verify the node for the template on the left side of the Add Configuration window and add a node (or nodes) to the list if necessary. The nodes you add to the list will be assigned the templates on the templates on the right side of the window. Click
OK . Go to step10.
If there are no templates in the list on the Add Configuration window, or if you need to add more templates to the list, click
Open Template Window .
Select the templates or template groups in the Message Source Template window.
Leave the Message Source Template window open.
Return to the Add Configuration window and click Get the Selected Templates. This will fill in the list of templates.
Verify the node list on the right and click OK.
In the Define Configuration window, click OK.
You are finished with the template to node assignment.
There is a difference between assigning single templates to the node versus assigning template groups. When assigning template groups, all member templates will automatically be assigned. As templates are added to existing template groups they are assigned and distributed as members of the group.
14.6.7 Template Files
The template configuration is stored in the database on the management server. During a template distribution to a node, a template file is transferred to the node in binary, encrypted format.
14.6.7.1 Templates on the Management Server
The template files are deployed as required to provide the necessary instrumentation for the agents on the managed node or server. Some specialized template files add additional capability to the agents on the server or node, for example
manager of managers (MoM). The template files that provide the basis for the flexible management concepts are found in the following directory: /etc/opt/OV/share/conf/OpC/mgmt_sv/templates. Other types of templates that instrument the agent for specialized management, monitoring, corrective actions and alarming could be installed on the server as SPIs. More details of the flexible management templates are covered in Chapter 19.
14.6.7.2 Templates on the Managed Node
The templates are referred to as policies after they are distributed to the managed node. The policy files contain policy data, one file for each policy type. In prior releases, a template file would contain the entire set of templates. The policy files represent each individual template. The policy files are maintained in the directory /var/opt/OV/data/image/library/english/10090_policies. The directory path is identified with the variable $DATADIR where DATADIR=/var/opt/OV. An example of the policy directory contents is shown here for reference.
# cd /var/opt/OV/data/image/library/english/10090_policies
# ls -l
total 10
drwxr-xr-x 2 root root 1024 Nov 22 21:36 le
drwxr-xr-x 2 root sys 1024 Oct 13 20:08 mgrconf
drwxr-xr-x 2 root root 1024 Nov 22 21:36 monitor
drwxr-xr-x 2 root root 1024 Nov 22 21:36 msgi
drwxr-xr-x 2 root root 1024 Nov 22 21:36 trapi
# cd le
# ls
5324c9f4-fa46-71d7-1fc7-9c99d13d0000_data
5324c9f4-fa46-71d7-1fc7-9c99d13d0000_header.xml
532a13d2-fa46-71d7-1fc7-9c99d13d0000_data
532a13d2-fa46-71d7-1fc7-9c99d13d0000_header.xml
5331f700-fa46-71d7-1fc7-9c99d13d0000_data
5331f700-fa46-71d7-1fc7-9c99d13d0000_header.xml
A listing of a policy data file is shown here.
# more 5324c9f4-fa46-71d7-1fc7-9c99d13d0000_data
SYNTAX_VERSION 5
LOGFILE "Bad Logs (10.x/11.x HP-UX)"
DESCRIPTION "History of HP-UX 10.x/11.x
bad logins (/var/adm/btmp logfile)"
LOGPATH "/var/adm/btmp"
EXEFILE "opcfwtmp /tmp/btmp.stat /var/adm/btmp /tmp/btmp.out"
READFILE "/tmp/btmp.out"
INTERVAL "10s"
CHSET ISO88591
ALWAYS_FROM_BEGIN
CLOSE_AFTER_READ
SEVERITY Warning
APPLICATION "/usr/bin/login(1) Login"
MSGGRP "Security"
MSGCONDITIONS
DESCRIPTION "Failed remote login"
CONDITION_ID "53259b2c-fa46-71d7-1fc7-9c99d13d0000"
CONDITION
TEXT "FAILED <@.user> <@.tty> <@.host> <*.date> <*.time>"
SET
OBJECT "<user>"
TEXT "Failed login of <user> on <tty> at <time> <date>"
DESCRIPTION "opcfwtmp failure"
CONDITION_ID "53277c26-fa46-71d7-1fc7-9c99d13d0000"
CONDITION
TEXT "opcfwtmp:"
SET
SEVERITY Critical
MSGGRP "OpC"
OBJECT "opcfwtmp"
TEXT "<$MSG_TEXT>"
14.6.5 Template Status
Use the
ovpolicy command to view, activate and deactivate templates on the managed nodes. Use the
opcragt command (or the Administrator's GUI) to distribute the templates. A template is converted to a policy data file during HTTPS-based distribution. An example of viewing the installed policies is shown here.
# ovpolicy -list
List installed policies for host: 'lotus'.
TypeName Name Status
-
'le' 'Bad Logs (10.x/11.x HP-UX)' enabled
'le' 'Cron (10.x/11.x HP-UX)' enabled
'le' 'Syslog (ServiceGuard)' enabled
'mgrconf' 'OVO authorization' enabled
'monitor' 'cpu_util' enabled
'monitor' 'disk_util' enabled
'monitor' 'distrib_mon' enabled
'monitor' 'mondbfile' enabled
'monitor' 'proc_util' enabled
'msgi' 'opcmsg(1|3)' enabled
'trapi' 'SNMP 6.20 Traps' enabled
'trapi' 'SNMP ECS Traps' enabled
14.6.5.1 ovpolicy and opctemplate
Use the command
ovpolicy to verify status, install, remove, enable, and disable local policies. The command
opctemplate is a wrapper command for
ovpolicy . Refer to the man page for a complete listing of the
14.6.5.2 Temporarily Disabling and Enabling a Template
It might be necessary to temporarily disable the policies during times of maintenance on applications that are monitored by OVO. This would prevent the agent from sending any information about events or performing actions that are triggered by the policy. When a policy is disabled, there are no messages created for that policy.
Use the command
ovpolicy (or
opctemplate ) to change or check the status of policies. For example, changing the policy status to disabled prevents the events from a particular policy from arriving in the message browser. Another advantage is that this method does not require completely disabling the entire agent and also avoids the task of unassign and later assign the template. This command requires root user permission.
