天津企业做网站,锦江网站建设,网站页面建设需要ps吗,网页美工基础Ganglia是一个针对大型集群的开源#xff0c;可扩展且分布式的监视系统。 它收集#xff0c;汇总并提供数十种与计算机相关的指标#xff08;例如CPU#xff0c;内存#xff0c;存储#xff0c;网络使用情况#xff09;的时序视图。 您可以在UC Berkeley Grid上看到Gang… 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页面的形式显示它们其中包含各种实时图形。 如果您想了解有关gmondgmetad和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操作使用了多少资源 轻松获取所有主节点的聚合指标到目前为止我们只有一个主节点但是当集群增长时我们将一些主重传例如JobTrackerSecondary 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。 从站子集群配置 slave1slave2slave3和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以将数据发送到主节点端口8649udp_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
} 适用于slave2slave3slave4的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类将每个守护程序收集的指标例如datanodetasktrackerjobtrackerHMaster等发送到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.classorg.apache.hadoop.metrics.ganglia.GangliaContext31
dfs.period10
dfs.servershadoop-slave1.IP.address:8649
...
mapred.classorg.apache.hadoop.metrics.ganglia.GangliaContext31
mapred.period10
mapred.servershadoop-slave1.IP.address:8649
... 主站的指标配置 应该与从站相同–例如只需使用hadoop-master.IP.address8649而不是hadoop slave1.IP.address8649即可 # /etc/hbase/conf/hadoop-metrics.properties
...
hbase.classorg.apache.hadoop.metrics.ganglia.GangliaContext31
hbase.period10
hbase.servershadoop-master.IP.address:8649
... 切记在所有节点上都编辑两个属性文件对于Hadoop编辑/etc/hadoop/conf/hadoop-metrics.properties对于HBase编辑/etc/hbase/conf/hadoop-metrics.properties然后重新启动Hadoop和HBase集群。 无需其他配置。 更多细节 实际上令我惊讶的是Hadoop的恶魔确实将数据发送到某个地方而不仅仅是被轮询该数据。 这是什么意思 例如这意味着每个单个从节点都运行多个进程例如gmonddatanodetasktracker和regionserver这些进程收集度量并将其发送到在slave1节点上运行的gmond。 如果我们在slave2slave3和slave4上停止gmonds但仍运行Hadoop的守护程序我们仍将获得与Hadoop相关的度量标准但不会获得有关内存cpu使用情况的度量标准因为它们是由停止的gmond s发送的。 请查看下面的图片中的slave2节点以了解或多或少它是如何工作的ttdd和rs分别表示tasktrackerdatanode和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.classorg.apache.hadoop.metrics.ganglia.GangliaContext31
hbase.period10
hbase.servershadoop-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
akawahadoop-slave1:~$ nc -u -l -p 8649# create a UDP (-u option) connection to hadoop-slave1:8649
# and send text from stdin to that node:
akawahadoop-slave2:~$ nc -u hadoop-slave1 8649
Hello My Lead Node# look at slave1s console to see if the text was sucessfully delivered
akawahadoop-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检查连接是否建立 akawahadoop-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:8649akawahadoop-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上的网络流量 akawahadoop-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即可停止运行 akawahadoop-slave1:~$ sudo /etc/init.d/ganglia-monitor stop
akawahadoop-slave1:~$ sudo /usr/sbin/gmond -d 2loaded module: core_metrics
loaded module: cpu_module
...
udp_recv_channel mcast_joinNULL mcast_ifNULL port-1 bindNULL
tcp_accept_channel bindNULL port-1
udp_send_channel mcast_joinNULL mcast_ifNULL hosthadoop-slave1.IP.address port8649metric 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结果。 akawahadoop-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:33akawaceon.pl: akawahadoop-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表示的主机列表。 akawahadoop-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以仅显示有用的行 akawahadoop-master:~$ nc localhost 8651 | grep hadoopGRID NAMEHadoop_And_HBase AUTHORITYhttp://hadoop-master/ganglia/ LOCALTIME1345642845
CLUSTER NAMEhadoop-masters LOCALTIME1345642831 OWNERICM LATLONGunspecified URLhttp://ceon.pl
HOST NAMEhadoop-master IPhadoop-master.IP.address REPORTED1345642831 TN14 TMAX20 DMAX0 LOCATIONunspecified GMOND_STARTED1345632023
CLUSTER NAMEhadoop-slaves LOCALTIME1345642835 OWNERICM LATLONGunspecified URLhttp://ceon.pl
HOST NAMEhadoop-slave4 IP... REPORTED1345642829 TN16 TMAX20 DMAX0 LOCATIONunspecified GMOND_STARTED1345478489
HOST NAMEhadoop-slave2 IP... REPORTED1345642828 TN16 TMAX20 DMAX0 LOCATIONunspecified GMOND_STARTED1345581519
HOST NAMEhadoop-slave3 IP... REPORTED1345642829 TN15 TMAX20 DMAX0 LOCATIONunspecified GMOND_STARTED1345478489
HOST NAMEhadoop-slave1 IP... REPORTED1345642833 TN11 TMAX20 DMAX0 LOCATIONunspecified GMOND_STARTED1345572002备择方案 由于监视群集是非常广泛的主题因此有许多工具可以帮助您完成此任务。 对于Hadoop集群除了Ganglia之外您还可以找到许多其他有趣的替代方案。 我只想简短地提到其中的几个。 Cloudera Manager 4企业版 除了大大简化Hadoop集群的安装和配置过程之外Cloudera Manager还提供了一些有用的功能来监视和可视化Hadoop的数十种服务性能指标以及与主机相关的信息包括CPU内存磁盘使用率和网络I / O。 此外它会在您接近关键阈值时向您发出警报Ganglia本身不提供警报但可以与Nagios和Hyperic等警报系统集成。 您可以在此处了解有关Cloudera Manager关键功能的更多信息。 仙人掌ZabbixNagiosHyperic 请访问仙人掌网站以了解有关此工具的更多信息。 这也是有关使用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