Ganglia是一个针对大型集群的开源，可扩展且分布式的监视系统。 它收集，汇总并提供数十种与计算机相关的指标（例如CPU，内存，存储，网络使用情况）的时序视图。 您可以在UC Berkeley Grid上看到Ganglia的运行情况。

Ganglia也是监视Hadoop和HBase群集的流行解决方案，因为Hadoop（和HBase）具有将其度量发布到Ganglia的内置支持。 使用Ganglia，您可以轻松地查看特定HDSF数据节点随时间写入的字节数，给定HBase区域服务器的块缓存命中率，对HBase集群的请求总数，花费在垃圾收集上的时间以及很多很多其他。

基本神经节概述

神经节由三部分组成：

• Ganglia监视守护程序（gmond） –一个守护程序，需要在每个受监视的节点上运行。 它收集本地监视指标并宣布它们，并且（如果已配置）接收并汇总从othergmond发送给它的指标
  s（甚至来自自身）。
• Ganglia meta守护程序（gmetad） –定期从一个或多个数据源（数据源可以是agmond或othergmetad）进行轮询以接收和汇总当前指标的守护程序。 汇总结果存储在数据库中，并且可以XML格式导出到其他客户端，例如Web前端。
• Ganglia PHP Web前端 –它从meta守护程序检索组合的指标，并以精美的动态HTML页面的形式显示它们，其中包含各种实时图形。

如果您想了解有关gmond，gmetad和Web前端的更多信息，请在Ganglia的Wikipedia页面上找到很好的描述。 希望下面的图片（显示示例性配置）有助于理解这个想法：

在本文中，我将重点介绍Ganglia的配置。 如果您使用的是Debian，请参考以下教程进行安装（只需输入几个命令）。 我们在这篇文章中使用Ganglia 3.1.7。

小型Hadoop集群的Ganglia

虽然Ganglia是可伸缩的，分布式的并且可以监视数百乃至数千个节点，但是小型集群也可以从中受益（开发人员和管理员也可以从中受益，因为Ganglia是学习Hadoop和HBase内部的一种很好的经验方法）。 在本文中，我想描述一下我们如何在运行Hadoop和HBase的五节点群集（1个主节点和4个从属节点）上配置Ganglia。 我相信5节点集群（或类似大小）是许多公司和组织开始使用Hadoop的典型配置。 请注意，Ganglia具有足够的灵活性，可以通过多种方式进行配置。 在这里，我将简单描述我想要实现的最终效果以及实现方式。 我们的监控要求可以指定如下：

• 从每个节点轻松获取指标
• 轻松获取所有从属节点的汇总指标（这样我们将知道MapReduce作业和HBase操作使用了多少资源）
• 轻松获取所有主节点的聚合指标（到目前为止，我们只有一个主节点，但是当集群增长时，我们将一些主重传（例如JobTracker，Secondary Namenode）移动到单独的机器上）
• 轻松获取所有节点的汇总指标（以获取集群的总体状态）

这意味着我希望Ganglia将集群视为两个“逻辑”子集群，例如“主”和“从”。 基本上，我希望看到这样的页面：

可能的Ganglia配置

这是一张说明性图片，显示了满足我们所有要求的5节点Hadoop集群的简单Ganglia配置。 因此，让我们以这种方式进行配置！

请注意，我们希望保留尽可能多的默认设置。 默认：

• gmond在UDP端口8649上进行通信（在gmond.conf中指定了inudp_send_channel和udp_recv_channel部分）
• gmetad在TCP端口8649上下载指标（在intcp_accept_channel部分ingmond.conf中指定，在gmetad.conf中的data_source条目中）

但是，一项设置​​将被更改。 我们将gmond之间的通信方法设置为单播UDP消息（而不是多播UDP消息）。 与多播相比，单播具有以下优点：对于较大的群集（例如，具有一百多个节点的群集）更好，并且Amazon EC2环境也支持单播（与多播不同）。

Ganglia监视守护程序（gmond）配置

根据上图：

• 每个节点都运行agmond。

从站子集群配置

• slave1，slave2，slave3和slave4节点上的每个gmond都定义udp_send_channel，以将度量标准发送到slave1（端口8649）
• slave1上的gmond定义udp_recv_channel（端口8649）以侦听传入的度量，并定义tcp_accept_channel（端口8649）以宣布它们。 这意味着该gmond是该子集群的“引导节点”，并收集所有gmond从从节点（甚至从自身）通过UDP（端口8649）发送的所有度量标准，稍后可以由gmetad通过TCP（端口8649）进行轮询。

掌握子集群配置

• 主节点上的gmond定义udp_send_channel以将数据发送到主节点（端口8649），udp_recv_channel（端口8649）和tcp_accept_channel（端口8649）。 这意味着它成为该单节点群集的“主导节点”，并从自身收集所有指标并将其公开给gmetad。 该配置应在gmond.conf文件中指定（您可以在/ etc / ganglia /中找到它）。 slave1的gmond.conf（仅包括最重要的设置）：

cluster {name = 'hadoop-slaves'...
}
udp_send_channel {host = slave1.node.IP.addressport = 8649
}
udp_recv_channel {port = 8649
}
tcp_accept_channel {port = 8649
}

适用于slave2，slave3，slave4的gmond.conf（实际上，也可以使用与slave1相同的gmond.conf文件）：

cluster {name = 'hadoop-slaves'...
}
udp_send_channel {host = slave1.node.IP.addressport = 8649
}
udp_recv_channel {}
tcp_accept_channel {}

主节点的gmond.conf文件应与slave1的gmond.conf文件类似–只需将master1的IP地址替换为slave1的IP地址，并将群集名称设置为“ hadoop-masters”。 您可以在此处阅读有关gmond的配置部分和属性的更多信息。

Ganglia meta守护程序（gmetad）

gmetad的配置更加简单：

• 大师级跑步
• gmetad定义了两个数据源：

data_source 'hadoop-masters' master.node.IP.address
data_source 'hadoop-slaves' slave1.node.IP.address

该配置应在gmetad.conf文件中指定（您可以在/ etc / ganglia /中找到它）。

Hadoop和HBase与Ganglia集成

Hadoop和HBase使用GangliaContext类将每个守护程序收集的指标（例如datanode，tasktracker，jobtracker，HMaster等）发送到gmond。 成功设置Ganglia后，您可能需要编辑/etc/hadoop/conf/hadoop-metrics.properties和/etc/hbase/conf/hadoop-metrics.properties，以向Ganglia宣布与Hadoop和HBase相关的度量。 由于我们使用与Ganglia版本3.1.x兼容的CDH 4.0.1，因此我们在属性文件中使用了新引入的GangliaContext31（而不是较旧的GangliaContext类）。

从站的度量标准配置

# /etc/hadoop/conf/hadoop-metrics.properties
...
dfs.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
dfs.period=10
dfs.servers=hadoop-slave1.IP.address:8649
...
mapred.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
mapred.period=10
mapred.servers=hadoop-slave1.IP.address:8649
...

主站的指标配置

应该与从站相同–例如，只需使用hadoop-master.IP.address：8649（而不是hadoop slave1.IP.address：8649）即可：

# /etc/hbase/conf/hadoop-metrics.properties
...
hbase.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
hbase.period=10
hbase.servers=hadoop-master.IP.address:8649
...

切记在所有节点上都编辑两个属性文件（对于Hadoop编辑/etc/hadoop/conf/hadoop-metrics.properties，对于HBase编辑/etc/hbase/conf/hadoop-metrics.properties），然后重新启动Hadoop和HBase集群。 无需其他配置。

更多细节

实际上，令我惊讶的是Hadoop的恶魔确实将数据发送到某个地方，而不仅仅是被轮询该数据。 这是什么意思？ 例如，这意味着每个单个从节点都运行多个进程（例如gmond，datanode，tasktracker和regionserver），这些进程收集度量并将其发送到在slave1节点上运行的gmond。 如果我们在slave2，slave3和slave4上停止gmonds，但仍运行Hadoop的守护程序，我们仍将获得与Hadoop相关的度量标准（但不会获得有关内存，cpu使用情况的度量标准，因为它们是由停止的gmond s发送的）。 请查看下面的图片中的slave2节点，以了解（或多或少）它是如何工作的（tt，dd和rs分别表示tasktracker，datanode和regionserver，而删除slave4是为了提高可读性）。

单点故障

在节点开始出现故障之前，此配置效果良好。 而且我们知道他们会的！ 而且我们知道，不幸的是，我们的配置至少有两个单点故障（SPoF）：

• 在slave1上的gmond（如果该节点发生故障，则有关所有从节点的所有监视统计信息将不可用）
• gmetad和master上的Web前端（如果该节点发生故障，则整个监视系统将不可用。这意味着我们不仅会释放最重要的Hadoop节点（实际上，它应称为SUPER-master，因为它有很多master守护程序）已安装，但我们也失去了宝贵的监视信息源，可通过查看该节点在发生故障前的瞬间生成的图形和度量来帮助我们检测故障原因）

避免在slave1节点上使用Ganglia的SPoF

幸运的是，您可以根据需要指定任意数量的udp_send_channels，以向其他gmond冗余发送度量（假设这些gmond指定udp_recv_channels来监听传入的度量）。 在我们的例子中，我们可能选择slave2也是额外的引导节点（与slave1一起）以冗余地收集指标（并向gmetad通知他们）

• 在所有从属节点上运行updategmond.conf并定义其他udp_send_channel部分以将度量标准发送到slave2（端口8649）
• 在slave2上的updategmond.conf上定义udp_recv_channel（端口8649）以侦听传入的度量，并在tcp_accept_channel（端口8649）上宣布它们（在slave1的gmond.conf中已经设置了相同的设置）
• 在从属节点上运行的Hadoop和HBase守护程序的updatehadoop-metrics.properties文件，以将其度量标准同时发送到slave1和slave2。例如：

# /etc/hbase/conf/hadoop-metrics.properties
...
hbase.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
hbase.period=10
hbase.servers=hadoop-slave1.IP.address:8649,hadoop-slave2.IP.address:8649

• 最终updatedata_source“ hadoop-slaves” ingmetad.conf从两个冗余gmond s轮询数据（如果gmetad无法从slave1.node.IP.address提取数据，它将继续尝试slave2.node.IP.address）：

data_source 'hadoop-slaves' slave1.node.IP.address slave2.node.IP.address

也许下面的图片不是很幸运（有很多箭头），但是它的意思是，如果slave1发生故障，那么gmetad将能够从slave2节点上的gmond获取指标（因为所有从节点都将指标冗余地发送给在slave1上运行的gmond s和slave2）。

避免在主节点上使用Ganglia的SPoF

这里的主要思想是不要将gmetad（和Web前端）与Hadoop主守护程序并置，这样，如果主节点发生故障（或根本变得不可用），我们就不会丢失监视统计信息。 一个想法是，例如，将gmetad（和Web前端）从slave1移到slave3（或slave4），或者简单地引入一个在slave3（或slave4）上运行的冗余gmetad。 前者的想法似乎还可以，而后者则使如此小的集群变得非常复杂。 我想，更好的主意是引入一个额外的节点（如果可能，称为“边缘”节点），该节点运行gmetad和Web前端（它可能还安装了基本的Hadoop和HBase软件包，但不运行任何Hadoop的守护程序-它仅充当客户端计算机，以启动MapReduce作业并访问HBase。 实际上，“边缘”节点通常用于在用户和群集之间提供接口（例如，它运行Pig和Hive ， Oozie ）。

故障排除和提示可能会有所帮助

由于调试配置的各个方面是设置Ganglia的最长部分，因此我在这里分享了一些技巧。 请注意，本文并不涵盖所有可能的疑难解答，而是基于我们遇到并最终设法解决的问题。

从小开始

尽管Ganglia的过程配置不是那么复杂，但是最好仅从两个节点开始，如果可行，将其扩展到更大的集群。 但是之前，您需要安装任何Ganglia的守护程序…

尝试将“ Hello”从node1发送到node2

确保可以使用UDP协议与给定目标主机上的端口8649进行通信。 netcat是一个简单的工具，可以帮助您进行验证。 打开节点1（稍后称为“引导节点”）上的端口8649以进行入站UDP连接，然后从节点2向其发送一些文本。

# listen (-l option) for inbound UDP (-u option) connections on port 8649
# and prints received data
akawa@hadoop-slave1:~$ nc -u -l -p 8649

# create a UDP (-u option) connection to hadoop-slave1:8649
# and send text from stdin to that node:
akawa@hadoop-slave2:~$ nc -u hadoop-slave1 8649
Hello My Lead Node

# look at slave1's console to see if the text was sucessfully delivered
akawa@hadoop-slave1:~$
Hello My Lead Node

如果不起作用，请仔细检查您的iptables规则（如果使用IPv6，则为iptables或ip6tables）是否为UDP和TCP连接打开了端口8649。

让gmond将数据发送到另一个gmond

在两个节点上安装gmond，并验证一个节点是否可以使用端口8649上的UDP连接将其指标发送到另一个节点。您可以在gmond.conf文件中为两个节点使用以下设置：

cluster {name = 'hadoop-slaves'
}
udp_send_channel {host = the.lead.node.IP.addressport = 8649
}
udp_recv_channel {port = 8649
}
tcp_accept_channel {}

运行完gmonds后（sudo /etc/init.d/ganglia-monitor start），可以使用lsof检查连接是否建立：

akawa@hadoop-slave1:~$ sudo lsof -i :8649
COMMAND   PID    USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
gmond   48746 ganglia    4u  IPv4 201166172      0t0  UDP *:8649
gmond   48746 ganglia    5u  IPv4 201166173      0t0  TCP *:8649 (LISTEN)
gmond   48746 ganglia    6u  IPv4 201166175      0t0  UDP hadoop-slave1:35702->hadoop-slave1:8649

akawa@hadoop-slave2:~$ sudo lsof -i :8649
COMMAND   PID    USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
gmond   31025 ganglia    6u  IPv4 383110679      0t0  UDP hadoop-slave2:60789->hadoop-slave1:8649

要查看是否有任何数据实际发送到引导节点，请使用tcpdump转储端口8649上的网络流量：

akawa@hadoop-slave1:~$ sudo tcpdump -i eth-pub udp port 8649
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth-pub, link-type EN10MB (Ethernet), capture size 65535 bytes
18:08:02.236625 IP hadoop-slave2.60789 > hadoop-slave1.8649: UDP, length 224
18:08:02.236652 IP hadoop-slave2.60789 > hadoop-slave1.8649: UDP, length 52
18:08:02.236661 IP hadoop-slave2.60789 > hadoop-slave1.8649: UDP, length 236

使用调试选项

tcpdump显示某些数据已传输，但没有告诉您发送了哪种数据。 希望在调试模式下运行gmond或gmetad可以为我们提供更多信息（由于在调试模式下它不能作为守护程序运行，因此只需使用Ctrl + C即可停止运行）

akawa@hadoop-slave1:~$ sudo /etc/init.d/ganglia-monitor stop
akawa@hadoop-slave1:~$ sudo /usr/sbin/gmond -d 2loaded module: core_metrics
loaded module: cpu_module
...
udp_recv_channel mcast_join=NULL mcast_if=NULL port=-1 bind=NULL
tcp_accept_channel bind=NULL port=-1
udp_send_channel mcast_join=NULL mcast_if=NULL host=hadoop-slave1.IP.address port=8649metric 'cpu_user' being collected nowmetric 'cpu_user' has value_threshold 1.000000...............metric 'swap_free' being collected nowmetric 'swap_free' has value_threshold 1024.000000metric 'bytes_out' being collected now********** bytes_out:  21741.789062....
Counting device /dev/mapper/lvm0-rootfs (96.66 %)
Counting device /dev/mapper/360a980006467435a6c5a687069326462 (35.31 %)
For all disks: 8064.911 GB total, 5209.690 GB free for users.metric 'disk_total' has value_threshold 1.000000metric 'disk_free' being collected now.....sent message 'cpu_num' of length 52 with 0 errorssending metadata for metric: cpu_speed

我们看到收集了各种度量并将其发送到host = hadoop-slave1.IP.address port = 8649。 不幸的是，它只能告诉您您是通过UDP发送的，因此无法正确传递您的消息。

不要混合使用IPv4和IPv6

让我们看一下集群中遇到的实际情况（这是神秘而烦人的Ganglia错误配置的根本原因）。 首先，查看lsof结果。

akawa@hadoop-slave1:~$ sudo  lsof -i :8649
COMMAND   PID    USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
gmond   38431 ganglia    4u  IPv4 197424417      0t0  UDP *:8649
gmond   38431 ganglia    5u  IPv4 197424418      0t0  TCP *:8649 (LISTEN)
gmond   38431 ganglia    6u  IPv4 197424422      0t0  UDP hadoop-slave1:58304->hadoop-slave1:864913:56:33

akawa@ceon.pl: akawa@hadoop-slave2:~$ sudo  lsof -i :8649
COMMAND   PID    USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
gmond   23552 ganglia    6u  IPv6 382340910      0t0  UDP hadoop-slave2:36999->hadoop-slave1:8649

在此，hadoop-slave2将度量发送到右侧端口上的hadoop-slave1，并且hadoop-slave1也将在右侧端口上侦听。 除了一个重要的细节外，所有内容都与上一节中的代码片段几乎相同– hadoop-slave2通过IPv6发送，而hadoop-slave1通过IPv4读取！ 最初的猜测是更新ip6tables（除iptables之外）规则以打开端口8649，以通过IPv6进行UDP和TCP连接。 但这没有用。 当我们在gmond.conf文件中将主机名“ hadoop-slave1.vls”更改为其IP地址时，它就起作用了（是的，之前我在每个文件中都使用主机名而不是IP地址）。 确保将您的IP地址正确解析为主机名，反之亦然。

使用gstat获取集群摘要

如果您设法将发送指标从slave2发送到slave1，则意味着您的集群正在运行。 在Ganglia的术语中，群集是一组主机，它们在gmond.conf文件中共享相同的群集名称属性，例如“ hadoop-slaves”。 Ganglia提供了一个有用的名为gstat的功能，它可以打印由在给定节点上运行的gmond表示的主机列表。

akawa@hadoop-slave1:~$ gstat --all
CLUSTER INFORMATIONName: hadoop-slavesHosts: 2
Gexec Hosts: 0Dead Hosts: 0Localtime: Tue Aug 21 22:46:21 2012CLUSTER HOSTS
Hostname                     LOAD                       CPU              GexecCPUs (Procs/Total) [     1,     5, 15min] [  User,  Nice, System, Idle, Wio]
hadoop-slave248 (    0/  707) [  0.01,  0.07,  0.09] [   0.1,   0.0,   0.1,  99.8,   0.0] OFF
hadoop-slave148 (    0/  731) [  0.01,  0.06,  0.07] [   0.0,   0.0,   0.1,  99.9,   0.0] OFF

检查gmetad从哪里轮询指标

在运行gmetad的主机上运行以下命令，以检查其轮询指标的群集和主机（以某种方式grep以仅显示有用的行）：

akawa@hadoop-master:~$ nc localhost 8651 | grep hadoop<GRID NAME='Hadoop_And_HBase' AUTHORITY='http://hadoop-master/ganglia/' LOCALTIME='1345642845'>
<CLUSTER NAME='hadoop-masters' LOCALTIME='1345642831' OWNER='ICM' LATLONG='unspecified' URL='http://ceon.pl'>
<HOST NAME='hadoop-master' IP='hadoop-master.IP.address' REPORTED='1345642831' TN='14' TMAX='20' DMAX='0' LOCATION='unspecified' GMOND_STARTED='1345632023'>
<CLUSTER NAME='hadoop-slaves' LOCALTIME='1345642835' OWNER='ICM' LATLONG='unspecified' URL='http://ceon.pl'>
<HOST NAME='hadoop-slave4' IP='...' REPORTED='1345642829' TN='16' TMAX='20' DMAX='0' LOCATION='unspecified' GMOND_STARTED='1345478489'>
<HOST NAME='hadoop-slave2' IP='...' REPORTED='1345642828' TN='16' TMAX='20' DMAX='0' LOCATION='unspecified' GMOND_STARTED='1345581519'>
<HOST NAME='hadoop-slave3' IP='...' REPORTED='1345642829' TN='15' TMAX='20' DMAX='0' LOCATION='unspecified' GMOND_STARTED='1345478489'>
<HOST NAME='hadoop-slave1' IP='...' REPORTED='1345642833' TN='11' TMAX='20' DMAX='0' LOCATION='unspecified' GMOND_STARTED='1345572002'>

备择方案

由于监视群集是非常广泛的主题，因此有许多工具可以帮助您完成此任务。 对于Hadoop集群，除了Ganglia之外，您还可以找到许多其他有趣的替代方案。 我只想简短地提到其中的几个。

Cloudera Manager 4（企业版）

除了大大简化Hadoop集群的安装和配置过程之外，Cloudera Manager还提供了一些有用的功能来监视和可视化Hadoop的数十种服务性能指标以及与主机相关的信息，包括CPU，内存，磁盘使用率和网络I / O。 此外，它会在您接近关键阈值时向您发出警报（Ganglia本身不提供警报，但可以与Nagios和Hyperic等警报系统集成）。 您可以在此处了解有关Cloudera Manager关键功能的更多信息。

仙人掌，Zabbix，Nagios，Hyperic

请访问仙人掌网站以了解有关此工具的更多信息。 这也是有关使用Cacti进行Hadoop Graphing的非常有趣的博客文章。 Zabbix ， Nagios和Hyperic是您可能还需要研究的工具。

致谢

我要非常感谢我的同事Pawel Tecza和Artur Czeczko，他们帮助我在集群上配置和调试了Ganglia。

参考： 一个小型Hadoop集群的Ganglia配置以及 Hakuna MapData的 JCG合作伙伴 Adam Kawa的一些故障排除 方法！ 博客。

翻译自: https://www.javacodegeeks.com/2013/04/ganglia-configuration-for-a-small-hadoop-cluster-and-some-troubleshooting.html