以HPE MSA 2040/2050为例在Zabbix 4.0中使用从属项

引言

每个使用Zabbix监视系统并监视其发展的人都知道，随着Zabbix 3.4的发布，我们有了一个很棒的功能-Dependent Items（依赖数据项），关于Zabbix的博客文章已经与此相关 。 但是，以3.4版中引入的形式，由于不支持在预处理规则（ ZBXNEXT-4109 ）和“父级”中使用LLD宏，因此“最大程度地”使用它是有问题的。只能从数据项中选择由LLD规则本身创建的一个（ ZBXNEXT-4200 ）。 简而言之，我必须完全按照上面的链接中所述进行所有操作-用手操作，这会带来大量不便，因此会产生大量不便。 但是，随着Zabbix 4.0alpha9的发布，一切都发生了变化。

一点历史

对我来说，所描述的功能非常重要，因为我们公司使用了HP的多个存储系统，即HP MSA 2040/2050，使用Python脚本对其XML API的请求会删除其度量标准。



最初，当任务是监视指定的设备并使用API​​找到一个选项时，事实证明，在最简单的情况下，为了找出存储系统一个组件的运行状况，有必要进行两个查询：

• 请求认证令牌（会话密钥）；
• 请求本身，返回有关组件的信息。

现在，假设存储由24个磁盘（或更多），两个电源，一对控制器，风扇，几个磁盘池等组成-我们将所有这些乘以2并得到50个以上的数据元素，这等于对每分钟检查一次API。 如果您尝试以这种方式运行，那么API会迅速“放下”，毕竟我们只在谈论要求组件的“运行状况”，而没有考虑其他可能且有趣的指标-温度，硬盘驱动器的运行时间，风扇速度等。

即使在Zabbix 3.4版发布之前，我做出的卸载API的第一个决定就是为接收到的令牌创建一个缓存，该令牌的值被写入文件并存储N分钟。 这样可以将对API的调用次数减少两次，但是情况并没有太大变化-很难获得健康状态以外的其他信息。 大约在这段时间里，我参观了由Badoo主办的Zabbix Moscow Meetup 2017，在那里我了解了上述依赖数据项的功能。

对该脚本进行了修改，使其能够提供详细的JSON对象，其中包含我们在存储库的各个组件上感兴趣的信息，并且其输出开始看起来像这样，而不是单个字符串或数字值：

{"1.1":{"health":"OK","health-num":"0","error":"0","temperature":"24","power-on-hours":"27267"},"1.2":{"health":"OK","health-num":"0","error":"0","temperature":"23","power-on-hours":"27266"},"1.3":{"health":"OK","health-num":"0","error":"0","temperature":"24","power-on-hours":"27336"}, ... } 

这是给定数据在所有存储磁盘上的示例。 对于其他组件，图片是相似的-键是组件ID，值是包含必要指标的JSON对象。

一切都很好，但是本文开头描述的细微差别很快浮出水面-所有相关指标都必须手动创建和更新，这非常痛苦（每个存储系统约300个指标以及触发器和图形）。 LLD可以拯救我们，但是在这里，在创建原型时，它不允许我们将规则本身未创建的项目指定为父项目，并通过LLD创建虚拟项目并将其项目ID替换为您需要的项目，从而摆脱了肮脏的局面。 Zabbix服务器。 提到的功能请求很快出现在Zabbix错误跟踪器中，这表明此功能不仅对我很重要。

因为 我这方面的所有准备工作都已完成，我决定容忍而不是产生诸如动态模板生成之类的临时解决方案，只等到本文开头指出的ZBXNEXT关闭后才完成。

现在看起来如何

为了演示Zabbix的新功能，我们采取以下措施：

• HPE MSA 2040存储可通过HTTP / HTTPS获得;
• 从CentOS 7.5.1804上的官方存储库安装的Zabbix 4.0alpha9服务器；
• 该脚本使用第三版的Python编写，使我们能够检测存储组件（LLD）并以JSON格式返回数据，以便使用JSON Path在服务器端Zabbix上进行解析。

父数据元素将是“外部检查”，它使用必要的参数调用脚本并将接收到的数据存储为文本。

准备工作

Python脚本是根据文档安装的，并具有Python依赖项中的“ requests”库。 如果您具有基于RHEL的发行版，则可以使用yum软件包管理器进行安装：

 [root@zabbix]# yum install python3-requests 

或使用点子：

 [root@zabbix]# pip install requests 

您可以通过请求例如来自磁盘的LLD数据来从外壳测试脚本：

 [root@zabbix]# ./zbx-hpmsa.py -m MSA_DNS_NAME_OR_IP -d -c disks {"data":[{"{#DISK.ID}":"1.1","{#DISK.SN}":"KFGY7LVF"},{"{#DISK.ID}":"1.2","{#DISK.SN}":"Z0K02QVG0000C4297CH3"},{"{#DISK.ID}":"1.3","{#DISK.SN}":"KLK7XG0F"}, ... } 

主机设定

首先，您需要创建父数据元素，其中将包含我们需要的所有指标。 例如，为物理磁盘创建这样的元素：



名称 -任意指定；
类型 -外部验证；
关键是使用必要的参数调用脚本（请参阅GitHub上的脚本文档 ）；
信息类型 -文字；
更新间隔 -该示例使用自定义宏{$ UPDATE}扩展为值“ 1m”；
历史记录存储期为一天。 我认为存储父数据元素不再有意义。
检查所创建元素的最新数据：



JSON出现了，那么一切都正确完成了。

接下来将设置发现规则，该规则将找到可用于监视的所有组件，并创建相关项和触发器。 继续使用物理磁盘的示例，它将如下所示：



创建LLD规则后，您将需要对数据项进行原型设计。 让我们以温度数据为例创建这样一个原型：



名称 -任意指定；
类型是依赖的。 作为父数据元素，选择相应的先前创建的元素；
键 -我们将发挥想象力，但是我们必须考虑到每个键必须唯一，因此我们将在其中包含LLD宏；
信息类型 -在这种情况下为数字；
历史记录存储时间 -在示例中，这是一个自定义宏，由您自行决定；
趋势存储周期还是一个自定义宏。

我还添加了“应用程序”的原型-您可以方便地将与一个组件相关的指标绑定到该应用程序。

在“预处理”选项卡上，使用检索温度读数的规则创建“ JSON路径”类型的步骤：



步骤表达式如下所示： $['{#DISK.ID}']['temperature']

请注意，现在您可以在表达式中使用LLD宏，这不仅大大简化了我们的工作，而且使执行此类操作变得非常容易（您之前已经被发送到Zabbix API）。

接下来，通过模拟温度，创建数据元素的其余原型：



在此阶段，您可以通过转到主机上的“最近的数据”来检查结果。 如果一切适合您，我们将继续努力。 我得到了以下图片：



我们正在等待配置缓存更新或手动推送更新：

 [root@zabbix]# zabbix_server -R config_cache_reload 

之后，您可以使用版本4.0的另一个“技巧”-“立即检查”按钮来运行创建的LLD规则：



我得到以下结果：

结论

结果，仅对XML API的九个请求，我们就可以从一个网络节点上获得三百多个指标，从而花费最少的时间并获得最大的灵活性。 LLD将使我们能够自动检测新组件或更新旧组件。

感谢您的阅读，下面提供了所用材料的链接以及HPE MSA P2000G3 / 2040/2050的当前模板的链接。

PS顺便说一句，在4.0版本中还引入了一种新型的检查-HTTP代理，再加上预处理和XML Path，可以潜在地使我们免于使用外部脚本-您只需要解决获取身份验证令牌的问题，仍然需要定期更新身份验证令牌。 我看到的选项之一是使用带有此令牌的全局宏，可以通过Zabbix API通过Crown incl将其更新。 有兴趣的人可以发展这个想法。 =）

剧本
Zabbix共享模板
相关数据项
杰森路径
Zabbix 4.0alpha9