Administer > Policies > XML File Policies > XML File Policy User Interface > Configuring Event Rules in XML File Policies

Configuring Event Rules in XML File 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 Operations Connector 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 access

In the Operations Connector user interface, click Create in the toolbar. Then click Event > XML XML File.

Click Rules to open the policy Rules page.

Rule types

The rule types are:

  • Event on matched rule. If matched, Operations Connector 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, Operations Connector stops processing and does not send an event to OMi.

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

Tasks

How to configure event rules in XML policies

This task describes how configure policy rules.

  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 XML file. Each policy must have at least one rule.

  2. In the Rule Content section, use the Condition tab to specify the XML properties and values that the policy searches for in the XML file that the policy reads. 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 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 slash marks (/) (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 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.

    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.

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

    Operations Connector 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.

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

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

    Mappings are custom variables that you define in the mappings tab. 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.

  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 event 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 event attributes. Operations Connector replaces the variables with the appropriate values in the generated event.

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

Related tasks

UI Descriptions

Policy Rules List

UI Element

Description

Create New Rule: Provides the following options:

  • Event on matched rule. If matched, Operations Connector 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, Operations Connector stops processing and does not send an event to OMi.

  • Suppress on unmatched rule. If not matched, Operations Connector stops processing and does not send an event 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

The three rule types are:

  • Event on matched rule. If matched, Operations Connector 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, Operations Connector stops processing and does not send an event to OMi.

  • Suppress on unmatched rule. If not matched, Operations Connector stops processing and does not send an event 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.

Condition 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

Input data property that the policy searches for (for example, host).

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.

Event 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.Operations Connector 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.Operations Connector 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 offsett 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 <$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, Operations Connector adds 12 hours to the hours that precede the variable.

    VALUE is the XML property or value to match.

    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.

    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:/SCOM_Alert/TimeRaised>, type
    <$DATETIME("^<#.m>/<#.d>/<#.y> <#.H>:<#.M>:<#.S>$",<$DATA:/SCOM_Alert/TimeRaised>)>

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

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

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

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

    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 third-party system that provides events (for example, NNMi@@mgmt1.example.com or SCOM@@mgmt2.example.com).

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

Source Event ID

ID of the event in the third-party system. This ID is required for synchronization of event changes with the source event. It also enables drilldown into the third-party system in the Event Browser in OMi.

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.

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)

Click and select yes or no from the menu.

Event 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$
An Operations Manager i Event Management Foundation License is required  to enable the Close Events with Key feature in OMi
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.

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

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

Override default settings for Event Suppression: Enables you to configure specific event suppression settings for this policy rule.
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 detailed 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 detailed 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.

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

Time interval after which duplicate events are no longer ignored.
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.

Custom Attributes Tab

UI Element

Description
Create New Custom Attribute:

Create New Custom Attribute: Creates a new custom attribute.

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.

Advanced Tab

UI Element

Description
Event Drilldown
Event Drilldown URL

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

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

To drill down to a specific event in the third-party system, add the source event ID to the URL. If you are working with sample data, you can drag the source event ID from the Sample Data tab and add it to the Event Drilldown URL field.

This event attribute can also be set by OMi based on an Operations Connector integration server configuration. If a policy and an integration server configuration both set this attribute, the information in the policy takes precedence.

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

The attribute is automatically set to BSMC_Message. You can delete the value but it will be inserted when you save the policy.
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

 The message stream interface (MSI) allows external applications to interact with the internal event flow of Operations 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 If Agent MSI is enabled, diverts an event to the MSI instead of to the server when an event is requested by an external application.
Copy events If Agent MSI is enabled, sends the event to the server, and a copy of the event to the MSI.

Sample Data Tab

UI Element Description
<Search Properties>

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

To clear the search results, click .
XML Properties

Shows all XML elements and attributes that match an XML tag.

The XML properties list is empty if no sample data has been loaded into the policy or if the sample data does not match any specified XML tags.

Toggle Short/Full Path Notation. Shows or hides the full path to the XML property or value. The full path begins with the XML tag specified in the Source tab. The XML Properties section by default shows the short path to the XML property or value.
Values for '...'

Displays the values of the XML property 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 XML Sample Data window opens and shows all XML properties that have the selected value.
Toggle Deduplication. Shows or hides duplicate values.

Mappings Tab

UI Element Description
<Mappings>

Displays the mapping definitions configured for the policy.

Pattern Matching Variables Tab

UI Element Description
<Variables>

Displays the user-defined variables configured in the Condition tab. For more information about assigning strings to variables, see User-defined variables in patterns topic.

Indicators Tab

UI Element

Description

Refresh. Loads the configured indicators from the connected OMi server.

  • Loading indicators from the OMi server may take a few seconds.

  • The Operations Connector server must be configured as an Operations Connector integration server in OMi for the indicators to load successfully.

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

Policy Variables Tab

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

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.
<$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 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_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.

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

Variable Description
<$LOGFILE> Returns the name of the log file that contains the input event. Sample output: program_log.txt
<$LOGPATH> Returns the name and path of the log file that contains the input event. Sample output: C:\temp\mylogfile\program_log.txt
<$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.
<$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 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.

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

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.
<$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 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_SERVICE> Returns the service name associated with the event.
<$MSG_OBJECT> (Open Message Interface and Scheduled Task Only) 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.

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.
<$MSG_GEN_NODE_NAME> Returns the host name of the node that sends the event. Sample output: node123.example.com.

Send Help Center feedback