Condition Matching Optimization

Note: HP renamed the product called now HP operations manager way too many times. Also it is very inconsistent with using abbreviations. Here we will assume that the term "HP Operations manager" and abbreviations HPOM, OMU, and OVO  mean the same thing :-)

HPOM message processing mechanism is based on applying to incoming messages a set of rules called conditions. They are applied sequentially so the order is important. 

The sequence in which conditions display within a policy determines the type and number of messages processed through the system. In principle, a policy that begins with suppress unmatched or suppress conditions (thus filtering out unwanted messages from the start) demands less processing than a policy in which the message conditions are placed first. Fewer messages to match reduces processing and increases performance.

You can filter messages on the managed node and on the management server:

• Managed Node Filtering out as many messages as possible on the managed node minimizes network traffic and reduces the load on the management server.
• Management Server Filtering on the management server enables you to compare and correlate messages from several nodes. If so configured, the management server can maintain a counter of suppressed messages. Regroup conditions let you customize the grouping of messages that operators see in the Java GUI Message Browser. Regroup conditions are not used to filter out messages. For more information about regroup conditions, see “Regrouping Messages” on page 379. Optimizing Performance

Using Suppress Unmatched Conditions

Suppress Unmatched conditions enables you to stop the matching process for events not “intended” for a particular policy. Suppress Unmatched conditions suppress events that do not match the specified pattern, but allow events that match to be processed by the conditions in the list. Message suppression improves performance on the managed node because HPOM processes only those events intended for the policy.

For example, to improve performance of SNMP trap filtering, create one policy for each class of devices that are occurring in your environment. Then place a Suppress Unmatched condition first in the list of conditions. HPOM suppresses SNMP traps from MIB objects not matching the condition, and only processes the SNMP traps intended for that policy.

Reducing the Number of Messages

Operators are often overwhelmed by the number of messages HPOM sends to their message browsers:

• Related Messages Some messages are related to each other (for example, an application stops and starts up again).
• Similar or Identical Events Some messages report similar or identical events (for example, a user switches to user root three times).
• Problem Deterioration Some messages report how a problem situation deteriorates (for example, the amount of free disk space decreases on a managed node). HPOM can be configured so operators receive only important and relevant messages. Messages that relate to the same or to a similar problem can be suppressed, or correlated and replaced with a new, more meaningful message. Correlating Messages and Events Message replacement is achieved through message correlation and event correlation.
• Message Correlation Message correlation can be achieved with built-in HPOM mechanisms, but offers only basic correlation techniques. Message correlation is recommended if you want to get started with correlation techniques and then proceed to a more sophisticated solution.
• Event Correlation Event correlation is the more sophisticated solution but requires the purchase of special event correlation products (for example the HP ECS Designer for NNM and HPOM). For details about event correlation, see “Event Correlation in HPOM”
  •  Message Correlation
    • Default EC policies delivered with HPOM.
    • Easy to configure, but supports only simple correlation tasks.
    • Only suppression or automatic acknowledgment is possible.
      • Automatic Acknowledgement Automatically acknowledges the message to which a relation was established
      • Duplicate Message Suppression Suppresses duplicate messages. If duplicate message suppression is enabled on the management server, HPOM also keeps a counter of the suppressed messages.
    • No separate purchase is necessary.
    • All data is processed by HPOM. Performance is not affected.
• Purchase of the event correlation product is required (for example, HP Event Correlation Designer for NNM and HPOM).
• More difficult to set up and maintain, but supports complex conditions.
• Handles event streams. Events can change their state while they are processed by the event correlation engine. Identical input events can generate different output events, depending on the current state.
• Static message handling.
• “Annotate node” concept of HP Event Correlation Designer allows you to attach different actions to the output events.
• Data is exchanged between HPOM and the event correlation product.
• Loss of data is possible when event correlation services go down.
• All data is processed by HPOM. If HPOM goes down, data is stored in a database. a. If enabled on the management server, suppressed messages are also counted. Implementing Message Policies Strategies for Optimal Message Filtering 360 Chapter 4 Message Correlation Message correlation describes the mechanism by which HPOM compares similar or identical events and messages. HPOM reacts to events and messages in one of two ways:
•  (see “Automating Standard Scenarios” on page 363).

Guidelines for Effective Message Keys

Effective message keys provide a concise description of the event that triggers a message. Message keys should contain only important information about the event. They should exclude unnecessary data, such as time stamps or fill words. Effective message keys can be used for state-based browsers (see “Automating Standard Scenarios” on page 363) and for suppressing duplicate messages (see “Suppressing Duplicate Messages” on page 367). To build effective message keys, follow these guidelines:

• Include the Node Name in the Message Key Incorporate the HPOM variable $MSG_NODE_NAME. This variable ensures that messages generated on one computer have a different message key from messages generated on another computer. Implementing Message Policies Strategies for Optimal Message Filtering Chapter 4 361 Example: my_appl_down:<$MSG_NODE_NAME>
• Include Other Important Message Attributes A message key should take into consideration all message attributes that describe the important aspects of the message. Typical attributes are node, object, application, severity, service name, monitor name (when defining a condition for a threshold monitor policy), or any variables that are defined in the Condition section. Example: appl_status:<$MSG_APPL>:<$MSG_OBJECT>:<$MSG_NODE_NAME> For a list of HPOM variables that can be used, see the HPOM Administrator’s Reference.
• Reflect the Severity of the Message Messages with different severities should have different message keys. This does not necessarily mean you should include the severity string itself in the message key. Try to reflect the severity by including the cause of the severity level. The cause is included in the message information itself. For example, for threshold monitor policies, the variable <$THRESHOLD> can be included. Each value of <$THRESHOLD> represents a distinct severity level.
• Enable HPOM to Generate a Default Key To generate a default message key along with a default message key relation for each condition of the policy, use the AUTOMATIC_MSGKEY keyword, optionally followed by a string value. This keyword also supplies existing conditions with a message key. For more information about message key relations, see “To Generate a Default Message Key and Message Key Relation” on page 364.
• Improve Readability Separate the components of a message key from each other, for example, with colons (:). Example: my_appl_down:<$MSG_NODE_NAME> Implementing Message Policies Strategies for Optimal Message Filtering 362 Chapter 4 Guidelines for Effective Message Key Relations To build effective message key relations, follow these guidelines:
• Watch Out for Variable Resolution Message key relations consist primarily of HPOM variables that are resolved on the managed nodes. Relations can also contain HPOM pattern definitions. The patterns are matched on the management server.
• Improve Readability Separate the components of a message key relation from each other (for example, with colons (:)). Example: my_appl_down:<$MSG_NODE_NAME>
• Enclose Relations in Anchoring Characters Enclose message key relations in anchoring characters. Use the caret (^) as the first character, and the dollar sign ($) as the last. This improves processing performance. Example: ^<$NAME>:<$MSG_NODE_NAME>:<$MSG_OBJECT>:<*>$
• Place Pattern Definitions in the Correct Location If you use pattern definitions in message key relations, place them into the right part of the relation string. Correct pattern-definition placement improves processing performance. Example of pattern definitions in the right place: ^<$MSG_NODE_NAME>:abcdef:[pattern]$ Example of pattern definitions in the wrong place: ^[pattern]:<$MSG_NODE_NAME>:abcdef$
• Specify Case-sensitive Check and Field Separators For a list of HPOM variables that can be used when defining which messages are to be acknowledged, see the HPOM Administrator’s

The following example illustrates this: Problem Resolution

A first message might report a problem. Then, a second message might report that the problem has been solved (for example, if a user fails to log on because of an incorrect password, but succeeds with a second attempt). Or it might report that the problem has deteriorated. In either case, the first message would no longer be relevant. For this reason, you would want to the second message to automatically acknowledge the first message.

HPOM enables you to automate such scenarios (for example, an application shutting down and starting up again).