Migrating from HP OpenView Operations to Zabbix

Migration from HP OpenView to Zabbix might look challenging but is worth it due to a long list of benefits. Let’s discuss what HP OpenView is, learn some of its history, its main features, and the reason for migration, as well as discover the real migration use case showing the process in detail.

Quadrata is a premium partner of Zabbix, that provides a wide range of IT-related services in Italy. During Zabbix Summit 2019 the company introduced their experience of migrating from HP OVO to Zabbix based on reliable and cost-effective solutions.

Watch the video now.

Contents

1. History of HP OpenView (01:54)
2. Main features of HP OpenView (04:05)
3. Our experience (07:18)
4. Conclusion (20:06)

History of HP OpenView

HP OpenView is a former name of a Hewlett-Packard product family for network and system monitoring and management.

It might not be well-known today, but it has been on the market since the 1980s. At that time it used only the SNMP interface, and its original name was Network Node Manager. Later HP put some new components inside such as the discovery engine and the operations center. The operations center provided server and application management as well as communication via RPC instead of SNMP. The discovery engine was later sold to IBM for Tivoli.

Around 1995 the Network Node Manager and the operations center were combined to be known as OVO, which is short for OpenView Operations.

Then HP started buying other companies and from 2004 to 2007 it bought Novadigm with its Radia suite, Peregrine Systems with its IT asset and service management software, Mercury Interactive Corp., and Opsware. The integration of all the products led to the name change, so HP OVO was rebranded to HP BTO (Business Technology Optimization). However, some customers still prefer the old name.

In 2017 HP (now HPE) separated its software division and sold it to Microfocus, so now HP OpenView is managed and supported by Microfocus.

Main features of HP OpenView

HP OpenView is a server-client framework similar to Zabbix, but different at the same time.

The HP OpenView agent mainly acts as a scheduler for custom scripts distributed on each node with a related configuration file. A user has to provide their own scripts to monitor CPU usage, etc., and then send the data to the engine using the OPCmon command. The engine receives an alert, not the actual data, and then manages it. Moreover, it supports automatic and manual specific actions, as well as manages the centralized configuration too.

HP OpenView is a framework composed of many modules including the modules that take the data from the server. But at least in our experience, the fact that no actual data is sent, but rather alerts means that many customers use HP OpenView only as an alerting system and not for monitoring purposes, like Zabbix.

HP OpenView vs Zabbix

The HP OpenView and Zabbix terminology is quite similar, but there are some differences:

• OVO policy — Zabbix template;
• OVO condition — Zabbix trigger;
• OVO message text — Zabbix trigger name;
• OVO help text — Zabbix URL or description;
• OVO automatic action — automatically handled Zabbix Script in escalation approaches.

Manual action on HP OpenView has no direct comparison.

As you can see from the table, we had 400 policies to migrate (configuration files, log files, measurement threshold, etc.).

Our experience

We can perform migration in two different ways:

1. greenfield;
2. two-step migration.

Greenfield migration involves the development of a new monitoring system in parallel to the old one. It allows us to use all the advanced features of Zabbix compared to HP OpenView.

But the customer couldn’t allow any downtime and asked us to perform migration in two steps:

1. translate every check from HP OpenView to Zabbix without optimization (except when a simple embedded Zabbix script perfectly fits HP OpenView script checks);
2. optimize checks using Zabbix capabilities.

Sometimes we translated checks and sometimes we used the functions already available in Zabbix instead.

OVO to Zabbix translation
I’ll have a couple of examples of how the translation went.

The first example is swap space monitoring. It works as follows:

1. The engine starts an agent-driven script on the client.
2. The client reads the threshold from a local configuration file (if the configuration file does not exist, it will be created);
3. The client evaluates swap usage compared to the thresholds.
4. If a threshold was reached, the central engine will get the message via OPC.

There is an OVO script that you have to build if you want to use HP OpenView. The script is tailored for different operating systems (HP UX, SunOS, Linux).

############################################################
# Check Swap used with Threshold
############################################################
case `uname` in
"HP-UX" )
SWAPUSED=`swapinfo -dft | grep '^total' | awk '{ print $5 }' | sed -e 's/%//'`
;;
"SunOS" )
#SWAPUSED=`swap -s | sed 's/k//g' | awk '{ printf("%.0f\n",100*($9/($9+$11))) }'`
#FIX RM-10/2013: swap -s reports physical memory+swap
SWAPUSED=`swap -l|awk '/[0-9]+/ {avail+=$4;free+=$5} END {print int(100-100*free/avail)}'`
;;
"Linux" )
dFreeOutput=`free -o -m | grep "^Swap:"`
if [ $? -ne 0 ]; then
dFreeOutput=`free -m | grep "^Swap:"`
fi
dUSED=`echo $dFreeOutput | awk '{print $3}'`
dTOTAL=`echo $dFreeOutput | awk '{print $2}'`
if [ $dUSED -gt 0 ]
then
SWAPUSED=`expr $dUSED \* 100 / $dTOTAL`
else
SWAPUSED=0
fi
;;
esac

Here is a comparison inside the script to find if there is a problem. A message will be sent to the central engine only if a threshold is reached. Thresholds are tailored potentially for each server.

MONVAL=0
if [ "${CRITPCT}" != "/" ] && [ ${SWAPUSED} -ge ${CRITPCT} ];then
MONVAL=4; MSGPCT=$CRITPCT
elif [ "${MAJPCT}" != "/" ] && [ ${SWAPUSED} -ge ${MAJPCT} ]; then
MONVAL=3; MSGPCT=$MAJPCT
elif [ "${MINPCT}" != "/" ] && [ ${SWAPUSED} -ge ${MINPCT} ]; then
MONVAL=2; MSGPCT=$MINPCT
elif [ "${WRNPCT}" != "/" ] && [ ${SWAPUSED} -ge ${WRNPCT} ]; then
MONVAL=1; MSGPCT=$WRNPCT
Fi
/opt/OV/bin/opcmon $MONITOR_NAME=$MONVAL -option VALUE="$SWAPUSED" –option THRESHOLD="$MSGPCT"

On Zabbix, agents are used to collect data, but the customer asked us to literally translate the existing OpenView way of life to Zabbix.

This implementation had four different thresholds, and each configuration file could be tailored for each server. Thus the problem was that some thresholds were not actualized and left in the configuration file with an unknown state. That is why we decided to use specialized triggers with thresholds resolved by macros at template and host levels.

OVO thresholds for swap usage and translation
We had four thresholds:

• warning,
• minor,
• major,
• critical.

Some values were not set in HP OpenView. We translated the thresholds into macros and put zero instead of ‘not set’. Trigger expressions will be more complex to reuse HP OpenView thresholds and especially the ‘not set’ ones. Here is a simplified example for swap check:

OVO triggers

Inside Zabbix and also inside HP OpenView it can lead to some corner cases.

First, what if a value increases and goes from Warning to Major?

Second, what if a value decreases and goes from Critical to Major?

We decided to avoid the automatic solution of problems for case 2 and to leave multiple problems with different severity for case 1.

The second example is log monitoring.

Log monitoring is straightforward because there are no scripts at the agent level. This is a part of the policy that you can see on your screen. As you can see, the policy has a condition — it is Critical. You can also see the match text, which is similar to a regular expression but has a specific syntax. The message text is displayed on the problem dashboard.

In a single policy, there can even be 100 different conditions. I think the best thing is the syntax in the match text which can be parsed for a trigger name because it is much more complicated in Zabbix.

There is one important thing about log parsing on HP OpenView — it is not able to handle complex conditions. The customer decided to analyze logs looking for errors, extract strings, and build an intermediate log file, and this second file was monitored by HP OpenView. Basically, it is correct, but sometimes the system can lose error conditions, and this is a problem for the customer.

Log parsing 
We decided to reuse this mechanism and configured one item and one trigger for each error condition, i.e. for the first trigger.

The translation is very straightforward:
Translation process
There are two things to pay attention to — automatic and manual actions.

It is possible to configure an automatic action on some triggers in Zabbix and in OVO. What is interesting is how the automatic action is defined on HP OpenView, using HOST.NAME and EVENT.ID variables.

The result of the automatic action is also important because the customer often needs to put the result into the problem description. We solved this by writing post-action scripts usually integrated with Zabbix API. For example, if a problem appears, the customer can execute global scripts, and the output of the global scripts goes inside the notes on events. This implies executing automatic actions only on Zabbix.

On many conditions, the operator can run a specific manual action. We cannot translate this into Zabbix because EVENT.ID value is not visible to general scripts. We modified the Zabbix source code obtaining EVENT.ID value for general scripts too, while asking for a general solution.

As an example, look at remedy ticket generation.

The HP OpenView operator can manually open a remedy ticket in case of suitable problems. When the remedy ticket is solved, then the OpenView problem will automatically be followed up and closed too. For manual remedy ticket generation, we followed the general solution using EVENT.ID for extracting remedy needed data and a Perl script to send the Zabbix problem information to remedy, while acquiring the remedy ticket number and return code.

Note. The OpenView operator can open a single remedy ticket associated with multiple error conditions, which is not available in Zabbix.

There is a result of remedy integration. The drop-down menu displays a new action and the problem view.

The last step after opening a remedy ticket is to register the remedy ID (ticket number) in Zabbix event actions message/command.

Conclusion

We learned that the time required to perform the migration is much longer than expected. We planned to spend about 50 days on it, but in fact, we needed 150 days to reach the end of the first phase where we are now.

We also learned that customer involvement is very important, it’s not possible to handle this by yourself.

What we like in HP OpenView is how the actions are defined, and also the way redirecting code of the automatic operation or the manual action is solved.

We also like the simple way to describe the different fields related to the regular expression.

We asked Zabbix to add a way for obtaining event ID inside manually handled global scripts, create a multi-selection in problem view, and provide a solution for the global script output redirected in the event note.

We wanted to share this use case because HP decided to split the software, so at the moment Zabbix is a very good solution to replace HP OpenView. It’s not an easy way but it’s possible because Zabbix has all the features required for this kind of migration.

See also: Presentation slides

About Dimitri Bellini

Zabbix Trainer, Zabbix Certified Professional at Quadrata System Integrator

View all posts by Dimitri Bellini