Administer > Monitoring > Policy Templates > Configure REST Web Service Listener Policies

Configure REST Web Service Listener Policies

REST Web Service Listener policies enable you to acquire data by using a REST Web Service endpoint within the product that is integrated with OMi (the agent). Chunks of data in the XML format are sent to the endpoint with the HTTP POST method. A REST Web Service Listener policy processes received data by applying the default values and rules defined in the policy. The agent then makes such data available to OMi.

The following types of data can be forwarded to OMi using a corresponding type of the REST Web Service Listener policies:

  • Events.

  • Topology information.

  • Metrics.

  • Generic output data.

Note Before setting up a policy, you should be clear about the purpose and usage of the data in OMi.

ClosedTo access

You can create or edit a REST Web Service Listener policy using the REST Web Service Listener policy editor, which you can open in the following ways.

  • To open the editor from the Edit Aspect dialog box:

    1. Open the Management Templates & Aspects manager:

      Administration > Monitoring > Management Templates & Aspects

      Alternatively, click Management Templates & Aspects.

    2. In the Configuration Folders pane, expand the configuration folders.

    3. In the Management Templates & Aspects pane, click an aspect, and then click the Edit Item Edit Item button.

      The Edit Aspect dialog box opens.

    4. Click the Policy Templates tab, and then do one of the following:

      • To add a new policy template:

        1. Click the Add Policy Template From List Add Policy Templates From List button. The Add Policy Templates From List dialog box opens.

        2. Click the New Item New Item button, and then click the New Item Add New Policy Template or the New Item Add New Policy Template (Raw Mode) button. The Select Type for New Policy Template dialog box opens.

        3. Select the appropriate type <DataType> from REST Web Service Listener, and then click OK.

      • To edit an existing policy template, click the policy template in the list, click the Edit Policy Template button, and then click the Edit Policy Template Edit Policy Template or the Edit Policy Template Edit Policy Template (Raw Mode) button.

      The Operations Connector High Availability policy editor opens.

      The REST Web Service Listener policy editor opens.

  • To open the editor from the Policy Templates manager:

    1. Open the Policy Templates manager:

      Administration > Monitoring > Policy Templates

      Alternatively, click Policy Templates.

    2. In the Policy Template Groups pane, expand Policy Management > Templates grouped by type.

    3. Depending on the type of data collected by the particular policy, expand Configuration, Events, Generic, Metrics, or Topology. Each policy type can be used only for a subset of the available data types.

    4. Click the <DataType> from REST Web Service Listener item in the appropriate folder, and then do one of the following:

      • To add a new policy template, in the Policy Templates pane, click the New Item button, and then click the Edit Policy TemplateAdd New Policy Template or the Edit Policy TemplateAdd New Policy Template (Raw Mode) button.

        The New <DataType> from REST Web Service Listener policy editor opens.

      • To edit an existing policy template, click the policy template in the Policy Templates pane, click the Edit Policy Template button, and then click the Edit Policy Template Edit Policy Template or theEdit Policy Template Edit Policy Template (Raw Mode) button.

        The Edit <DataType> from REST Web Service Listener policy editor opens.

Learn More

ClosedGeneral policy prerequisites

  • The integrated product is properly configured for integration with OMi. For more information, see the Integrate section.

  • The certificate request from the integrated product is approved in OMi.

  • The integrated product is configured as a connected server in OMi.

ClosedSource XML data requirements

The REST Web Service endpoint accepts valid XML data without the XML declaration (the <?xml version=...> line) and without the root XML element tags.

Example: 

<Event>
     <title>Detected neglectable impact on system hydrogen.elementary.com caused by monitored aspect workers_restart_rate [1/s]: 0.0000 at Tue Aug  5 13:41:32 2014</title>
     <timeStamp>12/13/14 08:59:57 AM</timeStamp>
     <impact>neglectable</impact>
     <category>Monitor Alert</category>
     <relatedCounter>workers_restart_rate [1/s]</relatedCounter>
     <relatedEntity>hydrogen.elementary.com</relatedEntity>
</Event>
ClosedMappings overview

A custom mapping definition consists of a map name (variable), an optional input data property (XML element or XML attribute), and one or more source and target value pairs. For example, you can assign the XML element Severity to the map name mapSeverity, and add a source value of serious. You can then assign the target value critical to the variable so that the agent inserts the value critical into the event in all places where the variable is used.

XML properties use the following syntax: <$DATA:/<XMLProperty>>

<XMLProperty> is the path from the root XML element of XML data to a specific XML element or attribute within that data. XML path uses slashes (/) as the path delimiters.

For example, the custom definition with the mapSeverity map name has the input data property of <$DATA:/PerformanceAlert/Severity> where Severity is a child element of PerformanceAlert.

XML properties are optional. If you do not assign an input data property to a map name (variable), you must add the source value directly to the variable when you insert the variable in an event attribute.

Note The ClosedSample Data tab is empty if no sample data has been loaded into the policy or if the sample data does not match any specified XML tags.

The Sample Data tab shows the following information if sample data is available:

  • XML Properties

    If sample data is available, the XML Properties section of the Sample Data tab shows all XML elements and attributes that match an XML tag.

    The XML Properties section by default shows the short path to the XML property or value. To view the full path, click Toggle Short/Full Path Notation. The full path begins with the XML tag specified in the Source tab.

    The items in the XML Properties section are by default sorted alphabetically in ascending order.

    To search for an XML property or value, type the search string in the Search Properties box. The list changes as you type; only matching items appear.

  • Values for <XMLProperty>

    This section displays the values of an XML property selected in the XML Properties section. If a value appears more than once, click Toggle Deduplication of XML Values to show or hide duplicate values. To find values that belong to more than one XML property, select the value and click Find Matching XML Events in Sample Data. The XML Sample Data window opens and shows all XML properties that have the selected value.

Tasks

ClosedConfigure a REST Web Service Listener Policy

Use the following options to create a customized procedure for the type of data you want to integrate using a REST Web Service Listener policy template.

In the REST Web Service Listener policy editor, follow the steps:

  1. In the Properties page, Closeddefine general policy information.

    Type the name of the policy in the Name text box.

    Optional. Provide a description of the policy (Description), select the instrumentation that will be deployed with the policy onto the host system where the agent is running (Instrumentation), and select the operating systems with which the policy is compatible (OS Types).

    For more information, see Properties Page.

  2. In the Source page, Closedcompose the value of the Path option.

    The value of the Path option is part of the URL that defines the address where the REST Web Service endpoint listens for the incoming XML data from a REST Web Service client. Depending on the configured protocol, the URL must conform to one of the following templates:

    http(s)://<ConnectedServerHostFQDN>:<ConfiguredPort>/bsmc/rest/events/<Path>

    http(s)://<ConnectedServerHostFQDN>:<ConfiguredPort>/bsmc/rest/topology/<Path>

    http(s)://<ConnectedServerHostFQDN>:<ConfiguredPort>/bsmc/rest/metrics/<Path>

    http(s)://<ConnectedServerHostFQDN>:<ConfiguredPort>/bsmc/rest/genericdata/<Path>

    Tip In specific integrated products (for example, Operations Connector) you can customize the embedded REST Web Service endpoint. For instructions, see the integrated product's documentation (for Operations Connector, this is Operations Connector Help).

    Optional for events, metrics, and generic output data. Load sample XML data to OMi and create XML tags that will serve as shortcuts to the XML elements that you want to process. The file with sample data must reside on the system from where your are logged into OMi.

    Note When you load the data, OMi replaces the already loaded data with new data. This action does not affect the mappings that are defined based on previously available sample data.

    Click Load sample data to load the file with sample data to the policy editor. Once loaded, a notifications appears in the Sample Data section of the policy editor.

    To create an XML event, metric, or generic data tag, click Create a new XML event tag, and then do one of the following:

    • If sample data is not loaded, manually type the corresponding XML element name.

    • If sample data is loaded, double-click the XML element in the list.

    The XML event, metric, or generic data tag creates a shortcut to the XML element that you want the policy to process. An event, metric, or generic data tag typically identifies an event, metric, or generic data record in an XML log file. You can define multiple event, metric, or generic data tags. An example from event collection: an XML file may contain two types of events: <PerformanceAlert> and <AvailabilityAlert>. To process both types, define both elements as event tags.

    Optional for topology information. Additionally, you can:

    • Enable delta detection, so that only the difference between the received XML file and existing topology data in the repository is sent to OMi.

    • When delta detection is enabled, specify the number of times the policy attempts to acquire details of each CI. If the configured number of attempts fail for a CI, such CI is deleted from the topology repository in OMi.
  3. In the events and metrics policies, in the Mappings page, Closedconfigure mappings of XML elements or attributes to custom variables.

    1. Create custom variables.

      If sample data is loaded in the policy editor and shortcuts to XML elements are defined, drag the XML element from the XML Properties list to the Map Name column. The editor automatically adds the default prefix map to the map name and inserts the column name.

      Alternatively, click above the Map Name column and type the variable name in the map name field. XML properties are optional. If you do not assign an XML property to a variable, you must add the source value directly to the variable when you insert the variable in an event or metric attribute.

    2. Add source and target value pairs to each custom variable.

      • If sample data is loaded in the policy editor and shortcuts to XML elements are defined, drag a value from the Values for '...' list to the Source Value column, and then type the target value in the corresponding field.

        Alternatively, click above the Source Value column and type the source and target values in the corresponding fields.

      • Optional. In the Indicators tab, add indicators to the source or target value fields. After loading the indicators from the OMi server, the Indicators tab shows a hierarchy of configuration item types with the associated health indicators (HIs) and event type indicators (ETIs).

        To insert an indicator in a source or target value field, drag the indicator state (for example, HTTPServer:Normal) from the Indicators tab and drop it on the corresponding field.

      • Optional. In the Policy Variables tab, add policy variables to data attributes. The agent replaces the variables with the appropriate values in the generated data.

        HPE recommends to surround variables with quotation marks, for example "<$MSG_NODE>" or "<$MSG_GEN_NODE>", at least for those variables whose values can contain space characters.

  4. In the generic output data policies, in the Mappings page, Closedconfigure mappings for key fields.

    1. Create key field mappings.

      If sample data is loaded in the policy editor and shortcuts to XML elements are defined, drag an XML element from the Meta Data list to the Input Field Qualifier column. The editor automatically extracts the eligible field name.

      Alternatively, click above the Input Field Qualifier column and type the qualifier name in the corresponding field.

    2. Optional. Change the Keep All Input Fields setting. By default, the option is selected and all fields are kept, regardless whether they are mapped or not. To keep only the mapped fields, clear the option.

    3. Add any additional fields as required.
  5. Optional for events. In the Defaults page, Closedconfigure default settings for all events collected by the policy.

    Note The default values configured in this page:

    • Apply only to a subset of event attributes. You can configure defaults of other attributes within individual policy rules.

    • Affect new as well as already existing rules. You can override the defaults in individual policy rules. If a rule contains empty event attributes, the agent will use the defaults for incoming events.

    1. Click Event Attributes to define default event attributes, such as severity and category.

      In the strings that define event defaults, you can use indicators, policy variables, and policy parameters.

      Tip After loading the indicators from the connected OMi server, the Indicators tab shows a hierarchy of configuration item types.

      To insert an indicator, drag the indicator with its state from the Indicators tab to the policy.

      To insert an indicator, drag the indicator from the Indicators tab to the policy. The policy editor inserts the indicator name.

    2. Click Event Correlation to set the type of duplicate event suppression and define the method used to suppress duplicate events.

    3. Click Custom Attributes to add additional information to all events generated by this policy. For example, you might add a company name, contact information, or a geographical location to an event.

    4. Click Advanced to define default advanced attributes such as legacy OM attributes and agent ClosedMSI (Message Stream Interface) settings.

    5. Optional. Use the Sample Data tab to drag XML properties (XML elements and attributes) and values to the attribute boxes. Alternatively, you can type the path to the XML property or value directly into the attribute box.

      XML properties use the following syntax: <$DATA:/<XMLProperty>>

      <XMLProperty> is the path from the root XML element of XML data to a specific XML element or attribute within that data. XML path uses slashes (/) as the path delimiters.

      The agent replaces the XML property at runtime with the value of the specified XML element or attribute. If you insert an XML value, the value will be used.

      Note The Sample Data tab is empty if no sample data is loaded into the policy editor or no XML data has been received for the policy.

    6. Optional. Use the Mappings tab to add mapping definitions to the attribute boxes.

      Mappings are custom variables that you define in the mappings tab (see also Configure REST Web Service Listener Policies). The default name of the mapping variable is map<XMLProperty>, for example mapSeverity.

      Alternatively, type the custom variable into the attribute box using the following syntax:

      • Map Name list contains the map name of the variable: map<XMLProperty>, for example mapSeverity.

      • Input Data Property list item: <$DATA:/<XMLTag>/<XMLProperty>>

        For example, the custom variable mapSeverity has the following input data property: <$DATA:/PerformanceAlert/Severity> where Severity is a child element of PerformanceAlert.

    7. Optional. Use the Operators tab to apply operators to the attribute values. Two functions are available:

      $MATCH(), to test a string or a variable against a pattern. The $MATCH function accepts three or four parameters:

      - the input string

      - the pattern definition

      - the output string if pattern matches on the input string

      - the output string if the pattern does not match (optional)

      Example: The data of the input field hostname start always with "TEST" (for example "TESTABC"). The $MATCH function to use the string after "TEST" is as follows:

      $MATCH(<$DATA:hostname>,TEST<*.prefix>,<prefix>)

      • <$DATETIME(FORMAT,VALUE)>, to convert the format of dates from the common format to the UNIX systems time (Epoch time) format.

      Note To apply operators to the attribute values, you can drag and drop them to a text field in the left pane of the same policy editor page. The appropriate tooltips are shown while performing this operation, which describe the role of the dragged operator.

    8. Optional. Use the Indicators tab to add indicators to the source or target value fields. After loading the indicators from the connected OMi server, the Indicators tab shows a hierarchy of configuration item types with the associated health indicators (HIs) and event type indicators (ETIs).

    9. Optional. In the Policy Variables tab, add policy variables to data attributes. The agent replaces the variables with the appropriate values in the generated data.

      HPE recommends to surround variables with quotation marks, for example "<$MSG_NODE>" or "<$MSG_GEN_NODE>", at least for those variables whose values can contain space characters.

  6. Optional for metrics. In the Defaults page, Closedconfigure default settings for all metrics collected by the policy.

    Note You can use the default values configured in this page when defining the policy rules on the Rules page, where you can also override them.

    1. Define the metric attributes common to all metrics collected by this policy, such as metric class and name. All metrics in the Basic tab marked with a * are required. Advanced attributes are optional.

    2. Optional. Use the Sample Data tab to drag XML properties (XML elements and attributes) and values to the attribute boxes. Alternatively, you can type the path to the XML property or value directly into the attribute box.

      XML properties use the following syntax: <$DATA:/<XMLProperty>>

      <XMLProperty> is the path from the root XML element of XML data to a specific XML element or attribute within that data. XML path uses slashes (/) as the path delimiters.

      The agent replaces the XML property at runtime with the value of the specified XML element or attribute. If you insert an XML value, the value will be used.

      Note The Sample Data tab is empty if no sample data is loaded into the policy editor or no XML data has been received for the policy.

    3. Optional. Use the Mappings tab to add mapping definitions to the attribute boxes.

      Mappings are custom variables that you define in the mappings tab (see also Configure REST Web Service Listener Policies). The default name of the mapping variable is map<XMLProperty>, for example mapSeverity.

      Alternatively, type the custom variable into the attribute box using the following syntax:

      • Map Name list contains the map name of the variable: map<XMLProperty>, for example mapSeverity.

      • Input Data Property list item: <$DATA:/<XMLTag>/<XMLProperty>>

        For example, the custom variable mapSeverity has the following input data property: <$DATA:/PerformanceAlert/Severity> where Severity is a child element of PerformanceAlert.

    4. Optional. Use the Operators tab to apply operators to the attribute values. Two functions are available:

      $MATCH(), to test a string or a variable against a pattern. The $MATCH function accepts three or four parameters:

      - the input string

      - the pattern definition

      - the output string if pattern matches on the input string

      - the output string if the pattern does not match (optional)

      Example: The data of the input field hostname start always with "TEST" (for example "TESTABC"). The $MATCH function to use the string after "TEST" is as follows:

      $MATCH(<$DATA:hostname>,TEST<*.prefix>,<prefix>)

      • <$DATETIME(FORMAT,VALUE)>, to convert the format of dates from the common format to the UNIX systems time (Epoch time) format.

      Note To apply operators to the attribute values, you can drag and drop them to a text field in the left pane of the same policy editor page. The appropriate tooltips are shown while performing this operation, which describe the role of the dragged operator.

    5. Optional. Use the Indicators tab to add indicators to the source or target value fields. After loading the indicators from the connected OMi server, the Indicators tab shows a hierarchy of configuration item types with the associated health indicators (HIs) and event type indicators (ETIs).

    6. Optional. In the Policy Variables tab, add policy variables to data attributes. The agent replaces the variables with the appropriate values in the generated data.

      HPE recommends to surround variables with quotation marks, for example "<$MSG_NODE>" or "<$MSG_GEN_NODE>", at least for those variables whose values can contain space characters.

  7. In the events and metrics policies, in the Rules page, Closeddefine policy rules.

    Events policies:

    Rules define the action a policy should take in response to a specific type of incoming event. Each rule consists of the following:

    • A condition for the incoming data

      The condition is the part of a policy that describes the data source.

    • Settings for the outgoing event

      The settings define the actual event data that the agent sends to OMi.

    A policy must contain at least one rule. If the policy contains multiple rules, they are evaluated consecutively. After the condition is matched in one rule, rule evaluation stops.

    Metrics policies:

    Rules define the action a policy should take in response to a specific type of incoming metric. Each rule consists of the following:

    • A condition for the incoming data

      The condition is the part of a policy that describes the data source.

    • Settings for the outgoing event

      The settings define the actual metric data that the agent sends to OMi.

    A policy must contain at least one rule. If the policy contains multiple rules, they are evaluated consecutively. After the condition is matched in one rule, rule evaluation stops.

    To define policy rules, follow the steps:

    1. In the Policy Rules list, click the button, and then select an appropriate value. For more information, see Policy Rules List.

    2. Click Rule Description and type a brief description of the rule.

    3. In the Rule Content section, use the Condition tab to define values that you want to evaluate against elements and attributes in the XML file.

      1. Click New item to create a new condition. New conditions by default use the equals operator.

      2. Click to expand the new condition.

      3. In the Property field, specify the XML element or attribute that the policy searches for. You must specify the XML path from the XML event tag to the property, separated by slashes (/) (for example, /PerformanceAlert/Severity).

        If you are working with sample data, you can drag and drop the XML element or attribute from the XML Properties list to the Properties field.

      4. Select the pattern operator.

        If you select the matches operator, you can type a pattern in the Operand field.

      5. In the Operand field, type the value or pattern that you want the policy to compare with the XML property. If sample data is loaded in the policy editor, you can drag the value from the Values list and drop it in the Operand field.

        Tip For matching patterns, you can use standard pattern-matching rules of the agent. Select the matches operator and click the icon in the Operand field to open the pattern matching toolbox window. The toolbox includes the following sections:

        • Pattern Matching Expressions. Click an expression to insert it into the Operand text box.

        • Variable Bindings Options. Variable binding options include the setting of case sensitivity check and the field separators used in the rule. If you do not specify the pattern matching options for the rule, either the defaults (enabled case sensitivity check; the space and the tab character as the separators) or the default options set for the policy are used.

      For further details, see Condition Tab.

    4. Optional. If you are creating a rule of the "Event on matched rule" type, set attributes for events that you want the policy to send. You can override the default event attributes here. You can also enter instructions that help operators handle the associated event (or add the name of the instruction text interface in order to retrieve event instructions from an external source) and configure actions to solve problems automatically or manually.

      In text boxes, you can specify sample data, mappings, pattern-matching variables, indicators, policy variables, and policy parameters.

      For details, see Event Attributes Tab, Event Correlation Tab, Custom Attributes Tab, Instructions Tab, Advanced Tab (Default Event Attributes), and Actions Tab.

  8. Optional for events and metrics. In the Options page, Closedset additional policy options.

    In this page, you can:

    • Configure which rule matching actions are logged by the policy

    • Define how the agent behaves on unmatched events or metrics

    • Set the pattern matching options

    For details, see Options Page.

  9. Click Save and Close to save the policy template and exit the dialog.

Troubleshooting

This section lists the guidelines for troubleshooting REST Web Service Listener policies.

ClosedGeneral troubleshooting guidelines

  • To start troubleshooting, check the log files of the agent in the %OvDataDir%log directory (Windows systems) or the /var/opt/OV/log directory (Linux systems).

  • To investigate issues related to policy execution, first examine the %OvDataDir%log\System.txt file (Windows systems) or the /var/opt/OV/log/System.txt file (Linux systems).

    Note The log files whose names start with the opr- prefix are generated by the OMi web console.

UI Reference

User interface elements of the policy editor (for all monitored and output data types) are described below. The elements are listed alphabetically.

ClosedActions Tab

UI Element

Description

Automatic command

Automatic command that runs when the rule is matched.
Command Command and parameters to run when the command is started for this event. The command runs on the node you specify in the Node field. If the command contains spaces, enclose it in quotation marks. Commands that are internal to the Windows command shell (for example echo or move), must be preceded by cmd /c.
Non Agent User

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.

Node

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.

Append output of command as annotation to the event Adds an annotation to the event when the command completes. The annotation contains the start time, output, exit value, and finish time of the command. If a command fails, an annotation is provided even if this item is not selected.
Close the event when the command is successful

Closes the event automatically if the command is successful.

Send event immediately Sends an event to the OMi server as soon as a local automatic command starts on the node. This is the default setting.
Wait until local command completes and then

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.
Command Command and parameters to run when the command is started for this event. The command runs on the node specified in the Node field. If the command contains spaces, enclose it in quotation marks. Commands that are internal to the Windows command shell (for example echo or move), must be preceded by cmd /c.
Non Agent User

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.

Node

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.

Append output of command as annotation to the event Adds an annotation to the event when the command completes. The annotation contains the start time, output, exit value, and finish time of the command. If a command fails, an annotation is provided even if this item is not selected.
Close the event when the command is successful

Closes the event automatically if the command is successful.

ClosedAdvanced Tab (Default Event Attributes)

UI Element

Description
Event Drilldown
Event Drilldown URL

URL of the event in a third-party system. This is the complete path of the URL, and includes the ClosedFQDN (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.

Tip To drill down to a specific event in the third-party system, add the source event ID to the URL.

OM Attributes
Application

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).
Object

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).
Type

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

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.
Agent MSI
Enable Agent MSI

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.
ClosedAdvanced Tab (Default Metric Attributes)
UI Element Description
Original metric name

The name of the metric as used on the third-party system.
Unit

The unit of the metric values.

Example: "MB"
Integration id

An ID, used to identify the source of the integration.

Example: "DB-ORA"
ClosedBasic Tab
UI Element Description
Data domain

The namespace of the integrated performance records, used in the Operations Agent store to avoid clashes.

Example: "OpsCxMetrics"
Metric class

Defines the metric class. Metric class and metric name are concatenated as the metric name that appears in the Operations Agent store and consumers.

Example: "Windows CPU Monitor"

Metric name

Defines the metric name. Metric class and metric name are concatenated as the metric name that appears in the Operations Agent store and consumers.

Example: "CPU Utilization"

Related CI

Contains the CI that is related to the metric (for example, oraclesid01@@node.example.com or C:@@server.example.com). Use the format <CI 1>:<CI 2>:...:<CI n>@@<hostname>.

ClosedBest practices for related CIs

It is necessary to differentiate between CIs that have a Composition relationship to a node, and those that do not have such a relationship:

  • For “hosted on” CIs

    <key attribute 1>:<key attribute 2>:<key attribute n>@@<hostname>

    Typically, a “hosted on” CI is a sub-type of “Running Software”. For example, a CI of type websphereas has a Composition relationship to a node.

  • For virtual CIs

    <key attribute 1>:<key attribute 2>:<key attribute n>

    A virtual CI does not have a strong containment relationship (Composition relationship) to node.

    An example of a typical virtual CI type is cluster. This CI type does not have a strong containment relationship to a node.

    Tip If you have problems resolving non-hosted CIs, provide the RTSM ID of the desired CI by using the format UCMDB:<ci_uuid>.

For more information about CI resolution in OMi, see the OMi Help.
Node

Used to identify a node-like CI to which the performance records are associated to.

Example: "dbsys1.company.com"
Value

The actual performance value. It is automatically converted to a double-precision number.

Example: 80
Time measured

The time stamp when the value was determined in the third-party system, expressed in the following formats:

  • Integers. The agent interprets integers in the policy source as seconds since 00:00:00 UTC on 1 January 1970 (UNIX system time). For example, 1276600333 is 15 June 2010, at 11:12:13.

    Use the $DATETIME function to convert it.

  • Default time formats. The agent by default interprets the following time formats:

    yyyy-mm-ddTHH:MM:SS (for example, 2010-06-15T11:12:13)

    mm/dd/yyyy HH:MM:SS (for example, 06/15/2010 11:12:13)

    Additional time zone formats are supported:

    yyyy-mm-ddTHH:MM:SS tz (for example, 2010-06-15T11:12:13 +3)

    mm/dd/yyyy HH:MM:SS tz (for example, 06/15/2010 11:12:13 -2)

    where tz is a number for the offset to the UTC time zone. You can also use half or quarter hours (.25, .5, or .75, for example, 2010-06-15T11:12:13 -2.75).

    If you want to create your own pattern, you can store the time zone information in <@.tz> to match all above mentioned time zones.
ClosedCondition Tab
UI Element Description
New Item. Creates a new condition with the default operator equals.
Delete Item. Deletes the selected condition.
Move Up. Moves the selected condition higher in the condition order.
Move Down. Moves the selected condition lower in the condition order.
Expand. Expands the list of conditions to display all details.
Collapse. Collapses the list of conditions to display only the names and hide the details.
Click to expand the details of a condition.
Click to hide the details of a condition.
Property

XML Property that the policy searches for. You must prefix the XML property with <XML Event/Metric Tag> ( /<XML Event/Metric Tag>/<full path to XML Property>).
Operator

The following operators are available:

  • equals

  • not equals

  • less than

  • greater than

  • less or equal

  • greater or equal

  • matches (Enables you to enter a pattern in the Operand field.)
Operand

Value or pattern that you want the policy to compare with the table column (Database policies), or the input data reference (Structured Log File policies), or the value of the XML property (REST Web Service Listener policies and XML File policies). If you are working with sample data, you can drag the value from the Values list and drop it in the Operand field.
ClosedCustom Attributes Tab

UI Element

Description
Create New Custom Attribute:

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.
Delete Custom Attribute Delete Custom Attribute: Deletes an existing custom attribute.
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

Value of the custom attribute.
ClosedDefaults Page (Events)

The Defaults page enables you to set default attributes for all events that a policy sends. The event defaults only affect new rules. You can override the defaults for individual rules.

For details, see Event Attributes Tab, Event Correlation Tab, Custom Attributes Tab, Instructions Tab, Advanced Tab (Default Event Attributes), and Actions Tab.

ClosedDefaults Page (Metrics)

The Defaults page enables you to set default attributes for all metrics that a policy sends. The metric defaults only affect new rules. You can override the defaults for individual rules.

For details, see Basic Tab and Advanced Tab (Default Metric Attributes).

ClosedEvent Attributes Tab

UI Element

Description

Title

Brief description of the nature of the event.

Description

Detailed description of the event.

Severity

Severity assigned to the event.

Time Created

Date and time when the event was created.

Use the following conventions when specifying the date and time attribute:

  • Integers. The agent interprets integers in the policy source as seconds since 00:00:00 UTC on 1 January 1970 (UNIX system time). For example, 1276600333 is 15 June 2010, at 11:12:13.

  • Default time formats. The agent by default interprets the following time formats:

    yyyy-mm-ddTHH:MM:SS (for example, 2010-06-15T11:12:13)

    mm/dd/yyyy HH:MM:SS (for example, 06/15/2010 11:12:13)

    Additional time zone formats are supported:

    yyyy-mm-ddTHH:MM:SS tz (for example, 2010-06-15T11:12:13 +3)

    mm/dd/yyyy HH:MM:SS tz(for example, 06/15/2010 11:12:13 -2)

    where tz is a number for the offset to the UTC time zone. You can also use half or quarter hours (.25, .5, or .75, for example, 2010-06-15T11:12:13 -2.75).

    If you want to create your own pattern, you can store the time zone information in <@.tz> to match all above mentioned time zones.

  • Pattern matching. You can use the function Closed<$DATETIME(FORMAT,VALUE)> to specify a pattern (FORMAT) that matches the time string in the policy source (VALUE). You can use standard pattern-matching rules when matching values. By default, pattern matching for the time format is case sensitive. The default field separators are the space and the tab characters.

    FORMAT must be enclosed in quotation marks ("FORMAT") and accepts the following variables:

    H (hours), M (minutes), S (seconds). If H, M, or S is not set, the hour, minute, or second displays as zero.

    d (day), m (month), y (year). If d or m is not set, the day or month display as one. If y is not set, the current year is assumed. If y is less than 100, the current millennium is assumed; for example, if y matches 10, the year displays as 2010. It is not possible to match a year earlier than 1970.

    p (P.M.) If p is set, The agent adds 12 hours to the hours that precede the variable.

    VALUE is the XML property to match.

    XML properties use the following syntax: <$DATA:/BSMConnectorEvent/<XML property>>

    <XML property> is the string assigned to the XML property from the XML event tag (for example, <severity>Warning</severity>)

    Examples:

    To match the time format 06/15/2010 11:12:13 in the pattern matching field <$DATA:timestamp>, type
    <$DATETIME("^<#.m>/<#.d>/<#.y> <#.H>:<#.M>:<#.S>$",<$DATA:timestamp>)>

    To match the time format 11:12 15.06.2010 in the pattern matching field <$DATA:timestamp>, type
    <$DATETIME("^<#.H>:<#.M> <#.d>.<#.m>.<#.y>$",<$DATA:timestamp>)>

    To match the time format 06/15/2010 1:35 PM in the pattern matching field <$DATA:timestamp>, type
    <$DATETIME("^<#.m>/<#.d>/<#.y> <#.H>:<#.M> <2*.p>$",<$DATA:timestamp>)>

    To match the time format 06/15/2010 11:12:13 in the XML property <$DATA:/BSMCEvent/timeStamp>, type
    <$DATETIME("^<#.m>/<#.d>/<#.y> <#.H>:<#.M>:<#.S>$",<$DATA:/BSMCEvent/timeStamp>)>

    To match the time format 11:12 15.06.2010 in the XML property <$DATA:/BSMCEvent/timeStamp>, type
    <$DATETIME("^<#.H>:<#.M> <#.d>.<#.m>.<#.y>$",<$DATA:/BSMCEvent/timeStamp>)>

    To match the time format 06/15/2010 1:35 PM in the XML property <$DATA:/BSMCEvent/timeStamp>, type
    <$DATETIME("^<#.m>/<#.d>/<#.y> <#.H>:<#.M> <2*.p>$",<$DATA:/BSMCEvent/timeStamp>)>

If you leave the attribute empty or if none of the time formats above can be matched, then the date and time when the agent created the event appears in OMi. This time always appears using the time zone of the agent at creation time (for example, 11:30 (CET/winter). This means that this time always appears in this fixed time zone.

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).

Related CI

Contains the CI that is related to the metric (for example, oraclesid01@@node.example.com or C:@@server.example.com). Use the format <CI 1>:<CI 2>:...:<CI n>@@<hostname>.

ClosedBest practices for related CIs

It is necessary to differentiate between CIs that have a Composition relationship to a node, and those that do not have such a relationship:

  • For “hosted on” CIs

    <key attribute 1>:<key attribute 2>:<key attribute n>@@<hostname>

    Typically, a “hosted on” CI is a sub-type of “Running Software”. For example, a CI of type websphereas has a Composition relationship to a node.

  • For virtual CIs

    <key attribute 1>:<key attribute 2>:<key attribute n>

    A virtual CI does not have a strong containment relationship (Composition relationship) to node.

    An example of a typical virtual CI type is cluster. This CI type does not have a strong containment relationship to a node.

    Tip If you have problems resolving non-hosted CIs, provide the RTSM ID of the desired CI by using the format UCMDB:<ci_uuid>.

For more information about CI resolution in OMi, see the OMi Help.
Sub Component

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

Tip The file that the policy reads usually contains the source event ID. If you are working with sample data, you can drag the source event ID from the Sample Data tab and add it to the source event ID field.

Reserved for future use.

Send with closed status
(For the Database, Perl Script, REST Web Service Listener, Structured Log File, and XML File policies)

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

yes = Sets lifecycle status to Closed.

no = Does not set the lifecycle status to Closed.

Default value: 0 (= no)

Tip Click and select yes or no from the menu.
ClosedEvent Correlation Tab

UI Element

Description
Event Key An identifier used to identify duplicates and for Close Events with Key.
Close Events with Key

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$
Suppress Deduplication on Server Stops automatic discarding of new events that are duplicates of existing events.
Event Suppression
Enable Event Suppression

Enables event suppression for the events generated by this policy.
Suppress events which are

  • 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).

Suppression Method

For event correlation, you can define one of three correlation methods:

  • Time Interval. This correlation method lets you define an interval during which duplicate events will be ignored. For more information, read this Closeddetailed example.

    Time interval correlation example

    In the illustration below, the interval is set to 30 seconds, but the suppression is limited to 60 seconds.

    The  represents events that are identical. 

    1. The first input event (E1) matches a rule in the policy.  The policy sends an event and starts timing. 
    2. A second matching event (E2) occurs 25 seconds later. This event occurred less than 30 seconds after the first event, and is therefore suppressed. 
    3. A third matching event (E3 )  occurs less than 30 seconds after the second event, and so is also suppressed. 
    4. The next matching event (E4) occurs less than thirty seconds after the third event, but is also more than 60 seconds after the first event, and therefore the policy sends an event.
  • Counter. This correlation method counts the number of matching input events and sends an event only after the number of matching input events equals the counter threshold. The counter can also be reset to zero after a time period that you specify. For more information, read this Closeddetailed example.

    Counter correlation example

     The  represent events that are identical. 

    1. The first input event (E1) matches a rule in the policy, and the counter increments to one.  No event is sent. 
    2. A second matching event (E2 ) occurs, the counter increments to two, an event is sent, and the counter resets.   
    3. A third matching event (E3 ), and the counter increments to one. No event is sent. 
    4. The next matching event (E4) occurs more than thirty seconds after the third event.  Since at thirty seconds the counter was reset to zero, the counter now increments to one. No event is sent.

  • Time Interval/Counter. If you use the Time interval and Counter together, events are evaluated first by the timer. If an event passes the timer, it is then evaluated by the counter, which either suppresses it or sends an event to OMi.

    Note If you specify just time interval correlation or just counter-based correlation in an individual event, any event defaults for the other correlation method also apply. For example, if you specify time interval correlation for an event, and the event defaults specify counter-based correlation, the combined time interval and counter-based correlation applies to both new rules and existing rules.

    You can change this default behavior, so that only the correlation method that you specify in the individual event applies. To change the default behavior, set the parameter OPC_IGNORE_DEFAULT_MSG_CORRELATION=TRUE in the eaagt namespace on the node. You can configure this parameter using ovconfchg at a command prompt.
Time Interval

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).
Suppress for no longer than

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).
Counter threshold Value that triggers an event if met or crossed.
Reset counter threshold after

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).
ClosedIndicators Tab

UI Element

Description

Refresh. Loads the configured indicators from the OMi server.

Note Loading indicators from the OMi server may take a few seconds.
<Search …>

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.

<Indicators>

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.
ClosedInstructions Tab

Specify if you want the instructions to accompany the event.

Events generated by a policy can include instructions that explain what to do when the event is generated. This instruction text can often help an operator to solve a problem when a particular type of event is received. The operator can view the instructions included with an event by checking the Event Details pane in the Event Browser. You can define default instructions for all rules in a policy. You can also override the default with different instructions for any rule.

UI Element

Description
Type

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.
ClosedMappings Page (Events, Metrics)
UI Element Description
Create new mapping definition. Adds a new mapping definition to the list of mappings.
Delete mapping definition. Deletes the selected mapping definition.
Copy Mapping Definition. Creates a copy of the selected mapping definition.
Move Up. Moves the selected mapping definition up to a higher position.
Move Down. Moves the selected mapping definition down to a lower position.
Map Name Name of the custom variable. The policy editor automatically adds the default prefix map to the map name if the variable has been created from sample data.
Input Data Property

XML property assigned to the custom variable.

The agent replaces the XML property at runtime with the value of the specified XML property. If you insert a value, the value will be used.
Create new mapping. Adds a new pair of source and target values to the mapping definition.
Delete mapping. Deletes the selected source and target value pair.
Copy Value Mapping. Creates a copy of the selected value mapping.
Move Up. Moves the selected value mapping up to a higher position.
Move Down. Moves the selected value mapping down to a lower position.
Source Value

Original value associated with the XML property from the XML file.
Target Value

New value associated with XML property.
ClosedMappings Page (Generic Output Data)
UI Element Description
Create new mapping definition. Adds a new mapping definition to the list of mappings.
Delete mapping definition. Deletes the selected mapping definition.
Input Field Qualifier

XML property assigned to the custom variable.

Operations Connector replaces the XML property at runtime with the value of the specified XML property. If you insert a value, the value will be used.

If you are working with meta data, you can drag and drop a key from the Meta Data tab.
Eligible Field Name

The field that is eligible for mapping. The field is extracted automatically from the Input Field Qualifier.

Some sources integrate hierarchical data (XML file, REST WS, and log file). In case of such data, any field to be mapped must be a leaf node in the internal logical tree-like structure.
Mapped Field Name The replacement for the input field.
Keep All Input Fields

If the option is selected, all input is kept regardless if the mapping does occur or not. If the option is not selected, the fields that are not mapped are dropped.
New item Adds a new additional, user defined field.
Delete item. Deletes the additional field.
Field Name

The name of the additional user defined field.
Field Value

The value of the additional user defined field. The value can contain static text defined by the user and data references into the input data (<$DATA:…>).
ClosedMappings Tab
UI Element Description
<Mappings>

Displays the mapping definitions configured for the policy.

ClosedMeta Data Tab

UI Element

Description
Input Data Properties

A list of keys derived from input data. You can drag and drop the keys onto the Key Field Mapping table.
ClosedOperators Tab

Expressions and Functions

Description
$MATCH(<input>, <pattern>,<output_on_match>(,<output_on_no_match>)) Tests a string or variable against a pattern. The $MATCH function accepts three or four parameters:

- the input string

- the pattern definition

- the output string if pattern matches on the input string

- the output string if the pattern does not match (optional)

Example: The data of the input field hostname start always with "TEST" (for example "TESTABC"). The $MATCH function to use the string after "TEST" is:

$MATCH(<$DATA:hostname>,TEST<*.prefix>,<prefix>)
<$DATETIME(<format>,<value>)> Converts regular dates to UNIX system time (Epoch time).
$DD

Any custom attribute with this expression is replaced with the date of processing of the log file.

Example: If a log file is processed on April 2, 2017, $DD will be replaced with 2.
$MM

Any custom attribute with this expression is replaced with the month of processing of the log file.

Example: If a log file is processed on April 2, 2017, $MM will be replaced with 4.
$MON

Any custom attribute with this expression is replaced with the first three letters of the month of processing of the log file.

Example: If a log file is processed on April 2, 2017, $MON will be replaced with Apr.
$YYYY

Any custom attribute with this expression is replaced with the year of processing of the log file.

Example: If a log file is processed on April 2, 2017, $YYYY will be replaced with 2017.
$TIMEZONE

Any custom attribute with this expression is replaced with the time and area of processing of the log file. Replaces with the number format of the timezone.

Example: If agent is running on IST zone then +530 hours.
$HOSTNAME Any custom attribute with this expression is replaced with the name of the host of the log file.
$LOGSOURCE Any custom attribute with this expression is replaced with the path of the log file which is specified in the policy configuration.
$POLNAME Any custom attribute with this expression is replaced with the name of policy of the log file.
ClosedOptions Page

UI Element

Description

Options in events policies:

Log Local Events

Defines which events, if any, are logged on the node from which they originated. These events are logged on the local node in the log file:

Windows: %OvDataDir%\log\OpC\opcmsglg

AIX, HP-UX, Linux, and Solaris: /var/opt/OV/log/OpC/opcmsglg
that match a rule and trigger an event Logs any events in the event source that match the policy rules.
that match a rule and are ignored Logs any events in the event source that are suppressed. (Suppressed events are not sent to OMi.)
that do not match any rule Logs any events that do not match any of the rules in the policy.

Unmatched Events

Send an event to OMi when the input event does not match any rule in the policy because none of the conditions apply or because the policy does not contain any rules. This ensures that unexpected events that might be important do not go unreported. By default, unmatched events are ignored.

Each policy that sends unmatched events to OMi creates an event with the default values of the policy.

Tip If you want a policy to send events only with the default values, omit all rules from the policy.

are forwarded to OMi Server Sends unmatched events to OMi.
are forwarded to OMi Server with state 'closed' Sets the unmatched event's lifecycle status to Closed before sending it to OMi.
are ignored Ignores unmatched events.

Options in metrics policies:

Log incoming Metric data

Defines which metric records, if any, are logged on the node from which they originated. These metrics are logged on the local node in the log file:

Windows: %OvDataDir%\log\OpC\opcmsglg

AIX, HP-UX, Linux, and Solaris: /var/opt/OV/log/OpC/opcmsglg
that match a rule and are stored Logs any metric records in the metric source that match the policy rules.
that match a rule and are ignored Logs any metric records in the metric source that are suppressed. (Suppressed metric records are not sent to OMi.)
that do not match a rule and are ignored Logs any metric records that do not match any of the rules in the policy.
Unmatched Records
Store records that do not match any rule The agent stores events and metrics that do not match any rule and sends them to OMi.
Options in events and metrics policies:

Pattern Matching Options

Defines case sensitivity and field separators for all rules.
Case sensitive check Defines whether the case (uppercase or lowercase) of a text string is considered when the pattern of a rule is compared with the source data. When switched on, a match only occurs if the use of uppercase and lowercase letters is exactly the same in both the source data and the pattern. This is the default setting.
Field Separators

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:

  • \n New line (NL)
  • \t Horizontal tab (HT)
  • \v Vertical tab (VT)
  • \b Backspace (BS)
  • \r Carriage return (CR)
  • \f Form feed (FF)
  • \a Alert (BEL)
  • \\ Backslash (\)

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.

Apply to All

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.

ClosedPattern Matching Variables Tab
UI Element Description
<Variables>

Displays the user-defined variables configured in the Condition tab.
ClosedPolicy Parameters Tab
UI Element Description
Create Parameter Create Parameter: Open the Create Parameter dialog box.
Edit Parameter: Open the Edit Parameter dialog box.
Delete Parameter Delete Parameter: Delete the selected parameter from the list.
Synchronize Parameters

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.
<Parameters>

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 Enumeration (of several options)

  • Numeric Number

  • Password Password

  • String String
ClosedPolicy Rules List

UI Element

Description

Options in events policies:

Create New Rule: Provides the following options:

  • Event on matched rule. If matched, the agent sends an event to OMi. The event uses the settings defined for the rule. If you do not configure these settings, the default settings are used.

  • Suppress on matched rule. If matched, the agent stops processing and does not send an event to OMi.

  • Suppress on unmatched rule. If not matched, the agent stops processing and does not send an event to OMi.

Options in metrics policies:

Create New Rule: Provides the following options:

  • Store on matched rule. If matched, the agent stores metrics in a buffer until a maximum number of records or a maximum amount of time are reached, when it sends them to OMi. The metrics use the settings defined for the rule. If you do not configure these settings, the default settings are used.

  • Suppress on matched rule. If matched, the agent stops processing and does not send metrics to OMi.

  • Suppress on unmatched rule. If not matched, the agent stops processing and does not send metrics to OMi.
Copy Rule. Copies the selected rule. You can then rewrite the description of the copied rule and edit the rule.
Delete Rule. Deletes the selected rule.
Move Up. Moves the selected rule higher in the rule order.
Move Down. Moves the selected rule lower in the rule order.
<Move to>

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.

<Search Rules>

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.

Activate/Deactivate Rule Filter. Activates and deactivates the rule filter.
Seq. Sequence number of the rules. Rules are evaluated in a specific order. When one condition is matched, no additional rules are evaluated.
Rule Description Description of the rule. It is good practice to use a description that helps you remember what the rule does.
Rule Type

Options in events policies:

  • Event on matched rule. If matched, the agent sends an event to OMi. The event uses the settings defined for the rule. If you do not configure these settings, the default settings are used.

  • Suppress on matched rule. If matched, the agent stops processing and does not send an event to OMi.

  • Suppress on unmatched rule. If not matched, the agent stops processing and does not send an event to OMi.

Options in metrics policies:

  • Store on matched rule. If matched, the agent stores metrics in a buffer until a maximum number of records or a maximum amount of time are reached, when it sends them to OMi. The metrics use the settings defined for the rule. If you do not configure these settings, the default settings are used.

  • Suppress on matched rule. If matched, the agent stops processing and does not send metrics to OMi.

  • Suppress on unmatched rule. If not matched, the agent stops processing and does not send metrics to OMi.

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.
ClosedPolicy Variables Tab (Default Event Attributes)
Variable Description
<$MSG_APPL> Returns the name of the application associated with the input event that caused the message. Sample output: /usr/bin/su(1) Switch User
<$MSG_GEN_NODE>

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

Note On agents that run in an AIX Workload Partition (WPAR), <$MSG_GEN_NODE> returns the IP address of the global environment. To configure the agent to return the WPAR's IP address for this variable, set the parameter OPC_IP_ADDRESS in the eaagt namespace to the IP address of the WPAR.

<$MSG_GEN_NODE_NAME> Returns the host name of the node that sends the event. Sample output: node123.example.com.
<$MSG_GRP> Returns the default category of the event. Sample output: Security
<$MSG_ID> Returns the unique identity number of the event, as generated by the the agent. Note that identity numbers are not generated for suppressed messages. Sample output: 6e998f80-a06b-71d0-012e-0f887a7c0000
<$MSG_NODE> Returns the IP address of the node on which the original event took place. Sample output: 192.168.1.123
<$MSG_NODE_NAME> Returns the name of the node on which the original event took place. This is the hostname that the agent resolves for the node. This variable is not fixed, however, and can be changed by a policy on a per-event basis.
<$MSG_SERVICE> Returns the service name associated with the event.
<$MSG_OBJECT> Delivers the name of the object associated with the event.
<$MSG_SEV> Returns the default value for the severity of the event. Sample output: Normal
<$MSG_TEXT> Returns the full text of the event. Sample output: SU 03/19 16:13 + ttyp7 bill-root
<$MSG_TIME_CREATED> Returns the time the message was created on the managed node in seconds elapsed since midnight (00:00:00), January 1, 1970, coordinated universal time. Sample output: 950008585
<$MSG_TYPE> Delivers the name set for message type.
ClosedPolicy Variables Tab (Default Value Mapping — Metrics)
Variable Description
<$MSG_GEN_NODE>

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

Note On agents that run in an AIX Workload Partition (WPAR), <$MSG_GEN_NODE> returns the IP address of the global environment. To configure the agent to return the WPAR's IP address for this variable, set the parameter OPC_IP_ADDRESS in the eaagt namespace to the IP address of the WPAR.

<$MSG_GEN_NODE_NAME> Returns the host name of the node that sends the event. Sample output: node123.example.com.
ClosedProperties Page

UI Element

Description
Name

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.
Description Description of what the policy does. You might also add other notes (for example, data sources that are used).
Template ID ClosedGUID (globally unique identifier) assigned to the policy template when it is first created.
Version ID ClosedGUID (globally unique identifier) assigned to this version of the policy template when it is saved. Each version of a policy template has a unique ID.
Version

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.

Note If you modify a policy template that is part of an HPE Operations Manager i Management Pack, increase the minor version number only. The next version of the Management Pack normally uses the next major version number.
Change Log

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

Last Modification
The Closeddate and time that the policy was saved.

The date and time displays using the current time zone of the computer on which the Web browser runs. The language setting of the Web browser determines the date and time format (for example, 09/14/2010 8:16:38 AM for English (United States)). If the Web browser and the computer on which the server run have different language settings, the language setting of the Web browser takes precedence. However, English is the default language if the Web browser is configured to use a language that is not available on the server.
Last Modified by

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

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.
OS Types

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.
ClosedRules Page (Events)

The Rules page enables you to define one or more policy rules.

For details, see Policy Rules List, Condition Tab, Event Attributes Tab, Event Correlation Tab, Custom Attributes Tab, Instructions Tab, Advanced Tab (Default Event Attributes), and Actions Tab.

ClosedRules Page (Metrics)

The Rules page enables you to define one or more policy rules.

For details, see Policy Rules List, Condition Tab, Basic Tab, and Advanced Tab (Default Metric Attributes).

ClosedSample Data Tab
UI Element Description
<Search Properties>

Entered search string is used to find an XML property. The list changes as you type; only matching items appear.

To clear the search results, click .
XML Properties

Shows all XML properties that have been received by the REST Web service listener for this policy.

Note The Sample Data tab is empty if no sample data has been loaded into the policy or if no XML data has been received for the policy.
Toggle Short/Full Path Notation. Shows or hides the full path to the XML property. The full path starts with <xml event/metric tag> /<path to xml property>. The XML properties section by default shows the short path to the XML property.
Values for '...'

Displays the values of the XML properties selected in the XML Properties section.

Find Matching Records. To find values that belong to more than one XML property, select the value and click Find Matching XML Events in Sample Data. The Web Service Sample Data window opens and shows all XML properties that have the selected value.
Toggle Deduplication. Shows or hides duplicate values.
ClosedSource Page

UI Element

Description
Path

A string entered in the policy. This string is a part of the actual URL where the REST Web Service Listener listens for the XML data. For example, for events the URL must conform to one of the following (depending on the protocol):

http://<ConnectedServerHostFQDN>:<ConfiguredPort>/bsmc/rest/events/<Path>

https://<ConnectedServerHostFQDN>:<ConfiguredPort>/bsmc/rest/events/<Path>

Only the following characters are allowed in a path: [a-zA-Z0-9()-=*.?;,+/:&_]
Character Set

Name of the character set used by the XML data that the policy reads.

Note It is important to choose the correct character set. If the character set that the policy is expecting does not match the character set in the XML data, pattern matching may not work, and the event details can have incorrect characters or be truncated in OMi. If you are unsure of which character set is used by the XML data that the policy reads, consult the documentation of the program that writes the file.

Default value: UTF-8
Sample Data
(events and metrics only)

Uploads the XML file to the Operations Connector.

Note The policy editor can only load a maximum of 50 MB of sample data.
Opens the REST Web Service Sample Data dialog box. This dialog box displays the XML elements and values contained in the uploaded XML sample data.

XML Generic Data Tag

Enables you to specify one or more XML generic data tags. The XML generic data tag creates a shortcut to the XML element that you want to process. An event tag typically identifies an event record in an XML data. A metric tag typically identifies a metric record in an XML data. You can define more than one tag.

Create a new XML generic data tag manually. Enables you to type an XML element in the provided box.

Create a new XML generic data tag from XML sample data. Opens the XML Sample Data Outline dialog box. This dialog box displays the XML elements and attributes contained in the uploaded XML sample data.

Deletes the selected XML tag.

Caution Deleting a tag that is referenced in a policy corrupts the policy and renders it unusable.
Detect deltas
(topology only)

A delta is the difference between the received XML file and the repository. The delta is the bare minimum of information about the changes. It discovers all changes without regards to the RTSM model.

If an instance or relation is not discovered for a certain amount of time (Age to deletion), it is deleted. The counter goes up each time when the algorithm is running (this depends on the interval and the last time the file was written / sent via web service).

If not selected, no delta detection is done and the incoming topology file is directly sent to the topology server.

Default value: selected.

Age to deletion
(topology only)

 A number of times for the policy to be run for a host that is not part of the topology data. After this number of policy executions, this host is deleted from the server.

Send Help Center feedback