Softpanorama

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

HPOM Conditions

News HP HPOM Policies Recommended Links HPOM Patterns Policy variables Actions
Rewriting of Messages Duplicate Message Suppression Condition Matching Optimization   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 :-)

Essentially this type of policy is a complex multilevel pattern matching rule with some subject area specific twists.

 Policy include one or more conditions that select appropriate messages from the message stream for processing. In other words condition is the term for rules against which each event is checked. Each condition consists of three major parts

Edition conditions

After you create a condition you can edit it. The top bar for each conditions contains seven submenus:

The firs and the most important submenu is "Condition". Here you specified predicate by which message will be matched.

Typically you do not need to be fancy and can match message based on application field of the message (option -a in opcmsg).

Note: After typing an appropriate field you need  to press Enter to move the input field down. Only when the text you entered "migrates down" and input field became clean you can be save it. Otherwise your input will be lost.

If match is found then some processing will occurs. If nor event is discarded or processed by default mechanism that can send it intact to the message browser.  Conditions can either "suppress" the event or "transform" the event into message. Actually there are three types of conditions:  

Conditions within a policy are  numbered and are evaluated sequentially. The first condition to match the event ends processing and none of  subsequent conditions is checked against this event. That means that when you build a set of conditions, more precise conditions should be in the top and more generic in the bottom.  Unless you set of conditions consumes all messages of the particular type the last condition should be  Suppress Unmatched Condition.

Conditions within a policy are  numbered and are evaluated sequentially. The first condition to match the event ends processing and none of  subsequent conditions is checked against this event.

Conditions match the message against several  attributes. Among them are

 HPOM compares each incoming message with each condition in the order they are listed in the policy body.

You can set up as many message, suppress, and suppress unmatched conditions as you need. I saw policies that analyze log files with hundreds of conditions. Such policies are difficult to maintain and are generally counterproductive, but it looks like to have tremendous amount of conditions is quite possible.  Not that it is recommended.

To set up conditions, follow these steps:

  1. Define Match Conditions Define a matching pattern that will be used to match messages that will be processed by this condition (incoming events)
  2. Test the pattern. Test to make sure that the pattern matching works as expected and picks up only the extected messages -- no missing  and no "foreign" (accidentally captured) messages.
  3. Set Up Message Correlation  Set up message correlation options to automatically acknowledge messages with a specific message key. That can help to eliminate frequently repeated messages and prevent cluttering up the Java GUI Message Browser.
  4. Configure Operator-initiated Actions Configure operator-initiated actions so that, every time a selected message is matched, HPOM allows a selected operator to run a script or program that you have configured.
  5. Configure Automatic Actions Configure automatic actions so that, every time a message is matched, HPOM runs a script or program automatically.
  6. Select the format and wording of output message. Configure output message.  This is the test that will be displayed to operators in Java GUI Message Browser.
  7. Define Message Attributes Define the attributes of the message to be displayed in the Java GUI Message Browser. These attributes are not necessarily the same as those for the original text matched from the message source.
  8. Define Custom Message Attributes Define your own message attributes of the message to be displayed in the Java GUI Message Browser to provide operators with more relevant information about the message. Implementing Message Policies
  9.  Write Instructions Write instructions to accompany the message displayed in the Java GUI Message Browser.

If you do not define any filters for a message source, all messages from that source are brought into HPOM for processing, provided you have chosen to forward unmatched messages to the management server.

HPOM provides a  pattern-matching language that permits  parts of messages to be extracted, assigned to variables, and used as parameters to build new message text or to set other attributes. These parameters can also be used for automatic and operator-initiated action commands. For a full list of HPOM and SNMP variables, see HP Operations Manager/Policy variables

Pattern Matching

See HPOM Patterns

Transformation rules

After a message matches a message condition, you can assign certain settings to the message before it is displayed in a browser. Assigning Message Settings You can assign new values for the following settings:

Any attribute set at the condition level overrides the value of the same attribute set by the policy defaults. You can also use part of the message text as a parameter to redefine the message text before the message is forwarded to an operator’s browser.

Custom message attributes allow you to add your own attributes to a message. This means that in addition to the default message attributes, you can extend HPOM messages with attributes of your choice, for example, the attribute “Customer” or the attribute “SLA” for service level agreements. Custom message attributes can only be set for message conditions and are only available for log file, HPOM interface, and threshold monitor policies.

The simplest way to specify the transformation is using Admin GUI.

You can also use that command opccmachg to assign attributes of your choice to a message. For more information, see the opccmachg(1m) manpage. When creating and assigning custom message attributes, you can specify attribute name and value, for example:

# opccmachg -user opc_op -id 
55d3604a-536f-71db-08c0-0a1108c90000 CUSTOMER=VIP SLA=none Device=Device1 Source=Node1 

A message matching the following condition would display with four additional columns in the Java GUI browser:

The values can contain one or more of the following: For more information, see the HPOM Administrator’s Reference.

NOTE: Custom message attributes are only displayed in the browser and message properties windows of the Java GUI.

If so configured, custom message attributes are passed to the Message Stream Interface (MSI) on the agent, the management server, or both. Custom message attributes are also passed to the trouble ticket system, the notification service, or both.

Adding Instructions to Your Message

You can add instructions to your message. Typically, these instructions describe an automatic action, provide details of how an operator should perform an operator-initiated action, or describe other manual steps for resolving a problem.

To add instructions to your message, use one of the following methods:

Responding to a Message

HPOM provides several options for responding to messages that match conditions. Operators use some of these options in Message Browser to respond to messages. Some of these responses are transparent to operators.

Responses You can choose from the following response types:

As a general rule, in instructions, you enter details about the operator-initiated actions, so operators know what exactly will be executed when the operator-initiated action is started. Normally, an operator-initiated action requires some kind of operator interaction. Or operators must set up or verify some type of prerequisite. Examples: You can forward messages to a trouble ticket system or external notification service. In addition, you can configure automatic acknowledgments after forwarding a message. Configuring Automatic Annotations and Acknowledgments For both automatic and operator-initiated actions, you can configure automatic annotations and automatic acknowledgments. An automatic annotation logs the following: If an action fails, an annotation is automatically written. When you configure an automatic acknowledgment for an action, the message is acknowledged automatically if processing of the action was successful. Without automatic acknowledgment, operators must manually acknowledge messages in the Java GUI Browser.
Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News

Subject: Unable to Duplicate Alerts(Logfile) in HPOM by Suresh Reddy

May 27, 2010 Dear Experts,

We have a requirement from server team to monitor a log pattern called "DEAD PATHS DETECTED BY POWER PATH" on all HP-UX nodes. I have created a log template with message matching condition as follows

<*>DEAD PATHS DETECTED BY POWER PATH<*>

Two systems are generating these logs frequently. We are receiving alerts on java console but instead of getting Duplicate a new alert is generating when the same pattern find in the server logs.
Please suggest how can I modify the log file template to make sure the template matching the above condition instead of generating a new alert, existing alert should be duplicated in Java console.

Note : I have tried by giving the suppress time interval in advanced options in template.

Thanks & Regards,
Suresh Reddy.

Sumit Kumar

May 27, 2010

Hi Suresh,

Open your Motif GUI and go to Actions-->Server-->Configure and check mark the Suppress and Count Duplicate Messages.

Suresh Reddy

May 28, 2010

Dear Sumit,

Thanks for your replay. Suppress and Count Duplicate Messages is already enabled. Please find the attachment for the same.


Thanks & Regards,
Suresh Redddy.

lauri

May 28, 2010 11:16:50 GMT

There is probably differences in full error line every time (like date/time etc). You HAVE TO create message key for those messages. In that case duplication is done based on message keys and not on full patterns.

Goran Koruga

May 28, 2010

Hello.

Indeed - your pattern is very generic, and comparision is not done using patterns but string comparision for standard message fields (severity, text, application ...) or messages keys created automatically from those (but note that in case field contents change, so will message keys).

Use message keys like already suggested.

Regards,
Goran

Suresh Reddy

Thanks a lot for your replies.

Please find the attached the file contains the alerts and the server logs. Please suggest how can I create a message key for a log file template.

My message group is OS and Application is HP OSSPI.

Shane Mann

May 31, 2010

You could use a message key like this:

<$MSG_NODE_NAME>:<$LOGFILE>:<DEAD PATHS DETECTED BY POWER PATH>

So any occurrence of that string from the same node, and same logfile will duplicate match.

Cheers,
Shane

Shane Mann

May 31, 2010

Sorry - to apply the message key - Edit the template, edit the condition which you've already added and put those values in the message key field.

Cheers,
Shane

Suresh Reddy

May 31, 2010 11:42:22 GMT

Perfect It is worked...

But I have one logfile template with 21 conditions in that this DEAD PATH is the one of the conditions.

Please let me know If I will give this as a messagecorelation :
<$MSG_NODE_NAME>:<$LOGFILE>
will it work without log file pattern
OR wtih the below condition
<$MSG_NODE_NAME> lauri

May 31, 2010

Could you please explain a bit closer, what you mean? Seems like your duplication is working already, what are you trying to correlate there?

Shane Mann

May 31, 2010

You need to make the message key 'unique' enough not to duplicate messages that are not related. If you just use: <$MSG_NODE_NAME> - then *any* message that is generated with just the node name as the message key will be treated as a duplicate.

By putting the node name and the logfile, you narrow it down to messages from the same source eg: same server, same logfile. Then a string to match an equivalent line in that logfile.

You can make it much broader, if you leave the node name out - eg: <$LOGFILE>:<DEAD PATHS DETECTED BY POWER PATH> It will duplicate all messages from that logfile, with that text, regardless of which server they came from. Does that make sense?

Probably the better way to do it is to setup your message output text so that it has no unique date/time in it. Then suppress duplicate output messages (if you don't care about the number of duplicates). You are matching using:
<*>DEAD PATHS DETECTED BY POWER PATH<*>

Put this in your output text field:
syslog: DEAD PATHS DETECTED BY POWERPATH

And you'll find the server duplicate matching will work, even without a message key.

Either way - for your 21 conditions, you need to set a 'unique' message key, or set the output text to be consistent for each condition (no date time stamps).

Cheers,
Shane



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019