集群手册/集群监控

集群监控

本章的主题是集群监控，这是一个非常多功能的主题。有大量的软件可用于监控分布式系统。然而，很难找到一个项目能够为所有需求提供解决方案。这些需求中可能包括以高效的方式从高性能集群中收集尽可能多的关于“工作节点”利用率的指标。在这种情况下，效率并非毫无意义的广告词 - 它非常重要。没有人愿意忍受负载不均衡，仅仅是因为收集了一些用于创建图表的数据，高性能计算在这方面的优先级非常明确。另一个必要条件可能是观察某些不能超过特定阈值的事物。这些事物可能是用于冷却 CPU 等设备的冷却水的温度，或者硬盘驱动器上分配的空间。理想情况下，监控软件应该能够在值超过阈值时启动应对措施。在本课程中，将在虚拟机集群上安装两种不同的监控解决方案。首先，测试了广为使用的 Nagios 的分支 Icinga。之后，使用 Ganglia。这两种解决方案都是开源的，并且在它们提供的功能方面有很大的不同。

图 4.1 提供了所用集群（虚拟机）和所用软件的概述。所有节点都使用最新的 Ubuntu LTS^[1] 版本。在 Ganglia 的情况下，软件版本为 3.5，是最新的版本，因此是从源代码编译的。对于 Icinga，使用版本 1.8.4。

Icinga

Icinga^[2] 是一个开源监控解决方案。它是 Nagios 的一个分支，并保持向后兼容性。因此，所有 Nagios 插件也可以与 Icinga 一起使用。Ubuntu 12.04 中官方 Ubuntu 存储库提供的版本是 1.6.1。要获得更当前的版本，将使用个人软件包档案 (PPA) 提供的软件包。^[3]

安装

由于提供了 PPA，安装非常简单。只遇到一个小的麻烦。官方指南 </ref> 建议使用 Ubuntu 的软件包安装 Icinga，如下所示

清单 4.1 建议在 Ubuntu 上安装 Icinga 的软件包顺序。

apt-get install icinga icinga-doc icinga-idoutils postgresql libdbd-pgsql postgresql-client 不幸的是，这失败了，因为 icinga-idoutils 的软件包安装需要一个工作的数据库（PostgreSQL 或 MySQL）。因此，必须更改软件包的顺序，或者只在 Icinga 之前安装 PostgreSQL。

配置

安装 Icinga 后，提供的 Web 界面立即可以访问（使用端口转发访问虚拟机）。默认情况下，一些插件被启用以监控安装了 Icinga 的主机。

图 4.2 显示了主节点上这些插件的服务状态详细信息。让 Icinga 监控远程主机（工作节点）需要更多的配置。查看 Icinga 配置文件夹发现如何配置主节点以显示图 [fig:default_plugins] 中的信息。信息分为两部分：主机识别和服务规范。主机识别包括 host_name、address 和 alias。服务由 host_name、service_description 和 check_command 指定。check_command 接受 Nagios 插件或自定义插件，这些插件必须在另一个 Icinga 配置文件中配置：commands.cfg。

图 4.3 显示了修改后的默认配置文件中用于主节点的一些重要部分。可以看出，主机和服务部分都以 use 语句开头，它代表将要使用的模板。Icinga 附带一个用于主机和服务的默认（通用）模板，这对我们来说已经足够了。

现在出现了一个问题：如何实现图 4.4 中所示的设置。我们希望使用 Icinga 监控我们的工作节点。为此，Icinga 提供了两种不同的方法，它们以相同的方式工作，但使用不同的技术。无论哪种情况，主节点上运行的 Icinga 都定期向工作节点请求数据。另一种方法是，Icinga 只监听数据，工作节点自己启动通信。这两种不同的方法是 SSH^[4] 和 NRPE。^[5] 手册中比较了这两种方法，并推荐使用 NRPE，代价是配置工作量增加。NRPE 导致的 CPU 开销更少，而 SSH 另一方面几乎可以在每台 Linux 机器上使用，因此不需要配置。对于我们的目的，减少 CPU 开销是一个优势，因此使用 NRPE。接下来的部分将介绍如何配置 Icinga 以使用 NRPE 监控远程主机。

主节点

为了使用 NRPE，必须在主节点上安装额外的软件。软件包 nagios-nrpe-plugin 为 Icinga 提供了使用 NRPE 从远程主机收集数据的可能性。不幸的是，该软件包是 Nagios 的一部分，因此在安装时，整个 Nagios 项目应该作为依赖项安装。幸运的是，使用 apt-get 的选项 –no-install-recommends，我们可以跳过这些软件包的安装。现在安装的软件包提供了一个新的 check_command，它可以在为新主机定义服务时使用：check_nrpe。该命令可用于在主机部分指定的远程主机上执行 Nagios 插件或自定义命令。如图 [fig:flo_ahc_icinga_components] 所示，我们希望能够检查“gmond”（下一个监控解决方案 Ganglia 的守护进程），以及两个 NFS 文件夹（/opt 和 /home）是否已正确挂载。为此，我们创建一个新的配置文件 /etc/icinga/objects，在本例中为 worker1.cfg，并将图 [fig:host_service_config] 中所示的主机部分更改为所需工作节点的主机名和 IP。服务部分中的 check_command 必须按以下方式使用

清单 4.2 工作节点配置文件中的 NRPE 检查命令。

check_command check_nrpe_1arg!check-nfs-opt NRPE 命令接受一个参数（因此为 _1arg）：将在主机部分指定的远程主机上执行的命令。在本例中，该命令为 check-nfs-opt，它不是 Nagios 插件软件包的一部分，而是一个自定义 shell 脚本。接下来的部分将描述在 check-nfs-opt 工作之前必须在远程主机上进行的必要配置。

工作节点

工作节点上也必须安装额外的软件。为了能够响应来自主节点的 NRPE 命令，必须安装软件包 nagios-nrpe-server。该软件包提供 Nagios 插件和一个响应来自主节点的 NRPE 请求的服务。我们不会使用 Nagios 插件，而是编写三个基本的 shell 脚本，以确保（如图 [fig:flo_ahc_icinga_components] 所示）

Ganglia 的 gmond 服务正在运行。
\opt 和 \home 都已使用来自主节点的 NFS 正确挂载。

在我们定义这些命令之前，必须允许主节点连接到我们的工作节点

清单 4.3 将主节点的 IP 地址添加到 /etc/nagios/nrpe.cfg。

allowed_hosts=127.0.0.1,!\colorbox{light-gray}{10.0.1.100}! 之后我们可以编辑文件 /etc/nagios/nrpe_local.cfg 并为这三个脚本添加别名和路径。这些命令将在指定别名下对主节点可用。

清单 4.4 向 /etc/nagios/nrpe_local.cfg 添加自定义命令

command[check-gmond-worker]=/opt/check-gmond.sh command[check-nfs-home]=/opt/check-nfs-home.sh command[check-nfs-opt]=/opt/check-nfs-opt.sh 这是在工作节点上需要做的所有事情。可以使用主节点上的一个简单命令来检查是否已正确设置，如清单 [lst:nrpe_check] 所示。

清单 4.5 使用 check_nrpe 检查 NRPE 是否已正确设置。

ehmke@master:/etc/icinga/objects$ /usr/lib/nagios/plugins/check_nrpe -H 10.0.1.2 CHECK_NRPE: Error - Could not complete SSL handshake. 不幸的是，在我们的例子中，需要一些额外的步骤，因为上述命令从每个工作节点返回错误。在工作节点上开启（并再次关闭）调试模式后（/etc/nagios/nrpe.cfg 中的 debug=1），该命令返回 NRPE 版本，并且一切按预期工作。这是一种奇怪的行为，尤其是在必须对每个工作节点执行时。

清单 4.6 check_nrpe 成功！。

ehmke@master:/etc/icinga/objects$ /usr/lib/nagios/plugins/check_nrpe -H 10.0.1.2 NRPE v2.12

用法

图 4.5 显示了所有主机的服务状态详细信息。我们的自定义命令都按预期工作。如果情况并非如此，它们将显示为 ido2db 进程。该服务的状况至关重要，这一点一目了然。Icinga 插件 API^[6] 允许 4 种不同的返回状态。

OK
WARNING
CRITICAL
UNKNOWN

除了返回代码之外，还可以返回一些文本输出。在我们的例子中，我们只返回“一切正常！”。检查 ido2db 进程的插件使用该文本输出为关键服务状态提供一个原因，这是相当直观的。

Ganglia

Ganglia 是一个开源的分布式监控系统，专门为高性能计算而设计。它依赖于 RRDTool 进行数据存储和可视化，并且在所有主要发行版中都可用。最新版本添加了一些有趣的功能，因此我们没有使用官方 Ubuntu 存储库提供的旧版本。

安装

Ganglia 的安装非常简单。我们下载了 Ganglia^[7] 和 RRDTool^[8] 的最新软件包，RRDTool 用于生成漂亮的图表。RRDTool 本身也需要安装 libconfuse。在编译（没有设置特殊的配置标志）和安装之后，我们必须将 RRDTool 集成到环境中，以便 Ganglia 可以使用它。这通常意味着调整环境变量 PATH 和 LD_LIBRARY_PATH。出于个人喜好，我们选择了另一种解决方案，如清单 [lst:rrd_env] 所示。

清单 4.7 将 RRDTool 集成到环境中。

echo '/opt/rrdtool-1.4.7/lib' >> /etc/ld.so.conf.d/rrdtool.conf ldconfig ln -s /opt/rrdtool-1.4.7/bin/rrdtool /usr/bin/rrdtool Ganglia 还需要 libconfuse 和 libapr。两者也必须安装在工作节点上。在配置期间，指定 –with-gmetad 很重要。

清单 4.8 安装 Ganglia。

./configure --with-librrd=/opt/rrdtool-1.4.7 --with-gmetad --prefix=/opt/ganglia-3.5.0 make sudo make install

配置

Ganglia 由两个主要组件组成：gmond 和 gmetad。Gmond 是一个监控守护进程，它必须在每个要监控的节点上运行。Gmetad 是一个守护进程，它轮询其他 gmond 守护进程并将它们的数据存储在 rrd 数据库中，然后这些数据库用于在 Ganglia Web 界面中可视化数据。目标是按照图 [fig:flo_ahc_ganglia_components] 所示配置 Ganglia。主节点运行两个 gmond 守护进程，一个专门用于收集来自主节点的数据，另一个用于收集来自工作节点上运行的 gmond 守护进程的数据。我们在 /opt 中安装了 Ganglia，该目录通过 NFS 安装在每个工作节点上。为了在主节点和工作节点上启动 gmond 和 gmetad 进程，使用了初始化脚本。问题是，下载的 tar 包中没有提供合适的初始化脚本。我们最初的想法是从 Ubuntu 存储库中提取（较旧）软件包的初始化脚本。该初始化脚本不能按预期工作。重新启动和停止 gmond 服务会导致主节点出现问题，因为那里正在运行 2 个 gmond 进程。它们不是通过服务的 pid 来被杀死的，而是通过名称来杀死的，这显然不是一个好主意。我们试图手动更改行为，但不幸的是，这不起作用。在 gmond 进程启动后，初始化系统会读取启动服务的 pid 并将其存储在 gmond.pid 文件中。问题是，gmond 进程在启动后会变成守护进程并更改运行用户（从 root 更改为 nobody）。这些操作也会更改 pid，这意味着 .pid 文件不再有效，停止和重新启动服务将无法工作。经过大量的尝试和错误，我们在最新的（尚未发布的）Ubuntu 版本 13.04 中找到一个有效的 upstart（Ubuntu 使用的新初始化系统）脚本。在该脚本中，我们只需要调整服务名称并确保在启动服务之前 NFS 分区已挂载（start on (mounted MOUNTPOINT=/opt and runlevel [2345])）。出于某种神奇的原因，这种设置即使在主节点上也适用于两个 gmond 进程。

主节点

我们首先配置 gmetad 守护进程。我们指定了两个数据源：“基础设施”（主节点）和“集群节点”（工作节点）。Gmetad 从主节点上运行的两个 gmond 进程中收集这些数据源的数据。为了防止冲突，两者都在不同的端口上接受连接：8649（基础设施）和 8650（集群节点）。我们还调整了网格名称和存储 rrd 数据库的目录。

清单 4.9 gmetad.conf 中的有趣部分。

data_source "Infrastructure" localhost:8649 data_source "Cluster Nodes" localhost:8650 gridname "AHC Cluster" rrd_rootdir "/opt/ganglia/rrds" 下一步是配置主节点上的 gmond 进程：gmond_master 和 gmond_collector。由于 gmond_master 进程不与其他 gmond 通信，因此不需要进行通信配置。我们只需要指定一个 tcp_accept_channel，gmond 在该通道上响应 gmetad 的查询。此外，可以为主机、集群和所有者指定名称，并提供位置（例如特定的机架）。

清单 4.10 gmond_master.conf 的配置。

tcp_accept_channel {
    port = 8649
}

gmond_collector 进程需要与四个 gmond_worker 进程进行通信。Ganglia 中存在两种不同的通信方法：单播和组播。我们选择了单播，设置起来很简单。gmond_collector 进程还必须接受来自 gmetad 进程的查询，因此我们指定了另一个 tcp_accept_channel。在指定的 udp_recv_channel 上，gmond_collector 等待来自 gmond_worker 进程的数据。

清单 4.11 gmond_collector.conf 的配置。

tcp_accept_channel {
    port = 8650
}
udp_recv_channel {
    port = 8666
}

工作节点

gmond_worker 进程既不监听其他 gmond 进程，也不接受来自 gmetad 守护进程的查询。因此，配置文件中唯一有趣的部分是该 gmond 守护进程的发送机制。

清单 4.12 gmond_worker.conf 的配置。

udp_send_channel {
    host = master
    port = 8666
    ttl = 1
}

用法

Ganglia 默认情况下已经收集和可视化了有关 CPU、内存、网络和存储的数据。还可以使用自定义插件扩展监控功能。收集到的数据可以在许多只有单个数据源的小图表中查看，或者在更大的聚合“报告”中查看。

ganglia 的首页显示了整个网格和“子集群”的许多聚合报告。图 4.7 显示了该首页，从该页面可以导航到单独的子集群以及特定的节点。该页面上的报告还显示了一些有趣的细节。例如，主节点每 5 分钟会有一些出站网络流量。默认情况下，所有报告都会显示过去一小时的数据，但也可以显示过去 2/4 小时、一周、一个月或一年的数据。

图形聚合

一个特别有趣的功能是自定义图形聚合。假设有一个报告可以可视化所有（例如 10 个）可用节点的 CPU 使用率。如果你运行一个需要其中四个节点的作业，你可能对另外 6 个节点的数据不感兴趣。使用 Ganglia，你可以创建一个自定义报告，该报告只匹配你使用正则表达式指定的节点。

如果这还不够，还可以创建完全自定义的聚合图形，你可以在其中指定使用的指标、轴限制和标签、图形类型（线或堆叠）和节点。在图 [fig:graph_aggregation] 中，我们指定了这样的一个图形。我们选择了一个自定义标题，将 Y 轴标签设置为百分比，将轴下限和上限设置为 0 和 100，并将系统 CPU 使用率设置为指标。也可以选择多个指标，只要组合有意义即可。

参考资料

↑ 长期支持
↑ https://www.icinga.org/
↑ https://launchpad.net/ formorer/+archive/icinga
↑ 安全外壳
↑ Nagios 远程插件执行器
↑ http://docs.icinga.org/latest/en/pluginapi.html
↑ http://ganglia.sourceforge.net/
↑ http://oss.oetiker.ch/rrdtool/

[1] 长期支持

[2] ttps://www.icinga.org/

[3] ttps://launchpad.net/ formorer/+archive/icinga

[4] 安全外壳

[5] Nagios 远程插件执行器

[6] ttp://docs.icinga.org/latest/en/pluginapi.html

[7] ttp://ganglia.sourceforge.net/

[8] ttp://oss.oetiker.ch/rrdtool/

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]