|May the source be with you, but remember the KISS principle ;-)|
|Contents||Bulletin||Scripting in shell and Perl||Network troubleshooting||History||Humor|
|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
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:
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
See HPOM Patterns
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:
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:
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.
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:
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:
May 27, 2010
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,
May 27, 2010
Open your Motif GUI and go to Actions-->Server-->Configure and check mark the Suppress and Count Duplicate Messages.
May 28, 2010
Thanks for your replay. Suppress and Count Duplicate Messages is already enabled. Please find the attachment for the same.
Thanks & Regards,
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.
May 28, 2010
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.
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.
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.
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.
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 :
will it work without log file pattern
OR wtih the below condition
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?
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).
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 in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
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
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 quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
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
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 DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting 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
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How 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
Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. 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 make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: February 19, 2014