May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Condition Matching Optimization

News Policies Recommended Links  Regex used in conditions Actions Message Keys Automatic acknowledgement
Condition Matching Optimization Event Correlation Correlation Composer Duplicate Message Suppression Humor Etc  

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:

Optimal processing performance can be achieved easily by putting the conditions into a sequence and by deploying Suppress Unmatched conditions.

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:


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

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