IT Operations Management (ITOM)
Showing results for 
Search instead for 
Do you mean 

Evolve to OMi: Implementing instruction text lookup and addressing other policy import “warnings”

VolkerGaertner on ‎12-17-2015 06:22 AM

In a previous post, I explained how to import policies from Hewlett Packard Enterprise Operations Manager (HPEOM) for Windows, HP-UX, Solaris or Linux into HPE Operations Manager i (OMi).

Today, I want to have a closer look at the –check option of the policy import, as the number of warnings it sometimes produces has confused some people.

I will explain what types of warnings the tool creates and how to address each warning type.

 To cut a long story short, a warning does not always mean that you can’t import or use the policy or that you have to edit it!

 Furthermore, quite often warnings in hundreds of policies can be addressed by a mass “search and replace” or by a single configuration step on the OMi server.

So hundreds of warnings don’t mean that you have to edit hundreds of policies!

Therefore if the check reports a low percentage of policies without warnings, don’t worry!

 The –check option

The Operations Bridge Evolution Guide recommends checking the downloaded HPE Operations Manager (HPEOM) policies for incompatibilities before doing an upload, so that you are able to address warnings by using a mass search and replace in all the downloaded policy files. This is much faster than changing each policy in OMi after an upload.

The check is done using the ConfigExchange –check option. The results are written into a policy report log file.

The policy report

The first thing you will see in the report is how many policies have no problem at all.

As I said, don’t be put off by a low percentage here.

Policy Parser Report
====================
Policies without problems: 17 of 108 (15.74%)

It is followed by a description of possible problems and solution hints:

Explanations for the problem summary:
Error   = policy will not work
Warning = parts of the policy may not work
Possible problem categories + solution hints: 

I don’t repeat the hints here as I will explain them in the following in more detail.

Then you get a summary of potential problems, like this:

ECS:
In # of policies:     Error   0

PATTERN:              Warning 823
ACTIONS:
ACTION_SERVER_VAR:     Warning 3
ACTION_SERVER_EXE:     Warning 0
VAR_IN_ACTION:         Warning 0
ENCRYPTED_PASSWORD:    Warning 0

MSI:
In # of conditions:   Warning 0

INSTRUCTION_TEXT_INTERFACE:
In # of conditions:   Warning 823

INSTRUCTION_TEXT:
In # of conditions:   Warning 0

How to address warnings

Let me start with the two warnings that occurred the most in my example:

Pattern Warnings

There are slight differences between the supported patterns in OMi and HPEOM.

1. OMi does not yet support a case-insensitive check when closing messages using message keys.

Although the case-sensitive check is the default in HPEOM, HPEOM allows a case-insensitive check as well. Many SPIs use case-insensitive checks per default, so if you followed that practice of always using case-insensitive checks, then you might see a lot of those policy warnings.

However, in most cases the check will just work as before, even if checked case-sensitive, as typically the same variables are used for the message key and the message key relation pattern.

For example, if the pattern closes all messages using the pattern

<$NAME>:<$MSG_NODE_NAME>:<$MSG_OBJECT>:<*>

Then the message key is usually constructed using the same variables: <$NAME>:<$MSG_NODE_NAME>:<$MSG_OBJECT>:<some other variable or identifier>

That means whatever case was used in the key is probably used in the pattern as well, therefore a case-sensitive check works just as well as a case-insensitive check.

Therefore I recommend that you import the policies as they are, but keep this in mind in case you find events that should have closed old events.

For example this could happen if the node names appear in the same log file in variations, sometimes in upper-case letters, sometimes in lower-case letters. In this case, the message that used the upper-case node name in its message key cannot be closed by a message that uses the lower-case node name in the message key relation pattern (or vice versa). In such a case, consider using an EPI script that converts either the key or pattern to lower case, for example using

def process(List<Event> events)
{
   try
   {
     // Example: convert key to lower case
     events.each {
       event -> event.setKey(event.getKey().toLowerCase())
       }
   }... 

 

To avoid that this change messes up the keys of other events, make sure to use a specific event filter so that this script is only called when necessary.
Note: Do not remove the ICASE keyword from the downloaded policy files as OMi might add support for this in a future release.

2. OMi does not support the whitespace pattern <S> (which was deprecated a long time ago in HPE OM)

To fix it replace <S> by <_>, <1S> by <1_>, <2S> by <2_> ... in all downloaded policy files.

Note: The Evolution Guide recommends downloading and importing policies in chunks to avoid duplication and to make sure that only those policies are imported that are actually in use. It is not recommended to download all policies from HPOM!
Therefore you might need to do search and replace operations multiple times, replacing the same patterns again and again. So it might make sense to write a little script, for example in perl, for repeating replacements.
Otherwise I recommend using tools like notepad++ or standard Linux tools like sed and awk to search & replace text strings in multiple files in a directory structure.

3.  OMi does not support integer-range patterns (like <25 -lt <#> -lt 30>) when closing related events

You can replace such a pattern by fixing values separated by |.
For example: <25 -lt <#> -lt 30> can be replaced by [26|27|28|29]

Instruction Text Interface Warnings

This warning only occurs when importing policies from HPEOM for HP-UX, Solaris or Linux and if the instruction text interface was used. It tells you that a policy uses that instruction text interface, and that you need to setup a corresponding instruction text lookup script on the OMi server in case you want to keep using this instruction text interface.

So there is no need to edit the policy if you get this warning.

The only configuration that needs to be done is to setup a corresponding External instruction lookup script in OMi.

Let me give you an example: You might have an Apache Knowledge Base lookup script configured like this in HPEOM:

Inside a HPEOM policy this instruction text interface is then called using an event parameter <ErrorCode> like this:

In a similar way you might have a lookup script for a Microsoft Knowledge Base.

To implement the same in OMi, a corresponding External Instructions lookup script has to be configured, see Administration Guide > Operations Console > External Instructions and Extensibility Guide > Groovy Scripts > Development and Deployment of Scripts > External Instruction Retrieval Scripts for all the details.

In our example the event filter used in such a lookup script should match those events where the instruction interface name (set by the policy) is either Apache KB or Microsoft KB:

The script itself would then include code like this:

// this method returns the instruction text
  def getInstruction(Event event)
  {
    // lookup for Apache KB
    if ("Apache KB".equalsIgnoreCase(event.instructionInterfaceName))
    {
      // check OS type of the GW where this script is running
      def command = ""
      if (System.properties['os.name'].toLowerCase().contains('windows'))
        command = "apachekb.bat " + event.instructionParameterString
      else
        command = "apachekb.sh " + event.instructionParameterString
      def proc = command.execute() // execute command line
      proc.waitForOrKill(3000)     // wait for 3sec before time-out

      if (proc.exitValue() == 0)
        return proc.in.text
      else
        if (proc.err.text) // if the command returns the error text in stderr
          return "instruction retrieval for parameter '" 
+ event.instructionParameterString + "' failed. Error: " 
+ proc.err.text
        else
          return " instruction retrieval for parameter '" 
+ event.instructionParameterString + "' failed. Error: " 
+ proc.in.text
    }
    // lookup code for Microsoft KB
    …

Instead of calling an external command you could of course also query the knowledge base inside the groovy script – groovy offers various modules to query databases, web pages etc.

Note: The policy check is unable to check if a corresponding script has already been setup on the OMi server or not. It will always print a warning if the instruction text interface is used.

MSI warnings

As for the instruction interface warnings above, these warnings do not mean that you have to edit your policies or that you can’t use them.

They just indicate that the Server MSI is referenced in the policy (you don’t get any warning if the Agent MSI is referenced, as this still can be used). On the server side, there is a difference in how OMi implements event enrichment and automation compared to HPEOM.

Instead of Server MSI, OMi offers:

  • Server-Side Stream-Based Event Correlation (SBEC)
  • Topology-Based Event Correlation (TBEC)
  • Event suppression
  • Event web service interface
  • Event Processing Interface (EPI)

So depending on the use case of the MSI call, use one of these techniques. If the MSI application is used to suppress events, use event suppression rules instead. If an MSI application is taking a feed for external purposes, then consider implementing it in OMi using the Event Web Service interface or forward events to external event processing using a forwarding rule.

If the MSI application is used to process multiple events then SBEC could be a suitable replacement.

In any case, you don’t have to edit the policies that refer to the old MSI interface. Server-side MSI keywords inside the policy are ignored by OMi – there is no need to remove them.

ECS errors

Instead of ECS and Composer, OMi offers server-side Stream-Based Event Correlation (SBEC), Topology-Based Event Correlation (TBEC), and the Event Processing Interface (EPI). Therefore ECS policies cannot be imported. They are simply ignored.

Please see the Evolution Guide for more details about how to use the SBEC, TBEC and EPI scripts to replace different types of ECS policies.

Encrypted password in action warning

HPEOM allows defining actions that are executed under a specific user and allows to store the user password in an encrypted form inside the policy. However, on an OMi system the recommendation is not to store the password inside the policy—because this would require a policy change each time the password is changed.

Instead, use the parameterization capabilities of OMi, which didn’t exist on HPEOM. Introduce a password parameter to the policy and store the actual value of the password in a management template or aspect or you can also specify it during the assignment. This parameterization allows you to change the password afterwards, without editing or deploying the policy again. Management templates for different groups of CIs allow different passwords without having to maintain multiple copies of policies.

See the OMi tutorial “How to add a parameter to a policy template” for details.

Other Action and Instruction Text warnings

If we look at all the remaining warnings that might occur, then they have one thing in common: They refer to executables or variables that only exist on an HPEOM system.

So of course you get a warning when you try to import those policies on an OMi system.

The first question you should ask yourself is: What is the use case for these policies?

What is it that the action triggers? Is that still a valid or necessary use case on an OMi system? Or would you use another technology instead?

For example, some customers use actions in HPEOM policies to automatically add nodes to a certain node group in HPEOM, as the node group membership defines which operator will see the event. For this the action calls the opc_node CLI on the HPEOM server. In OMi however, permissions are typically not assigned based on node group membership, therefore the specific use case for this action does not apply any more.

Similarly, other automation use cases that made perfect sense on an HPEOM system, might - in the best case - not be required any more or might be better addressed using other technologies like discovery, downtime management or enrichment rules.

Without knowing the use case it’s impossible to give a general statement on which technology should be used instead, but my assumption is that there are only very few use cases which will still need to be addressed by policy-based actions that run on the OMi server.

So in these cases, you will have to edit those few policies and replace the executables and variables used on an HPEOM server by corresponding executables and variables that exist on an OMi server.

Note: The Evolution Guide provides some tips how to replace the $OPC_MGMTSV variable. See OMi Solutions for $OPC_MGMTSV Actions in the Evolution Guide.

Summary

Simply put, in my example, out of the 1649 individual warnings,

  • 823 warnings were addressed by implementing the instruction text lookup script,
  • 823 warnings were addressed by doing nothing ;) – well, ok, I quickly looked at the used patterns and because they are all based on policy variables it’s unlikely that the case sensitive check will create problems, so I ignored the warning. The remaining
  • 3 warnings turned out to be calls that are no longer necessary on OMi because the use case no longer applied.

I hope that this information helps you to understand why there might be so many warnings, but as you have seen, this does not mean that there is huge effort necessary to address those warnings.

My advice is to stay calm, and walk through the steps above to solve the warnings. Don’t panic if there are a lot of them.

For more information about the evolution of HPE Operations Manager to Operations Manager i please see the Operations Bridge Evolution page.

See our web page for other details www.hpe.com/software/opsbridge and join our advocacy hub https://opsbridgeinsiders.influitive.com/.

Other BSM blogs with many other details of HPE Operations bridge solutions can be found here: http://community.hpe.com/t5/Business-Service-Management/bg-p/sws-571.

About the Author

VolkerGaertner

Comments
Raymond Meijer
on ‎01-12-2016 04:32 AM

 Very useful post; I will definitely need this in the future.

Sujesh
on ‎01-12-2016 11:02 AM

I like it

kyriakos2
on ‎01-14-2016 12:27 AM

Seems complex

wboy
on ‎01-14-2016 10:53 AM

I am missing tool where it would suggest how to fix the issue

wboy
on ‎02-08-2016 03:49 AM

Nice article! Hoping to see more tricks/tips with migration

Events
June 6 - 8, 2017
Las Vegas, Nevada
Discover 2017 Las Vegas
Join us for HPE Discover 2017 in Las Vegas. The event will be held at the Venetian | Palazzo from June 6-8, 2017.
Read more
Apr 18, 2017
Houston, TX
HPE Tech Days - 2017
Follow a group of tech bloggers for a new HPE Tech Day, a full day of sessions about how to create a hybrid IT, from hyperconverged to Composable Infr...
Read more
View all
//Add this to "OnDomLoad" event