官方博文 | 从HP OpenView到Zabbix

HP OpenView

ZABBIX

作者简介：

Dimitri Bellini

Zabbix培训师，

Zabbix Quadrata系统集成专业认证人员。

从HP OpenView迁移到Zabbix可能看起来很有挑战性，但由于一长串好处，这是值得的。让我们先讨论一下HP OpenView是什么，了解它的一些历史、主要功能和迁移的原因，以及详细阐述迁移过程的实际迁移案例。

Quadrata是Zabbix的优质合作伙伴，在意大利提供广泛的IT相关服务。在2019年Zabbix峰会期间，基于可靠且经济高效的解决方案，公司介绍了他们从HP OVO迁移到Zabbix的经验。

01

HP OpenView 历史

HP OpenView是惠普产品系列的前一个名称，用于网络和系统监控和管理。

它在今天可能并不出名，但从20世纪80年代就开始上市了，当时它只使用SNMP接口，最初的名字是Network Node Manager。后来，惠普在内部安装了一些新组件，如自动发现引擎和操作中心。操作中心提供服务器和应用程序管理，并且通过RPC而不是SNMP进行通信。后来自动发现引擎被出售给IBM用于Tivoli。

大约在1995年，网络节点管理器和操作中心被合并为OVO，这是OpenView Operations的缩写。

然后惠普开始收购其他公司，从2004年到2007年，它收购了Novadigm及其Radia套件、Peregrine Systems及其it资产和服务管理软件、Mercury Interactive Corp.和Opsware。所有产品的集成导致了名称的更改，因此HP OVO更名为HP BTO（业务技术优化）。不过，有些顾客还是喜欢老名称。

2017年，HP（现为HPE）将其软件部门分离，并将其出售给Microfocus，因此，现在HP OpenView由Microfocus管理和支持。

02

HP OpenView的主要功能

HP OpenView是一个类似于Zabbix的服务端和客户端的模式，但又有所不同。

HP OpenView agent 主要充当分布在每个节点上的自定义脚本的调度程序，并提供相关的配置文件。例如用户必须提供自己的脚本来监控CPU使用情况，然后使用OPCmon命令将数据发送到引擎。引擎接收到警报，而不是实际数据，然后对其进行管理。此外，它还支持自动和手动的特定操作，以及管理集中配置。

HP OpenView是一个由许多模块组成的框架，其中包括从服务器获取数据的模块。但至少在我们的经验中，没有实际数据发送，而是发出警报，这意味着许多客户仅将HP OpenView用作警报系统，而不是如同Zabbix用于监控目的。

HP OpenView vs Zabbix

HP OpenView和Zabbix的术语非常相似，但也有一些不同：

• OVO策略-Zabbix模板；
• OVO条件-Zabbix触发器；
• OVO消息文本-Zabbix触发器名称；
• OVO帮助文本-Zabbix URL或说明；
• OVO自动操作-在升级方法中自动处理Zabbix脚本。

HP OpenView上的手动操作没有直接的比较。

从表中可以看到，我们有400个策略要迁移（配置文件、日志文件、度量阈值等）。

03

经验分享

我们可以用两种不同的方式执行迁移：

1. greenfield
2. 两步迁移

Greenfield转换涉及开发一个与旧系统并行的新监测系统。与HP OpenView相比，它允许我们使用Zabbix的所有高级功能。

但客户不允许任何停机，要求我们分两步执行迁移：

1. 将每个检查从HP OpenView转换为Zabbix而无需优化（除非简单的嵌入式Zabbix脚本完全适合HP OpenView脚本检查）；
2. 使用Zabbix功能优化检查。

有时我们转化检查，有时我们使用Zabbix中已有的功能。

OVO 到 Zabbix 的转换

我将举几个转换过程的例子。

第一个例子是交换空间监控。其工作原理如下：

1. 引擎在客户端上启动代理驱动的脚本。
2. 客户端从本地配置文件读取阈值（如果配置文件不存在，则创建该文件）；
3. 客户端根据阈值评估交换使用情况；
4. 如果达到阈值，中央引擎将通过OPC获取消息。

如果要使用HP OpenView，必须构建一个OVO脚本。该脚本是为不同的操作系统（HP UX、SunOS、Linux）量身定制的。

下面是脚本内部的比较，以确定是否存在问题。只有达到阈值时，才会向中央引擎发送消息。阈值可能是为每个服务器定制的。

在Zabbix上，agents被用来收集数据，但是客户要求我们将现有OpenView的方式逐字转换成Zabbix。

这个实现有四个不同的阈值，每个配置文件可以为每个服务器定制。因此，问题是一些阈值没有实现，并留在配置文件中，状态未知。这就是为什么我们决定在模板和主机级别使用由宏解析阈值的专用触发器。

用于交换用法和转换的OVO阈值

我们有四个阈值：

• 警告值
• 较小值
• 较大值
• 关键值

某些值不在HP OpenView中设置。我们将阈值转换为宏，并将0替换为“未设置”。重新使用HP OpenView阈值将使触发器表达式更复杂，尤其是“未设置”的阈值。以下是交换检查的简化示例：

OVO触发器

在Zabbix和HP OpenView内部，它可能会导致一些个别情况。

首先，如果一个值增加，并且从警告值变为较大值怎么办？

第二，如果某个值减少并从关键值变为较大值，会怎么样？

我们决定避免自动解决案例2的问题，并为案例1保留多个严重性不同的问题。

第二个例子是日志监控。

日志监控很简单，因为在agent级别没有脚本。这是您可以在屏幕上看到的策略的一部分。正如你所看到的，策略有一个条件-它是关键值。您还可以看到匹配文本，它类似于常规表达式，但具有特定的语法。消息文本显示在问题仪表板上。

在一个策略中，甚至可以有100个不同的条件。我认为最好的是匹配文本中的语法可以被解析为触发器名称，因为它在Zabbix中要复杂得多。

在HP OpenView上进行日志解析有一件重要的事情——它无法处理复杂的条件。客户决定分析日志以查找错误、提取字符串并构建一个中间日志文件，第二个文件由HP OpenView监控。基本上，这是正确的，但有时系统会丢失错误条件，这对客户来说是个问题。

日志分析

我们决定重用此机制，并为每个错误条件（例如第一个触发器）配置一项和一个触发器。

转换可以非常直接：

转换过程

有两件事要注意-自动和手动操作。

可以在Zabbix和OVO中的某些触发器上配置自动操作。有趣的是如何在HP OpenView上使用HOST.NAME和EVENT.ID变量定义自动操作。

自动操作的结果也很重要，因为客户经常需要将结果放入问题描述中。我们通过编写通常与Zabbix API集成的动作完成后的脚本来解决这个问题。例如，如果出现问题，客户可以执行全局脚本，全局脚本的输出进入事件注释中。这意味着只在Zabbix上执行自动操作。

在许多情况下，操作员可以运行特定的手动操作。我们无法将其转换为Zabbix，因为EVENT.ID的值对常规脚本不可用。我们还修改了Zabbix源代码，以获取通用脚本的EVENT.ID值，同时要求提供通用解决方案。

作为一个例子，看看补救单的生成。

如果出现适当的问题，HP OpenView操作员可以手动打开补救通知单。当补救单被解决时，OpenView问题也将被自动跟上并关闭。对于手动补救单生成，我们遵循通用解决方案，使用EVENT.ID提取补救所需的数据，并使用Perl脚本发送要补救的Zabbix问题信息，同时获取补救单号和返回代码。

注意：OpenView操作符可以打开与多个错误条件相关联的单个补救单，这在Zabbix中不可用。

这是补救整合的结果。下拉菜单显示新操作和问题视图。

打开补救单后的最后一步是在Zabbix事件操作消息/命令中注册补救ID（票证号）。

04

结论

我们了解到执行转换所需的时间比预期的要长得多。我们计划在这上面花50天，但事实上，我们需要150天来完成我们现在的第一阶段。

我们还了解到，客户参与是非常重要的，这是不可能由你自己处理。

在HP OpenView中，我们关注的是如何定义操作，以及如何解决自动操作或手动操作的重新代码。

我们还喜欢用简单的方法来描述与常规表达式相关的不同字段。

我们要求Zabbix添加一种在手动处理的全局脚本中获取事件ID的方法，在problem视图中创建多个选择，并为事件说明中重新定向的全局脚本输出提供解决方案。

我们想分享这个使用案例，因为惠普决定拆分软件，所以目前Zabbix是一个非常好的解决方案，可以取代HP OpenView。这不是一个简单的方法，但这是可能的，因为Zabbix拥有这种转换所需的所有功能。