當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

小型Hadoop集群的Ganglia配置和一些故障排除

發布時間：2023/12/3 编程问答 31 豆豆

生活随笔收集整理的這篇文章主要介紹了小型Hadoop集群的Ganglia配置和一些故障排除小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

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集群。無需其他配置。

單點故障

在節點開始出現故障之前，此配置效果良好。而且我們知道他們會的！而且我們知道，不幸的是，我們的配置至少有兩個單點故障（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:8649akawa@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:33akawa@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

總結

以上是生活随笔為你收集整理的小型Hadoop集群的Ganglia配置和一些故障排除的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： vivoy5s有红外线功能吗
下一篇：为什么手机总是不能连接到FlashAir