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 :-)
processing mechanism is based on applying to incoming messages a set of
rules called conditions. They are applied sequentially so the order is
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:
Optimal processing performance can be achieved
easily by putting the conditions into a sequence and by deploying Suppress
- Managed Node Filtering out as many messages as possible on the managed
node minimizes network traffic and reduces the load on the management
- 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
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
- (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:
Automating Standard Scenarios Sometimes, you may want to acknowledge messages
- 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
- 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
- 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.
- 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).