使用 SNMP 通过 Nagios 对 Dell R820 服务器进行硬件检查

Question 1

也许我很奇怪，但我更喜欢通过 vCenter SNMP 接口监控 vSphere 集群中的 ESXi 主机（与某些事件的电子邮件相结合）。这满足了我的大部分需求。因此，它是针对事件发出警报，而不是通过 Nagios 之类的工具轮询硬件。

您能否澄清一下您最感兴趣的主机级别监控具体项目是什么？

我认为 vSphere 的陷阱和电子邮件警报可以像您希望的那样细化……

在此处输入图片描述

Answer

也许我很奇怪，但我更喜欢通过 vCenter SNMP 接口监控 vSphere 集群中的 ESXi 主机（与某些事件的电子邮件相结合）。这满足了我的大部分需求。因此，它是针对事件发出警报，而不是通过 Nagios 之类的工具轮询硬件。

您能否澄清一下您最感兴趣的主机级别监控具体项目是什么？

我认为 vSphere 的陷阱和电子邮件警报可以像您希望的那样细化……

在此处输入图片描述

Question 2

不行。VMware 选择使用 CIM 路由而不是 SNMP，因此您无法执行您所要求的操作。他们实现的唯一 SNMP 支持是陷阱发送，上次我尝试时（诚然是几年前）发现它存在很多错误。

这里已经讨论了两个不错的选择（检查ESXI硬件, OP5的检查 esx 插件）。

你可能已经知道，Nagios Exchange 上有很多其他人尝试解决此问题的方法，但其中大多数已经过时并且无法与现代 VMware 产品兼容。

关于具有 root 权限的问题，python 插件曾经工作没有 CIM 树根级以上的 root 访问权限（例如，不会继承到 VM 本身），但从 5.1 开始似乎不再如此。不过，您可能可以创建一个供 Nagios 使用的特殊角色（不是管理员角色）。

根据您上面的评论（关于想要更详细的硬件状态监控），在这种情况下，通过服务处理器（BMC、LOM、iLO，无论您想怎么称呼它）进行一些 IPMI 检查可能会更好。

如果您专门处理戴尔硬件，您可以添加戴尔特定的离线软件包 (VIB)在 ESXi 中启用 OpenManage 支持。

将来，你也许可以使用优秀的检查打开管理插件，但目前还不可能。

Answer

不行。VMware 选择使用 CIM 路由而不是 SNMP，因此您无法执行您所要求的操作。他们实现的唯一 SNMP 支持是陷阱发送，上次我尝试时（诚然是几年前）发现它存在很多错误。

这里已经讨论了两个不错的选择（检查ESXI硬件, OP5的检查 esx 插件）。

你可能已经知道，Nagios Exchange 上有很多其他人尝试解决此问题的方法，但其中大多数已经过时并且无法与现代 VMware 产品兼容。

关于具有 root 权限的问题，python 插件曾经工作没有 CIM 树根级以上的 root 访问权限（例如，不会继承到 VM 本身），但从 5.1 开始似乎不再如此。不过，您可能可以创建一个供 Nagios 使用的特殊角色（不是管理员角色）。

根据您上面的评论（关于想要更详细的硬件状态监控），在这种情况下，通过服务处理器（BMC、LOM、iLO，无论您想怎么称呼它）进行一些 IPMI 检查可能会更好。

如果您专门处理戴尔硬件，您可以添加戴尔特定的离线软件包 (VIB)在 ESXi 中启用 OpenManage 支持。

将来，你也许可以使用优秀的检查打开管理插件，但目前还不可能。

Question 3

我们使用 op5 的 check_esx 插件（http://www.op5.org/community/plugin-inventory/op5-projects/check-esx-plugin) 正是为此目的。您需要安装 vmware perl sdk。

我们这样使用它：

check_esx -H $HOSTADDRESS$ -u root -p passwd -l runtime -s health
CHECK_ESX.PL OK - All 449 health checks are Green | Alerts=0;;

check_esx 插件可以监控很多东西，op5 的小伙子们做得很好。

Answer

我们使用 op5 的 check_esx 插件（http://www.op5.org/community/plugin-inventory/op5-projects/check-esx-plugin) 正是为此目的。您需要安装 vmware perl sdk。

我们这样使用它：

check_esx -H $HOSTADDRESS$ -u root -p passwd -l runtime -s health
CHECK_ESX.PL OK - All 449 health checks are Green | Alerts=0;;

check_esx 插件可以监控很多东西，op5 的小伙子们做得很好。

Question 4

问题在于检查ESXI硬件并且只读或非管理员角色用户（非 root）是由于 PAM 功能或 ESXi 5.1 及更高版本中的错误，具体取决于您的观点。

任何创建并分配给管理员角色以外的任何角色的用户在 /etc/security/access.conf 中均被设置为全部拒绝。即使您克隆管理员角色并将您创建的用户分配给此克隆角色，它也会在 /etc/security/access.conf 中被设置为全部拒绝。

我在本地（不是通过 vCenter）在 ESXi 5.5 主机上创建了一个用户“nagios”，并将其分配给权限选项卡下的“只读角色”。默认情况下，其在 access.conf 中的权限为“-:nagios:ALL”

如果我通过 ssh 连接到 ESXi 主机并编辑 /etc/security/access.conf 并将 nagios 用户权限更改为“+:nagios:sfcb”或“+:nagios:ALL”，则 check_esxi_hardware 可以工作。

使用“+:nagios:sfcb”限制用户“nagios”只能访问 CIM 服务。

您现在遇到的问题是 /etc/security/access.conf 的更改在重启后无法持久保留。

这是 VMware 社区中讨论此问题的一个主题： https://communities.vmware.com/thread/464552?start=15&tstart=0

这是一篇非常好的文章，讨论了使用 wbem 的相同问题： https://alpacapowered.wordpress.com/2013/09/27/configuring-and-securing-local-esxi-users-for-hardware-monitoring-via-wbem/

以下两篇博客讨论了如何在 ESXi 中重新启动后使更改持久化：

www.therefinedgeek.com.au/index.php/2012/02/01/enabling-ssh-access-in-esxi-5-0-for-non-root-users/

www.virtuallyghetto.com/2011/08/how-to-persist-configuration-changes-in.html

我无法将最后两个链接设为超链接，因为这是我第一次向 serverfault 发帖，并且除非您拥有 10 个声誉点，否则您只能在答案中放两个链接（这是公平的）。

我还没有决定使用哪种解决方案来确保重启后此设置仍然存在。我仍在测试。

谢谢

Answer