Administer > Monitoring > Policy Templates > Configure Service/Process Monitoring Policies

Configure Service/Process Monitoring Policies

Service/process monitoring policies enable you to monitor the status of services (on Windows) and processes (on any operating system that the HPE Operations Agent supports). You can configure the policies to create events and launch commands when a change occurs in either the status of a service or the number of running processes.

ClosedTo access

You can create or edit a Perl Script policy using the Perl Script policy editor, which you can open in the following ways.

You can create or edit a Service/Process Monitoring policy using the Service/Process Monitoring 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 Perl Script, and then click OK.

        4. Select the type Service/Process Monitoring, 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 Perl Script policy editor opens.

      The Service/Process Monitoring 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 Perl Script 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 Perl Script 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 Perl Script policy editor opens.

    5. Click the Service/Process Monitoring item, 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 Template Add New Policy Template or the Edit Policy Template Add New Policy Template (Raw Mode) button.

        The New Service/Process Monitoring 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 Service/Process Monitoring policy editor opens.

Learn more

ClosedDefault and Custom Actions

A service/process monitoring policy can run an action when a change occurs in the status of a service or the number of running processes. The following types of action responses are available:

  • Start action. A start action is triggered when the service is not in the state you specified, or the number of processes, CPU utilization, or memory usage is not as you specified.

  • Continue action. After the start action runs, continue actions are carried out at each subsequent polling interval if the reset value is not reached.

  • End action. After the start action runs, end actions are carried out after the service or process returns to the expected state.

You can configure default actions, which apply to all service or process monitors. You can also configure custom actions in policy rules. Custom actions apply to individual service or process monitors. By default, service or process monitors do not have any default actions specified.

ClosedDefault Session Object Values

You can also use some default session object values in event and command text boxes. The agent automatically sets these values for service/process monitoring policies.

  • Session object values for service monitoring policies. The agent automatically sets the following values in the session object for service monitor policies:

    <$SESSION(SERVICENAME)>

    Returns the name used to access the Windows service on the node.

    <$SESSION(SERVICEDISPLAYNAME)>

    Returns the display name of the Windows service. This value is retrieved on the specified node and can be displayed in the local language of the node.

    <$SESSION(SERVICEMONITORSTATE)>

    Returns the state of the Windows service to monitor, for example; "running", "stopped", or "disabled". If an agent catalog is available in the local language set on the node, this is the localized text for the monitor state. If no agent catalog is available in the local language of the node, English text is used to display the monitor state.

    <$SESSION(SERVICECURRENTSTATE)>

    Returns the current state of the Windows service being monitored, for example; "running", "stopped", or "disabled". If an agent catalog is available in the local language set on the node, this is the localized text for the monitor state. If no agent catalog is available in the local language of the node, English text is used to display the monitor state.

    <$SESSION(SERVICEACTION)>

    Returns the string used to build the event title. It depends on the monitor mode you define:

    • Monitor state "running"

      net start /Y <service_name>

    • Monitor state "stopped"

      net stop /Y <service_name>

    • Monitor state "disabled"

      empty

  • Session object values for process monitoring policies. The agent automatically sets the following values in the session object for process monitor policies:

    <$SESSION(PROCESSNAME)>

    Returns the name used to access the process on the node.

    <$SESSION(PROCESSPARAMETERS)>

    Returns the parameter pattern used to access the process on the node.

    <$SESSION(PROCESSNBREXPECTED)>

    Returns the number of monitored processes.

    <$SESSION(PROCESSNBRAVAILABLE)>

    Returns the number of available processes matching the process name and parameter pattern.

    <$SESSION(PROCESSCPUUSAGEEXPECTED)>

    Returns the percentage of CPU usage that you expect the process to use.

    <$SESSION(PROCESSCPUUSAGE)>

    Returns the percentage of the current CPU usage of the monitored process.

    <$SESSION(PROCESSMEMUSAGEEXPECTED)>

    Returns the amount of memory (in megabytes) that you expect the process to use.

    <$SESSION(PROCESSMEMUSAGE)>

    Returns the current memory usage of the monitored process.

    <$SESSION(PROCESSMODE)>

    Returns the string used to build the message text. It depends on the monitor you specify, for example:

    • MIN

      PROCESSMODE is: ">= "

    • MAX

      PROCESSMODE is: "<= "

    • EQUAL

      PROCESSMODE is: " " (empty string)

Tasks

ClosedHow to create a service/process monitoring policy

  1. In the Service/Process Monitoring Policy Editor, 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, select Services or Processes, depending on what you want to monitor. Optionally modify the polling interval. The polling interval determines how often the policy checks the source for new information.

  3. Optional. In the Defaults page, configure start, continue, or end actions for the policy. Default actions apply to all service or process monitors. You can also configure custom actions in policy rules. Custom actions apply to individual service or process monitors. By default, service or process monitors do not have any default actions specified.

    For details, see Start, Continue, and End Actions (Defaults).

    In text boxes, you can use indicators, policy variables, and policy parameters. You can also use default session object values. The agent automatically sets these values for service/process monitoring policies.

    For details on the each event tab, see Event Attributes Tab, Event Correlation Tab, Custom Attributes Tab, Advanced Tab, and Actions Tab (Events).

  4. In the Rules page, define one or more policy rules. For each service or process that you want to monitor, add a rule by clicking the button.

    For details, see Policy Rules List.

  5. Service monitors only. In the Condition tab, define the service that you want to monitor and the state you expect:

    1. Type the real name of the Windows service you want to monitor.

    2. Optional. Type a Display Name of the monitor. The Display Name is used in the policy editor for information purposes only. It is not used to identify the Windows service.

    3. Select the state that you want to monitor for the selected Windows service. For example, the default monitoring status "Running" checks whether the selected Windows service is running. Other states include "Disabled" and "Stopped". If the policy detects a change in state for the selected Windows service, it starts the actions defined for the policy.

    4. Optional. Click Send event if service doesn't exist to ensure that you are informed if the Windows service is not present when you deploy the policy to the node.

  6. Process monitors only. In the Condition tab, specify the process that you want to monitor:

    1. Type the name of the process you want to monitor.

      For Windows nodes, the string you enter here must match the name of the process as it is known to Windows, including the file extension, for example: "notepad.exe". Duplicates are not allowed.

      For UNIX or Linux nodes, specify only the name of the executable file for the process that you want to monitor. Do not include the path.

    2. Optional. Define the strings or parameters that you need to match in the Parameters field. If you use this option, the parameters you specify are used to identify the running process. Standard pattern matching is used to evaluate the contents of this fields, which for Windows managed nodes are not case sensitive. Note that:

      • If the Parameters field is empty, the policy editor matches only processes running without parameters.

      • If the Parameters field contains a string with no pattern-matching characters, the policy editor matches only processes with the defined string.

      • If the Parameters field contains pattern-matching characters, the policy editor matches all process parameters with the string defined (for example, <*> matches all parameters, and <*>abc<*> matches all parameters containing the string "abc").

    3. Use the drop-down list to specify an operator, and the Number of processes text box to specify the number of processes that you expect to be running. Use the equals operator (==) to specify an exact value. Alternatively, use less than or equal to (<=), or greater than or equal to (>=) to define a range (for example, >=1).

    4. Optional. Use the drop-down list to specify an operator, and the CPU utilization text box to specify the percentage of CPU that you expect the process to use. Use the equals operator (==) to specify an exact value. Alternatively, use less than or equal to (<=), or greater than or equal to (>=) to define a range (for example, <=60).

    5. Optional. Use the drop-down list to specify an operator, and the Memory usage text box to specify the amount of memory (in megabytes) that you expect the process to use. Use the equals operator (==) to specify an exact value. Alternatively, use less than or equal to (<=), or greater than or equal to (>=) to define a range (for example, <=200).

    You can insert policy parameters in the text boxes of the Condition tab.

  7. Optional. Use the Actions tab to define how the policy responds when the status of a monitored service changes, for example from "running" to stopped", or when the number of processes, CPU utilization, or memory usage changes. Complete the following steps to configure custom actions for a service or process monitor:

    1. Click Override default actions.

    2. Click Edit the "Start Actions" event to open the Start Action tab. A start action is triggered when service is not in the state you specified or when the number of processes, CPU utilization, or memory usage is not as you specified.

      Use the event tabs in the Start Action tab to define the details of the event.

      For details on the each event tab, see Event Attributes Tab, Event Correlation Tab, Custom Attributes Tab, Advanced Tab, and Actions Tab (Events).

    3. Optional. If you want to configure continue actions, click one of the following:

      • Use the specified "Start Actions". This option enables you to send an event that is a duplicate of the start action event. In addition, if the start action has an automatic command, the agent starts this command again.
      • Define special "Continue Actions". This option enables you to configure an event and commands that are different to those in the start action.

      To configure the event that the continue action sends, click Edit the "Continue Action" event and use the tabs in the Continue Action tab to define the details of the event.

      For details on the each event tab, see Event Attributes Tab, Event Correlation Tab, Custom Attributes Tab, Advanced Tab, and Actions Tab (Events).

    4. Optional. If you want to configure an end action, click Start the specified "End Actions". Then click Edit the "End Action" event and use the tabs in the End Action tab to define the details of the event.

      For details on the each event tab, see Event Attributes Tab, Event Correlation Tab, Custom Attributes Tab, Advanced Tab, and Actions Tab (Events).

    In text boxes, you can use indicators, policy variables, and policy parameters. You can also use default session object values. The agent automatically sets these values for service/process monitoring policies.

  8. Click Save and Close to save the policy template and exit the wizard.

UI Reference

User interface elements are described below (listed alphabetically):

ClosedActions Tab (Events)

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.

ClosedActions Tab (Rules)
UI Element Description
Rule Actions

Use default actions: Applies the action settings configured in the event defaults to this rule.

Override default actions: Enables you to configure specific action settings for this rule.
Start Actions

A start action is triggered when the service is not in the state you specified, or the number of processes, CPU utilization, or memory usage is not as you specified.

Edit the "Start Actions" event: Opens the Start Action tab, which enables you to define a start action.
Continue Actions

After the start action runs, continue actions are carried out at each subsequent polling interval if the reset value is not reached.

Don't start any "Continue Actions": Select this option if you do not want to start any continue actions.

Use the specified "Start Actions": This option enables you to send an event that is a duplicate of the start action event. In addition, if the start action has an automatic command, the agent starts this command again.

Define special "Continue Actions": This option enables you to configure an event and commands that are different to those in the start action.

Edit the "Continue Action" event: Opens the Continue Action tab, which enables you to define a continue action.
End Actions

After the start action runs, end actions are carried out after the service or process returns to the expected state.

Start the specified "End Actions": This option enables you to configure an event and commands for the end action.

Edit the "End Action" event: Opens the End Action tab, which enables you to define an end action.
ClosedAdvanced Tab

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.

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

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

Override default settings for Agent MSI: Enables you to configure specific agent MSI settings for this policy rule.
ClosedCondition Tab
UI Element Description
Monitoring Services
Service Name

The real name of the Windows service that you want to monitor.

The policy editor does not check whether the Windows service you specify exists (for example, because you have not typed the service name correctly). Select the Send event if service does not exist option to ensure that you are informed if the Windows service you specify here is not present when you deploy the policy to the node.
Display Name

The Display Name is used in the policy editor for information purposes only. It is not used to identify the Windows service.

Monitoring

The state that you want to monitor for the selected Windows service. For example, the default monitoring status "Running" checks whether the selected Windows service is running. Other states include "Disabled" and "Stopped". If the policy detects a change in state for the selected Windows service, it starts the actions defined for the policy.
Send event if service doesn't exist Sends an event if the service specified in the policy is not present on the node when you deploy the policy.
Monitoring Processes
Process

The name of the process that you want to monitor.

For Windows nodes, the string you enter here must match the name of the process as it is known to Windows, including the file extension, for example: "notepad.exe". Duplicates are not allowed.

For UNIX or Linux nodes, specify only the name of the executable file for the process that you want to monitor. Do not include the path.

You can monitor multiple instances of a process by using parameters to differentiate between the instances (for example, svchost.exe -k rpcss and svchost.exe -k netsvcs). For more information, see Parameters below.
Parameters

Define the strings or parameters that you need to match. If you use this option, the parameters you specify are used to identify the running process. Standard pattern matching is used to evaluate the contents of this field, which for Windows managed nodes are not case sensitive. Note that:

  • If the Parameters field is empty, the policy editor matches only processes running without parameters.

  • If the Parameters field contains a string with no pattern-matching characters, the policy editor matches only processes with the defined string.

  • If the Parameters field contains pattern-matching characters, the policy editor matches all process parameters with the string defined (for example, <*> matches all parameters, and <*>abc<*> matches all parameters containing the string "abc").
Number of processes

Use the drop-down list to specify an operator, and the text box to specify the number of processes that you expect to be running. Use the equals operator (==) to specify an exact value. Alternatively, use less than or equal to (<=), or greater than or equal to (>=) to define a range (for example, >=1).

The value you enter here defines the state which the policy expects to find and considers correct. The policy sends an event only if the state it finds is not the expected one. For example, use >= 1 (greater than or equal to one) to check that one or more instances of a process are running. If the policy discovers that 0 (zero) instances of the process are running, it sends an event.

CPU utilization

Use the drop-down list to specify an operator, and the text box to specify the percentage of CPU that you expect the process to use. Use the equals operator (==) to specify an exact value. Alternatively, use less than or equal to (<=), or greater than or equal to (>=) to define a range (for example, <=60).
Memory usage

Use the drop-down list to specify an operator, and the text box to specify the amount of memory (in megabytes) that you expect the process to use. Use the equals operator (==) to specify an exact value. Alternatively, use less than or equal to (<=), or greater than or equal to (>=) to define a range (for example, <=200).
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.
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 (Critical, Major, Minor, Warning, Normal, Unknown).

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 value to match.

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

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

Reserved for future use.

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

Sets the event's lifecycle status to Closed before sending it to OMi.
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.
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.
ClosedPolicy Data Page

UI Element

Description
Load From Local File System

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

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

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

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

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

The policy editor highlights the policy syntax. If the policy exceeds 1,000 lines, syntax highlighting is automatically disabled. If the policy exceeds 1 MB in file size, the policy editor automatically asks you to download the policy to a file.
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

Create New Rule: Adds a rule to the service/process monitoring policy.
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.
<Search rules>

Entered search string is used to search the service or process names and highlight only the rules containing the specified string.

To search for rules with specific text strings in the service or process name, 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.

Number of the rule in the list.
Rules for service monitors
Service Name Name of the Windows service being monitored.
Display Name Display name of the Windows service being monitored.
Monitoring Expected state of the monitored service: Running, Stopped, Disabled
Rule Actions Actions configured for the rule: Default or Custom
Rules for process monitors
Process Name of the process being monitored.
Parameters String or pattern to match the parameters of the process.
Operator

equals operator (==)

less than or equal to (<=)

or greater than or equal to (>=)
Number of Processes Expected number of running processes.
Rule Actions Actions configured for the rule: Default or Custom
ClosedPolicy Variables Tab

You can use the following variables in Windows event log policies. If a variable returns values that contain spaces, surround the variable with quotation marks.

Policy Variables Tab for Database and REST Web Service Policies (Events only)

Variable Description
<$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_TEXT> Returns the full text of the event. Sample output: SU 03/19 16:13 + ttyp7 bill-root

Policy Variables Tab for XML File and Structured Log File Policies (Events only)

Variable Description
<$MSG_ID> Returns the unique identity number of the event, as generated by 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_TEXT> Returns the full text of the event. Sample output: SU 03/19 16:13 + ttyp7 bill-root

Policy Variables Tab for Open Message Interface, Scheduled Task, and SNMP Interceptor Policies (Events only)

Variable Description
<$MSG_ID> Returns the unique identity number of the event, as generated by the HPE Operations 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_TEXT> Returns the full text of the event. Sample output: SU 03/19 16:13 + ttyp7 bill-root
<$NAME> (Scheduled Task Only) Returns the name of the policy that sent the event. Sample output: cpu_util

Policy Variables Tab for All Policy Types (Metrics only)

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.
ClosedSource Page
UI Element Description
Monitoring Choose whether to monitor the status of services (on Windows) or processes (on any operating system that the HPE Operations Agent supports).
Polling Interval

Indicate how often the policy should check the source for new information. This period of time is the polling interval.

To increase performance, the polling interval should be as large as possible, while still being frequent enough to monitor data at the rate that it is expected to change. A policy begins to evaluate data after the first polling interval passes. A shorter polling interval is better when you are testing a policy.

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

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

Note The Default Start, Continue, and End Action pages enable you to configure default settings for any actions started by the policy. For details on the each tab, see Event Attributes Tab, Event Correlation Tab, Custom Attributes Tab, Advanced Tab, and Actions Tab (Events).

UI Element Description
Define default start actions A start action is triggered when the service is not in the state you specified, or the number of processes, CPU utilization, or memory usage is not as you specified.
Define default continue actions After the start action runs, continue actions are carried out at each subsequent polling interval if the reset value is not reached.
Define default end actions After the start action runs, end actions are carried out after the service or process returns to the expected state.
ClosedStart, Continue, and End Actions (Rules)

UI Element

Description
Event Attributes Enables you to set the attributes of the start, continue, or end event.
Event Correlation Enables you to set correlation options for the start, continue, or end event.
Custom Attributes Enables you to add custom attributes to the start, continue, or end event.
Instructions Enables you to add instruction information to help operators handle the start, continue, or end event.
Advanced Enables you to set the advanced attributes of the start, continue, or end event.
Actions Enables you to add automatic and operator-initiated commands to the start, continue, or end event.

Send Help Center feedback