Configure Database Policies

You can create or edit an Operations Connector High Availability template using the Operations Connector High Availability policy editor, which you can open in the following ways.

You can create or edit a Database policy (for collecting data through OpsCx) using the Database 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 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 Templates From List button. The Add Policy Templates From List dialog box opens.

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

       3. Select the type Operations Connector High Availability, and then click OK.

       4. Select the type <DataType> from DB (BSMC only), and then click OK.

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

     The Operations Connector High Availability policy editor opens.

     The Database 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 DB (BSMC only) 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 button, and then click the Add New Policy Template or the Add New Policy Template (Raw Mode) button.

       The New <DataType> from Database policy editor opens.

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

       The Edit <DataType> from Database policy editor opens.

  5. Click the Operations Connector High Availability item, and then do one of the following:

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

       The New ConfigFile policy editor opens.

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

       The Edit ConfigFile policy editor opens.

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

• There are several key database driver requirements for using this policy.

  • You must install or copy a compatible JDBC database driver or database access API locally on the Operations Connector systems. Many database driver packages are available as compressed (zipped) archive files or .jar files. If the file is in zip format, unzip the contents. A recommended location for the downloaded driver is the directory the C:/Program Files/HP/HP BTO Software/java.

  • You must know the syntax for accessing the database driver. See the driver documentation for details.

    Examples of common database driver strings are:

    • com.microsoft.sqlserver.jdbc.SQLServerDriver The Microsoft SQL Server JDBC driver.

    • oracle.jdbc.OracleDriver The Oracle JDBC driver.

• You must know the syntax for the Database Connection string. The Database Connection string normally includes the class of driver you are using, some key name relating to the supplier of the driver software, followed by a combination of server, host, and port identifiers. For details, see the driver documentation.

  Example: Database Connection URLs for Microsoft SQL Server for this policy:

  • jdbc:sqlserver://<hostname>:1433;Database=<name>;
    
    where <hostname> is the name of the host where the database is running and <name> is the name of the database.

• The database you want to query must be running, have a database name defined, and have at least one named table created in the database. In some cases, the database management software needs to be configured to enable connections by using the middleware or database driver.

• You need a valid user name and password to access and perform a query on the database. In some cases, the machine and user account that Operations Connector is running on must be given permissions to access the database.

• You must know a valid SQL query string for the database instance and database tables in the database you want to query. Consult your database administrator to work out required queries to use.

• Use a database client to connect to the relevant software database. Identify which tables contain the required data (the software schema documentation may help you with this).

Database policies use a user defined SQL query, an initial value statement, and a static initial value (session variable). The query you provide is used to define a search criterion on the database and with the initial value statement and a set up session variable, you can provide initial values that you can use in filtering. Starting with OMi 10.00, you are no longer limited to a fixed set of SQL clauses but can write more complex queries as well.

For example, if you fetch a field that contains a time stamp, you can write an SQL query to process only data records that happened after the policy was activated. You can do so by setting an appropriate initial value statement that is executed when the policy is activated and then compare the values retrieved in the main SQL clause against this initial value. For details on how the queries are used to fetch and filter records, see Understanding How Data From an SQL Query is Processed.

When querying the database - for example with a combination of select and from SQL clauses - all the rows from the table defined in the clause are retrieved, unless you define a further clause that filters the data. For example, you may want to retrieve only entries that were added after a certain point in time and not all entries in the table. To do so, you can compare the results returned by the SQL clause against a data map that you can populate with an initial SQL statement or by setting up a session variable for each key.

When the initial SQL statement is executed, the data map is initialized with values. The values returned as last record from the execution of the statement are copied to the data map and returned. You can then compare the values in your SQL query against the values in the data map by referring to the keys (<$DATA:<key>>). This will be replaced with the current value of the <key> in the data map.

To make sure that the data map is not empty if the initial SQL statement does not return any values, you should set a session variable for each key. This value is then used to replace <$DATA:<key>> in the executable SQL statement.

A custom variable consists of a map name, a key attribute name, and one or more source and target value pairs. For example, you can assign the data key name Severity to the map name mapSeverity, and add a source value of 2. 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.

Perl attribute key names use the following syntax: <$DATA:<AttributeName>>

where <AttributeName> is the data key name in a Perl hash array.

The key field mapping consists of an input field qualifier, an eligible field name, and a mapped field name. To map the key field, map the eligible field name to the mapped field name. The eligible field name is automatically extracted from the input field qualifier.

Perl script policies integrate unstructured data. Therefore, the eligible field name is identical to the input data qualifier.

You can add additional fields to data that is sent to Data Forwarding targets. Additional fields are simple key-value pairs and you must manually add both the keys and values. If a defined key field name equals a field name in the mapped data set, it is discarded.

The actual field value can consist of user defined strings and data references to the input data (<$DATA:…>).

Example:

The data references in the additional field combined_text are replaced when the policy is run. In the above example, after the variables are replaced, the resulting value in the field combined_text is:

At 12/05/2015 14:01:39, Monitoring: Threshold violation detected an substantial impact on system performance. This has happened 8264 times.

Note that data references must refer to the input format, not the mapped format.

In the Database policy editor, follow the steps:

1. In the Properties page, type a Name for the policy.

   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, define the connection to the database and the columns that the policy accesses.

   1. Configure the connection to the database:

      1. In the Classpath field, type the location of the .jar file that is loaded.

         Example: C:/Program Files/HP/HP BTO Software/java/sqljdbc4.jar
         (Microsoft SQL Server installed in the default folder)

      2. In the JDBC Driver Class field, type the name of the driver used to connect to the database. Use the Fully Qualified Class Name of the JDBC driver you are using.

         Example: com.microsoft.sqlserver.jdbc.SQLServerDriver
         (Microsoft SQL Server Driver class)

      3. In the Connect string field, type the URL to the database connection (referred to as an Authentication string).

         Example: jdbc:sqlserver://system2.company.com:1433;Database=BSMEVENTS
         (Microsoft SQL Server Driver connection string)

      4. Enter the username and password.

      5. Under Polling interval, specify how often the policy queries the database. Use the spinboxes to specify increments of seconds, minutes, hours, and days.

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

         • If sample data is loaded in the policy editor, 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.

      6. Optionally, enter any additional connection properties needed by the database to which you are connecting. See the database documentation for details.

   2. Select the Collection tab and specify the SQL query:

      1. An SQL statement to query the data.

         Write a query that fits the database you are using and the type of data you are querying.

         For example, a basic query might look like this:

         "select {* | <column>[,<column>...] [,<column> ...]} from <table>[,<table>...] [where <SQL clause to define select criteria>"]

         select clause: enter * for all fields or a comma separated list of column names to be retrieved from the database.

         from clause: enter a table name or a comma separated list of tables from which the selected columns should be extracted.

         where clause: enables you to define the selection criteria. If you not define it, all the rows from the table defined in the from clause are retrieved.

         The queries are not limited to this example set and you can write more complex ones that suit your needs.

         Click to retrieve the specified table columns from the database. The results are displayed in the Sample Data tab of the policy.

         See the example at the end of this step to see how you can connect the SQL statement, the initial value statement, and the memento.

      2. Define initial values for keys by setting up the Session Variables.

         Click to add a new field. Type the name of the key and its initial value. Alternatively, you can drag and drop entries from the Initial value sample data tab.

         Note It is recommended that you set up a session variable for each key. If no records are found with the initial value statement, the value set up in the session variable is used to replace the key in the executable SQL statement. Without an initial value the SQL statement for the execute method is not valid.

         See the example at the end of this step to see how you can connect the SQL statement, the initial value statement, and the session variable.

      3. Enter the Initial value statement.

         An SQL statement that is executed in the init method. It can be used to initialize the data map with values. The values returned as last record from the execution of the statement are copied to the data map and returned.

         Click to retrieve the specified table columns from the database. The results are displayed in the Initial Value Sample Data tab of the policy.

      Example:

      The following example shows how you can set up a combination of an SQL statement, an initial value statement, and a session variable to query the table "dbo.ALL_EVENTS" that contains the columns "ID", "TITLE", and "TIME_RECEIVED", and to collect all new records after the activation of the policy.

      SQL statement:

      "select ID,TITLE,TIME_RECEIVED from dbo.ALL_EVENTS where TIME_RECEIVED > '<$DATA:TIME_RECEIVED>' order by TIME_RECEIVED;"

      <$DATA:TIME_RECEIVED> will be replaced with the current value of TIME_RECEIVED in the data map. Therefore this SQL statement will return all new records that are added to the table after the SQL init statement was called and set the value in the data map.

      Initial value statement: The following initial statement is used to fill the data map when the policy is activated:

      "select top 1 ID,TIME_RECEIVED,TITLE from dbo.ALL_EVENTS order by TIME_RECEIVED DESC;"

      This statement returns the newest record from the table. The values of the three columns are stored in the data map and can later be accessed in the SQL statement.

      Session variables: TIME_RECEIVED "2014-09-09 00:00:00.000"

      This is the initial value for the key TIME_RECEIVED. If no records are found with the initial SQL statement, this value is used to replace <$DATA:TIME_RECEIVED> in the executable SQL statement.

   3. Optionally, select the Internals tab and modify the default settings for the:

      1. Fetch Size - the maximum number of entries the policy sends at once.
      2. Result size - the maximum number of entries the policy retrieves from the database in each run.

      By adjusting the fetch and result sizes you can balance the loads on the database and the Operations Connector system.

3. In the events and metrics policies, in the Mappings page, configure mappings for table columns.

   1. Create one or more custom variables.

      If you are working with sample data, drag the table column from the table column list to the Map Name column. Operations Connector 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. Columns are optional. If you do not assign a column to a variable, you must add the source value directly to the variable when you insert the variable in an event attribute.

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

      • If sample data is loaded in the policy editor, 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, configure mappings for key fields.

   1. Create one or more key field mappings.

      If you are working with meta data, drag the table column from the Meta Data list to the Input Field Qualifier column. Operations Connector automatically extracts the eligible field name.

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

   2. Optionally, 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, deselect the option.

   3. Add any additional fields as required.
5. Optional for events. In the Defaults page, configure event defaults.

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

      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 city location to an event.

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

   5. Optional. Use the Sample Data tab to drag table columns and values to the policy fields. Alternatively, you can type the path to the table column directly into the attribute box.

      Table columns use the following syntax: <$DATA:<TableColumn>>

      <TableColumn> is the name of the table column in the third-party database.

      The agent replaces the table column at runtime with the value of the specified column. If you insert a column value, the value will be used.

      Note The Sample Data tab is empty if no sample data has been loaded into the policy or if the database query did not succeed.

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

      Mappings are custom variables that you define in the Mappings page.

      Custom variable into the attribute box using the following syntax:

      <$MAP(<CustomVariable>)> where <CustomVariable> is the map name of the variable (for example, <$MAP(mapSEVERITY)>).

      If the custom variable does not have a table column Input Data Property, use the following syntax:

      <$MAP(<CustomVariable>,<<SourceValue>>) where <SourceValue> can be one of the following:

      • Name of the table column, for example <$MAP(mapSEVERITY)>,<$DATA:SEVERITY>

      • The source value itself, for example <$MAP(SEVERITY)>,Critical)>

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

   8. 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, configure metrics defaults.

   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 table columns and values to the policy fields. Alternatively, you can type the table column directly into the attribute boxes.

      Table columns use the following syntax: <$DATA:<TableColumn>>

      <TableColumn> is the name of the table column in the third-party database.

      The agent replaces the table column at runtime with the value of the specified column. If you insert a column value, the value will be used.

      Note The Sample Data tab is empty if no sample data has been loaded into the policy or if the database query did not succeed.

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

      Mappings are custom variables that you define in the Mappings page.

      Custom variable into the attribute box using the following syntax:

      <$MAP(<CustomVariable>)> where <CustomVariable> is the map name of the variable (for example, <$MAP(mapSEVERITY)>).

      If the custom variable does not have a table column Input Data Property, use the following syntax:

      <$MAP(<CustomVariable>,<<SourceValue>>) where <SourceValue> can be one of the following:

      • Name of the table column, for example <$MAP(mapSEVERITY)>,<$DATA:SEVERITY>

      • The source value itself, for example <$MAP(SEVERITY)>,Critical)>

   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 policies, in the Rules page, define rules for events.

   1. In the policy Rules section, click and select the type of rule to define what the policy should do in response to a specific value in a table column. Each policy must have at least one rule.

   2. In the Rule Content section, use the Condition tab to specify the table column and values that the policy searches for in the database that the policy accesses. If the policy finds a match, it may or may not generate an event, depending on the rule type.

      1. Click 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 name of the table column that the policy searches (for example, SEVERITY).

         If you are working with sample data, you can drag and drop the table column from the Table Column 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. For a list of available operators, see Condition Tab.

      5. In the Operand field, type the value or pattern that you want the policy to compare with the table column. If you are working with sample data, you can drag the value from the Values list and drop it in the Operand field.

   3. Use the Event Attributes tab to define event attributes (for example, event title and description) for all events generated by this rule.

      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.

   4. Use the Event Correlation tab to set the type of duplicate event suppression and define the method used to suppress duplicate events.

   5. Use the Custom Attributes tab to add additional information to all events generated by this rule. For example, you might add a company name, contact information, or a city location to an event.

   6. Use the Advanced tab to define an event drill-down URL, legacy HPOM attributes, and agent MSI (Message Stream Interface) settings.

   7. Optional. Use the Sample Data tab to drag table columns and values to the policy fields. Alternatively, you can type the path to the table column directly into the attribute box.

      Table columns use the following syntax: <$DATA:<TableColumn>>

      <TableColumn> is the name of the table column in the third-party database.

      The agent replaces the table column at runtime with the value of the specified column. If you insert a column value, the value will be used.

      Note The Sample Data tab is empty if no sample data has been loaded into the policy or if the database query did not succeed.

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

      Mappings are custom variables that you define in the Mappings page.

      Custom variable into the attribute box using the following syntax:

      <$MAP(<CustomVariable>)> where <CustomVariable> is the map name of the variable (for example, <$MAP(mapSEVERITY)>).

      If the custom variable does not have a table column Input Data Property, use the following syntax:

      <$MAP(<CustomVariable>,<<SourceValue>>) where <SourceValue> can be one of the following:

      • Name of the table column, for example <$MAP(mapSEVERITY)>,<$DATA:SEVERITY>

      • The source value itself, for example <$MAP(SEVERITY)>,Critical)>

   9. Optional. Use the Pattern Matching Variables tab to add variables created with pattern matching.

      Pattern matching variables insert matched strings that have previously been assigned to variables. To insert a pattern matching variable, type the variable name enclosed in angle brackets (for example, <VariableName>) or drag and drop it from the Pattern Matching Variables list to the eventmetricevent or metric attribute.

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

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

8. In the metrics policies, in the Rules page, define rules for metrics.

   1. In the policy Rules section, click and select the type of rule to define what the policy should do in response to a specific string in the table column. Each policy must have at least one rule.

   2. In the Rule Content section, use the Condition tab to define the match condition.

      Click to create a new condition. Enter the property and select the operator from the drop-down list. Add the operand. Use the arrows and collapse/expand buttons to navigate the conditions.

   3. Optional. If you are creating a rule of the type 'store on matched rule', set the attributes (Basic or/and Advanced) for metrics that you want the rule to override. If default attributes are specified in the Defaults tab, you use the defaults or you can override them as described below.

      The attributes are in two groups, basic and advanced. The metrics in the Basic tab are required. Advanced attributes are optional.

   4. Optional. Use the Sample Data tab to drag table columns and values to the policy fields. Alternatively, you can type the table column directly into the attribute boxes.

      Table columns use the following syntax: <$DATA:<TableColumn>>

      <TableColumn> is the name of the table column in the third-party database.

      The agent replaces the table column at runtime with the value of the specified column. If you insert a column value, the value will be used.

      Note The Sample Data tab is empty if no sample data has been loaded into the policy or if the database query did not succeed.

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

      Mappings are custom variables that you define in the Mappings page.

      Custom variable into the attribute box using the following syntax:

      <$MAP(<CustomVariable>)> where <CustomVariable> is the map name of the variable (for example, <$MAP(mapSEVERITY)>).

      If the custom variable does not have a table column Input Data Property, use the following syntax:

      <$MAP(<CustomVariable>,<<SourceValue>>) where <SourceValue> can be one of the following:

      • Name of the table column, for example <$MAP(mapSEVERITY)>,<$DATA:SEVERITY>

      • The source value itself, for example <$MAP(SEVERITY)>,Critical)>

   6. Optional. Use the Pattern Matching Variables tab to add variables created with pattern matching.

      Pattern matching variables insert matched strings that have previously been assigned to variables. To insert a pattern matching variable, type the variable name enclosed in angle brackets (for example, <VariableName>) or drag and drop it from the Pattern Matching Variables list to the eventmetricevent or metric attribute.

   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.

9. Optional. In the Options page, configure options for local event logs, unmatched events, and pattern matching.

   For details, see Options Page.

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

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

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, and Advanced Tab (Default Event Attributes), and Actions Tab.

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

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.

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.

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

The Source page enables you to configure

For details , see Connection Tab, Collection Tab, and Internals Tab.