Configure Log File Entry Policies

Automatic command

Automatic command that runs when the rule is matched. For example, you could configure a log file entry policy to automatically delete the contents of C:\Temp when the log file contains "The C: disk is at or near capacity."

By default, the command runs as the agent user ($AGENT_USER). Alternatively, select Non Agent User and specify a user account and password that exists on the node:

• Username. Runs the command under the specified user account. The account must exist on the node.

• Password. Password of the specified user account.

• Enable Policy Parameter in password field. Enables you to enter a variable in the Password field, for example %%password%%. A corresponding policy parameter should exist in the Policy Parameters tab.

Name of the node on which the command will be started. You can also use the variable <$MSG_NODE_NAME> to configure reusable policies for replicated sites.

Closes the event automatically if the command is successful.

Options that can help to reduce the amount of unnecessary network traffic to the OMi server. For example, if an automatic command solves the problem that generated the event, you may choose not to inform the OMi server.

• Send the event

• Send the event if the local command fails

• Send the event only if the local command is successful

Operator-initiated command

Operator-initiated command that is attached to the event that the rule sends to OMi. This command can be started by the OMi user from the Event Browser. The command might be a script that requires user input to solve the problem, or instructions that appear in a Web browser.

By default, the command runs as the agent user ($AGENT_USER). Alternatively, select Non Agent User and specify a user account and password that exists on the node:

• Username. Runs the command under the specified user account. The account must exist on the node.

• Password. Password of the specified user account.

• Enable policy parameter in Password field. Enables you to enter a variable in the Password field, for example %%password%%. A corresponding policy parameter should exist in the Policy Parameters tab.

Name of the node on which the command will be started. You can also use the variable <$MSG_NODE_NAME> to configure reusable policies for replicated sites.

Closes the event automatically if the command is successful.

URL of the event in a third-party system. This is the complete path of the URL, and includes the FQDN (fully qualified domain name) of the computer that hosts the third-party system, the communication port, and the root URL path (for example, http://nnmi.example.com:8004/nnm/launch?cmd=showForm&objtype
=Incident&objuuid=$OPC_CUSTOM[nnm.incident.uuid]&menus=true).

Event drilldown information enables OMi users to launch the user interface of the third-party system in the context of an event.

Application that caused the event to occur. Unlike the Related CI attribute, which is a direct relationship to a CI in the RTSM, the application attribute is a simple string-type attribute (for example, Oracle and OS).

Device such as a computer, printer, or modem. Unlike the Related CI attribute, which is a direct relationship to a CI in the RTSM, the object attribute is a simple string-type attribute (for example, C:, and /dev/spool).

String used to organize different types of events within an event category or subcategory (for example, users or applications, accounts and security).

ID of the service associated with the event. A service ID is a unique identifier for a service and can be used in OMi to identify the node and CI associated with the event.

The message stream interface (MSI) allows external applications to interact with the internal event flow of the agent. The external application can be a read-write application, for example, an event processing program that can read events, modify attributes, and generate new events for retransmission to the server. The application could also read events, or send its own events.

Divert events. Divert an event to the MSI instead of to the server when an event is requested by an external application.

Copy events. Send the event to the server, and a copy of the event to the MSI.

If the agent MSI is enabled in the event defaults, you can choose to apply them to or override them for this rule:

Use default settings for Agent MSI. Applies the agent MSI settings configured in the event defaults to this rule.

Override default settings for Agent MSI: Enables you to configure specific agent MSI settings for this policy rule.

Fully qualified domain name, node name, or IP address that the policy compares with the node in the log file line. Type a value in this field to match the log file line from a specific node.

Separate multiple entries with the OR operator (|) or leave blank to match all nodes.

Example: celery.example.com|broccoli.example.com

Pattern that you want the policy to compare with the log file line.

Create New Custom Attribute: Creates a new custom attribute with the default name CA_n. To rename the custom attribute, double-click the name to select it and type the new name.

The name of the custom attribute. The name is case-insensitive.

Custom attributes are additional attributes that contain any information that is meaningful to you. For example, you might add a company name, contact information, or a city location to an event. You can have more than one custom attribute attached to a single event.

The following custom attribute names cannot be used because they are reserved for internal use:

Description

EtiHint

HP_OPR_SAAS_CUSTOMER_ID

NoDuplicateSuppression

RelatedCiHint

SourceCiHint

SourcedFromExternalId

SourcedFromExternalUrl

SubCategory

SubCiHint

Value of the custom attribute.

Title

Brief description of the nature of the event.

Description

Detailed description of the event.

Severity

Severity assigned to the event (Critical, Major, Minor, Warning, Normal, Unknown).

Category

Name of the logical group to which the event belongs (for example, Database, Security, or Network). The event category is similar in concept to the HP Operations Manager message group.

Subcategory

Name of the logical subgroup (category) to which the event belongs (for example, Oracle (database), Accounts (security), or Routers (network)).

ETI

Contains the event type indicator (ETI) resolution hint, which OMi uses to associate the event with an ETI and for event correlation.

Use the format <ETI name>:<ETI state>:<metric value>. Specify the name of the indicator (for example, CPULoad), the indicator state (for example, High), and, optionally, the metric value (for example, 80). When OMi receives an event with an ETI resolution hint of CPULoad:High, and the ETI and state exist, the Event Type Indicator attribute is set to CPULoad:High in the event. The metric value is optional and serves informational purposes only.

Node

Name of the system where the event occurred (for example, node.example.com).

Information used to identify a subcomponent of a CI. This CI subcomponent is used to calculate an aggregated status within OMi's Service Health for selected CIs.

If an HI is populated by events from multiple components, you can specify a component name in this field in order to ensure the correct calculation of the HI state.

For example, if you have a Computer CI with two CPUs, cpu #1 and cpu #2, events from both CPUs will be sent to the same CPU Load HI. By default, the events will override each other and create an incorrect HI state. To prevent this, you can populate Sub Component with values "cpu #1" and "cpu #2" which will cause the HI state to be calculated as an aggregated state between the two events.

Source CI

Contains the source related CI. For example, type the name and instance of the OMi server that provides events (for example, OMi@@mgmt.example.com).

If you enter a source related CI, OMi tries to find the corresponding CI in the RTSM.

Source Event ID

Reserved for future use.

Send with closed status (For the Open Message Interface, SNMP Interceptor, and Scheduled Task policies)

Sets the event's lifecycle status to Closed before sending it to OMi.

If events with the event key that you type here exist in the OMi event database when this event is received, these events are automatically closed. You can use pattern matching and variables to match multiple event keys. For example, consider the following pattern:

<$MSG_SEV>:<$MSG_NODE_NAME>

This pattern is evaluated by first replacing the variables with the values that they resolve to, for example:

critical:cabbage.example.com

This pattern is then compared using pattern matching rule against the event keys for all events in the OMi event database. Any key that you provide in the policy is treated as a simplified OM pattern in OMi. Therefore a plain string is treated as a substring and not as a complete match. The key in our example will match:

critical:cabbage.example.com:TEST
critical:cabbage.example.com:TEST1
critical:cabbage.example.com:TEST2A

and so on.

To ensure that that the key matches only exact values, enclose the attribute value in an OM Pattern Expression, starting with ^ (start of line) and ending with $ (end of line), for example:

^critical:cabbage.example.com:TEST$

Enables event suppression for the events generated by this policy.

If event suppression is enabled in the event defaults, you can choose to apply them to or override them for this rule:

Use default settings for Event Suppression. Applies the event suppression settings configured in the event defaults to this rule.

Override default settings for Event Suppression: Enables you to configure specific event suppression settings for this policy rule.

• Generated by the same input event. Select this option to suppress events that were sent in response to two separate input events that are identical except for the date and time that the event was generated (for example, identical entries in a log file).

• Generated by the same rule. Select this option to suppress events that match the pattern specified for the selected rule. This is a more general setting for the suppression of duplicate events. For example, a policy might contain a rule with this match pattern: Error Message<#> The log file lines Error Message10 and Error Message20 are not identical, but would both match this rule.

• Identical relative to their attributes. Select this option to suppress either events that have the same event key or (if no event key is present) events that have identical event attributes (except for the date and time that the event was generated).

Time interval during which duplicate events are ignored.

To modify the time, click the button and use the drop-down lists to specify increments of days, hours, minutes, or seconds.

To insert a parameter in a time field, type the parameter in the format %%<VariableName>%% or drag and drop the parameter from the Policy Parameters tab. When dropping a numeric parameter in a time field, the policy editor appends an s to the parameter to indicate that the parameter specifies the time in seconds (for example, %%interval%%s).

Time interval after which duplicate events are no longer ignored.

To modify the time, click the button and use the drop-down lists to specify increments of days, hours, minutes, or seconds.

To insert a parameter in a time field, type the parameter in the format %%<VariableName>%% or drag and drop the parameter from the Policy Parameters tab. When dropping a numeric parameter in a time field, the policy editor appends an s to the parameter to indicate that the parameter specifies the time in seconds (for example, %%interval%%s).

Time interval after which the counter is reset to 0.

To modify the time, click the button and use the drop-down lists to specify increments of days, hours, minutes, or seconds.

To insert a parameter in a time field, type the parameter in the format %%<VariableName>%% or drag and drop the parameter from the Policy Parameters tab. When dropping a numeric parameter in a time field, the policy editor appends an s to the parameter to indicate that the parameter specifies the time in seconds (for example, %%interval%%s).

Refresh. Loads the configured indicators from the OMi server.

Entered search string is used to search the indicators and highlight only the indicators containing the specified string.

To search for indicators with specific text strings in the name, type the string in the <Search …> field and click the button. The first matching indicator is selected in the list of rules. Click the and buttons to move to the previous and next matching indicator.

Hierarchy of configuration item types with associated health indicators (HIs), which are applicable for the event integration only, and event type indicators (ETIs). To insert an indicator with a state in a policy, drag and drop the indicator from the Indicators tab to the relevant field in the policy.

You can select one of the following options from the Type drop-down list:

• Use defaults. Select if you do not want to use instructions that accompany the event.

• Instruction Text. Select if you want to add the instruction text to accompany the event. Enter the text directly in the Instruction Text field.

  Note that you can type URLs in the text. The Event Browser automatically converts them into clickable hyperlinks. For example, you can add URLs of external websites, support sites, documentation repositories, troubleshooting information, and similar.

  To add a link, type any URL that begins with one of the following URI scheme names:

  • http://

  • https://

  • ftp://

  • ftps://

  • mailto:

  • telnet://

  • file://

  You can also just type the address of any website that begins with www..

• Instruction Text Interface. Select if you want to use the external instructions interface to generate instructions. Type the name of the external instructions interface in the Interface name field and enter Parameters that will be passed to the instruction text interface upon the instruction text retrieval (these parameters will get resolved by the agent before the message is sent to the server).

  In Parameters, you can enter a policy variable or a policy parameter configured for this policy template (note that you can also enter a parameter as a value in the Interface name field). Supported policy variables include (but are not limited to):

  • <$MSG_APPL>: Returns the name of the application associated with the event.

  • <$MSG_NODE>: Returns the IP address of the node on which the original event took place.

  • <$MSG_NODE_NAME>: Returns the hostname of the node on which the original event took place (this is the hostname that the agent resolves for the node).

  • <$MSG_ID>: Returns the unique identity number of the event.

  • <$MSG_SEV>: Returns the default value for the event severity.

  • <$MSG_TEXT>: Returns the full text of the event.

  A list of supported variables is available in the Policy Variables tab. For a complete list of HPOM variables and their descriptions, see the HPOM documentation.

Options in events policies:

Options in metrics policies:

Pattern Matching Options

Defines case sensitivity and field separators for all rules.

Defines which characters should be considered to be field separators. Field separators are used in the pattern as separator characters for the rule condition. You can define up to seven separators, including these special characters:

For example, if you wanted a backslash, an asterisk, and the letter A to define the fields in the event, you would type \\*A (with no spaces separating the characters).

If you leave this box empty, the default separators (a blank and the tab character) are used by default.

You can set case sensitivity and separator characters for individual rules in a policy by clicking the button in rule's match condition.

Applies the pattern matching options to all existing rules in a policy. This overwrites any modifications made to the pattern matching options in individual rules.

If you change the pattern matching options and do not click Apply to all, they only apply to all new rules in a policy.

Load From Local File System: Click to open the Select file to upload dialog box. Use the dialog box to upload a policy file. Policy files are data files and their filenames end in _data.

Save To Local File System: Click to download the policy to a policy data file on your system. You can then update the policy more comfortably in an editor of your choice. After completing your changes to the policy, upload the policy data file by clicking the Load From Local File System button.

The policy editor automatically asks you to download policies that exceed 1 MB in file size.

Check Syntax: Validates the syntax of the policy data. If the policy syntax is incorrect, the validation tool reports an error and points to the corresponding line and position of the unexpected token (for example the incorrect keyword).

Policy data in text form. The data uses the HPE Operations Agent policy syntax.

The policy editor highlights the policy syntax. If the policy exceeds 1,000 lines, syntax highlighting is automatically disabled. If the policy exceeds 1 MB in file size, the policy editor automatically asks you to download the policy to a file.

Synchronize Parameters: Check the policy template to make sure that variables in the format %%<variable_name>%% have corresponding parameters. Each variable should have one corresponding parameter.

Also checks for unused parameters, for which no corresponding variable exists in the policy template.

If any missing or unused parameters exist, the Synchronize Parameters dialog box opens. Read the summary, and then click Change or Ignore. If you click Change, the missing parameters are automatically created, and unused parameters are automatically deleted.

List of parameters configured for this policy template.

Parameters enable you to create policy templates that other users can easily customize. Each parameter corresponds to a variable in a policy template. A parameter gives consumers of a policy template the opportunity to specify the value of a variable, without having to modify the policy template themselves.

To insert a parameter, drag the parameter from the Policy Parameters tab to any text field within a condition or an event definition in a policy template. Alternatively, type the parameter in the text box using the format %%<variable_name>%% (for example %%CriticalThreshold%%).

An icon represents the type of parameter value, which can be one of the following:

• Enumeration (of several options)

• Number

• Password

• String

Entered number is used to select the rule with that sequence number in the list of rules.

To select a specific rule in the rule list, type the rule's sequence number in the <Move to> field and click the button.

Entered search string is used to search the rule descriptions and highlight only the rules containing the specified string.

To search for rules with specific text strings in the rule description, type the string in the <Search rules> field and click the button. The first matching rule is selected in the list of rules. Click the and buttons to move the previous and next matching rule.

Options in events policies:

Options in metrics policies:

You can change the rule type by clicking the current rule type in the list of rules and selecting another rule type from the drop-down list.

Returns the IP address of the node that sends the event. Sample output: 192.168.1.123.

Name of the policy. You can use spaces in the name. The equal sign (=) is not allowed.

The name is set when the policy is created and cannot be changed in new versions of a policy.

The current version of the policy. If you modify an existing policy, you create a new version of the policy in the database with a unique version number. By default, the minor version number increases by one automatically after you modify the policy and save it. If you want to save the policy with a specific version number, you can select the major or minor version number that you want. It is not possible to replace an existing version of a policy. However, you can delete a specific version of a policy.

Text that describes what is new or modified in this version of the policy.

Last Modification

The name of the user active when the policy was saved.

Instrumentation selected for this policy. Instrumentation consists of one or more programs (for example scripts or executable files) that some policies may require to complete a configuration or monitoring task. Instrumentation is deployed to nodes that have HPE Operations Agent installed when the policy is deployed.

Instrumentations are unavailable if they are grayed out and their names end with "(Placeholder)". Upload them by using the Content Manager.

Types of operating system with which this policy is compatible.

To enable platform neutrality, you can create several platform specific variations of the same policy, and include them all in one aspect. OMi ensures that a policy is deployed only to host nodes that have the operating systems that you specify.

If you leave all the OS type check boxes clear, the policy can be deployed to host nodes with any operating system.

Log File Path / Name

Path and name of the log file that the policy reads. Type the drive letter and the full path for the location of this file on the node.

You can use the following configurations to make your policy more flexible:

• Windows environment variables (for example, winnt or clusterlog). The syntax for these variables is <$variablename>, for example <$winnt>.

• Script or command that returns the path and name of the log file you want to access. For example, type <`command`> where command is the name of a script that returns the path and name of the log file you want the policy to read.

  The command can also return more than one log file path separated by spaces. The HPE Operations Agent processes each of the files using the same options and conditions as configured for this policy. This is very useful when you want to dynamically determine the log file path or process multiple instances of a log file.

Path and name with extension of the command or program that preprocesses the log file. The file that you specify must exist on the node.

If Log File Path \ Name is empty, the agent runs the command at the polling interval that you specify. If Log File Path \ Name contains the path of a log file, the agent runs the command at the specified polling interval only if the log file has changed.

Path of the log file that the preprocessing command creates or updates.

If you specify a path in File to be read, the agent reads this log file. If you leave File to be read empty, the agent reads the log file that you specify in Log File Path \ Name instead.

Determines how often the policy reads the log file (in days, hours, minutes, and seconds). This period of time is the polling interval. The larger polling interval is set, the less performance is needed. However, more memory is used (this depends on the amount of the data in the log file). Setting the polling interval below 30 seconds is not recommended, the default setting is usually appropriate.

Note that a policy begins to evaluate data after the first polling interval passes, unless the Read from beginning (first time) or Read from beginning (always) radio button is selected, which results in evaluation of the first data at the policy activation. A shorter polling interval is better when you are testing a policy.

To modify the time, click the button and use the drop-down lists to specify increments of days, hours, minutes, or seconds.

To insert a parameter in a time field, type the parameter in the format %%<VariableName>%% or drag and drop the parameter from the Policy Parameters tab. When dropping a numeric parameter in a time field, the policy editor appends an s to the parameter to indicate that the parameter specifies the time in seconds (for example, %%interval%%s).

Default value: 5 minutes

Logfile Character Set

Name of the character set used by the log file that the policy reads.

Default value: UTF-8

Send event if log file does not exist

The agent sends an event if the specified log file does not exist.

Default value: not selected

If you select this option, the file handle of the log file closes and reopens again after the polling interval. The log file is read from the last position. If this file had a rollover in the meantime, it is read from the beginning. If the name of the log file changes, and a new file was started in the meantime, the policy continues to read the new log file and the original log file data is lost.

If you do not select this option, the file handle remains and is read entirely each time, unless there is a newer file with the same name (or name pattern). In that case the original log file is read to the end, and then the newer file is read. Therefore, no data is lost.

Consider the following example: a policy reads the log file system.log.While there is still some unread data in the system.log file, it is renamed to systemMonday.log, and a new version of the system.log file is written.

In case this option is selected, the unread data from the systemMonday.log file remains unread and the system.log file is read entirely.

In case this option is not selected, the unread data from the new system.log file is read after the reading of the systemMonday.log file is completed.

Default value: not selected

Read Mode

The read mode of a log file policy indicates whether the policy processes the entire file or only new entries.

Default value: Read from last position