hadoop小型集群_小型Hadoop集群的Ganglia配置和一些故障排除
hadoop小型集群
Ganglia是一個(gè)針對(duì)大型集群的開(kāi)源，可擴(kuò)展且分布式的監(jiān)視系統(tǒng)。 它收集，匯總并提供數(shù)十種與計(jì)算機(jī)相關(guān)的指標(biāo)（例如CPU，內(nèi)存，存儲(chǔ)，網(wǎng)絡(luò)使用情況）的時(shí)序視圖。 您可以在UC Berkeley Grid上看到Ganglia的運(yùn)行情況。
Ganglia也是監(jiān)視Hadoop和HBase群集的流行解決方案，因?yàn)镠adoop（和HBase）具有將其度量發(fā)布到Ganglia的內(nèi)置支持。 使用Ganglia，您可以輕松地查看特定HDSF數(shù)據(jù)節(jié)點(diǎn)隨時(shí)間寫(xiě)入的字節(jié)數(shù)，給定HBase區(qū)域服務(wù)器的塊緩存命中率，對(duì)HBase集群的請(qǐng)求總數(shù)，在垃圾收集上花費(fèi)的時(shí)間以及許多很多其他。
基本神經(jīng)節(jié)概述
神經(jīng)節(jié)由三部分組成：
- Ganglia監(jiān)視守護(hù)程序（gmond） –一個(gè)守護(hù)程序，需要在每個(gè)受監(jiān)視的節(jié)點(diǎn)上運(yùn)行。 它收集本地監(jiān)視指標(biāo)并宣布它們，并且（如果已配置）接收并匯總從othergmond發(fā)送給它的指標(biāo)
s（甚至來(lái)自自身）。 - Ganglia meta守護(hù)程序（gmetad） –定期從一個(gè)或多個(gè)數(shù)據(jù)源（數(shù)據(jù)源可以是agmond或othergmetad）進(jìn)行輪詢以接收和匯總當(dāng)前指標(biāo)的守護(hù)程序。 匯總結(jié)果存儲(chǔ)在數(shù)據(jù)庫(kù)中，并且可以XML格式導(dǎo)出到其他客戶端，例如Web前端。
- Ganglia PHP Web前端 –它從meta守護(hù)程序檢索組合的指標(biāo)，并以精美的動(dòng)態(tài)HTML頁(yè)面的形式顯示它們，其中包含各種實(shí)時(shí)圖形。
如果您想了解有關(guān)gmond，gmetad和Web前端的更多信息，請(qǐng)?jiān)贕anglia的Wikipedia頁(yè)面上找到很好的描述。 希望下面的圖片（顯示一個(gè)示例性配置）有助于理解這個(gè)想法：
在本文中，我將重點(diǎn)介紹Ganglia的配置。 如果您使用的是Debian，請(qǐng)參考以下教程進(jìn)行安裝（只需鍵入幾個(gè)命令）。 我們?cè)谶@篇文章中使用Ganglia 3.1.7。
小型Hadoop集群的Ganglia
盡管Ganglia是可伸縮的，分布式的并且可以監(jiān)視數(shù)百乃至數(shù)千個(gè)節(jié)點(diǎn)，但是小型集群也可以從中受益（開(kāi)發(fā)人員和管理員也可以從中受益，因?yàn)镚anglia是學(xué)習(xí)Hadoop和HBase內(nèi)部的一種很好的經(jīng)驗(yàn)方法）。 在本文中，我將描述我們?nèi)绾卧谶\(yùn)行Hadoop和HBase的五節(jié)點(diǎn)群集（1個(gè)主節(jié)點(diǎn)和4個(gè)從屬節(jié)點(diǎn)）上配置Ganglia。 我相信5節(jié)點(diǎn)集群（或類似大小）是許多公司和組織開(kāi)始使用Hadoop的典型配置。 請(qǐng)注意，Ganglia具有足夠的靈活性，可以通過(guò)多種方式進(jìn)行配置。 在這里，我將簡(jiǎn)單描述我想要實(shí)現(xiàn)的最終效果以及實(shí)現(xiàn)方式。 我們的監(jiān)視要求可以指定如下：
- 從每個(gè)節(jié)點(diǎn)輕松獲取指標(biāo)
- 輕松獲取所有從屬節(jié)點(diǎn)的匯總指標(biāo)（這樣我們將知道MapReduce作業(yè)和HBase操作使用了多少資源）
- 輕松獲取所有主節(jié)點(diǎn)的聚合指標(biāo)（到目前為止，我們只有一個(gè)主節(jié)點(diǎn)，但是當(dāng)集群增長(zhǎng)時(shí)，我們會(huì)將一些主重傳（例如JobTracker，Secondary Namenode）移動(dòng)到單獨(dú)的機(jī)器上）
- 輕松獲取所有節(jié)點(diǎn)的匯總指標(biāo)（以獲取群集的總體狀態(tài)）
這意味著我希望Ganglia將集群視為兩個(gè)“邏輯”子集群，例如“主”和“從”。 基本上，我希望看到這樣的頁(yè)面：
可能的Ganglia配置
這是一張說(shuō)明圖，顯示了滿足我們所有要求的5節(jié)點(diǎn)Hadoop集群的簡(jiǎn)單Ganglia配置。 因此，讓我們以這種方式進(jìn)行配置！
請(qǐng)注意，我們希望保留盡可能多的默認(rèn)設(shè)置。 默認(rèn)：
- gmond在UDP端口8649上通信（在gmond.conf中指定了inudp_send_channel和inudp_recv_channel部分）
- gmetad在TCP端口8649上下載指標(biāo)（在intcp_accept_channel部分ingmond.conf中指定，在gmetad.conf中的data_source條目中）
但是，一項(xiàng)設(shè)置??將被更改。 我們將gmond之間的通信方法設(shè)置為單播UDP消息（而不是多播UDP消息）。 與多播相比，單播具有以下優(yōu)點(diǎn)：對(duì)于較大的群集（例如，具有一百多個(gè)節(jié)點(diǎn)的群集）更好，并且Amazon EC2環(huán)境中支持單播（與多播不同）。
Ganglia監(jiān)視守護(hù)程序（gmond）配置
根據(jù)上圖：
- 每個(gè)節(jié)點(diǎn)都運(yùn)行agmond。
從站子集群配置
- slave1，slave2，slave3和slave4節(jié)點(diǎn)上的每個(gè)gmond定義udp_send_channel，以將度量標(biāo)準(zhǔn)發(fā)送到slave1（端口8649）
- slave1上的gmond定義udp_recv_channel（端口8649）以偵聽(tīng)傳入的度量，并定義tcp_accept_channel（端口8649）以宣布它們。 這意味著該gmond是該子集群的“引導(dǎo)節(jié)點(diǎn)”，并收集所有g(shù)mond從屬節(jié)點(diǎn)（甚至從自身）通過(guò)UDP（端口8649）發(fā)送的所有度量標(biāo)準(zhǔn)，稍后可以由gmetad通過(guò)TCP（端口8649）進(jìn)行輪詢。
掌握子集群配置
- 主節(jié)點(diǎn)上的gmond定義了udp_send_channel以將數(shù)據(jù)發(fā)送到主節(jié)點(diǎn)（端口8649），udp_recv_channel（端口8649）和tcp_accept_channel（端口8649）。 這意味著它成為該單節(jié)點(diǎn)群集的“主導(dǎo)節(jié)點(diǎn)”，并從自身收集所有指標(biāo)并將其公開(kāi)給gmetad。 該配置應(yīng)在gmond.conf文件中指定（您可以在/ etc / ganglia /中找到它）。 slave1的gmond.conf（僅包括最重要的設(shè)置）：
適用于slave2，slave3，slave4的gmond.conf（實(shí)際上，也可以使用與slave1相同的gmond.conf文件）：
cluster {name = 'hadoop-slaves'... } udp_send_channel {host = slave1.node.IP.addressport = 8649 } udp_recv_channel {} tcp_accept_channel {}主節(jié)點(diǎn)的gmond.conf文件應(yīng)與slave1的gmond.conf文件類似–只需將master1的IP地址替換為slave1的IP地址，并將群集名稱設(shè)置為“ hadoop-masters”。 您可以在此處閱讀有關(guān)gmond的配置部分和屬性的更多信息。
Ganglia meta守護(hù)程序（gmetad）
gmetad的配置更加簡(jiǎn)單：
- 大師級(jí)跑步
- gmetad定義了兩個(gè)數(shù)據(jù)源：
該配置應(yīng)在gmetad.conf文件中指定（您可以在/ etc / ganglia /中找到它）。
Hadoop和HBase與Ganglia集成
Hadoop和HBase使用GangliaContext類將每個(gè)守護(hù)程序收集的指標(biāo)（例如datanode，tasktracker，jobtracker，HMaster等）發(fā)送到gmond。 成功設(shè)置Ganglia后，您可能需要編輯/etc/hadoop/conf/hadoop-metrics.properties和/etc/hbase/conf/hadoop-metrics.properties，以向Ganglia宣布與Hadoop和HBase相關(guān)的度量。 由于我們使用與Ganglia版本3.1.x兼容的CDH 4.0.1，因此我們?cè)趯傩晕募惺褂昧诵乱氲腉angliaContext31（而不是較舊的GangliaContext類）。
從站的度量標(biāo)準(zhǔn)配置
# /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 ...主站的指標(biāo)配置
應(yīng)該與奴隸相同–只需使用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 ...切記在所有節(jié)點(diǎn)上編輯兩個(gè)屬性文件（對(duì)于Hadoop編輯/etc/hadoop/conf/hadoop-metrics.properties，對(duì)于HBase編輯/etc/hbase/conf/hadoop-metrics.properties），然后重新啟動(dòng)Hadoop和HBase集群。 無(wú)需其他配置。
更多細(xì)節(jié)
實(shí)際上，令我驚訝的是Hadoop的惡魔確實(shí)將數(shù)據(jù)發(fā)送到某個(gè)地方，而不僅僅是被輪詢?cè)摂?shù)據(jù)。 這是什么意思？ 例如，這意味著每個(gè)單個(gè)從節(jié)點(diǎn)都運(yùn)行多個(gè)進(jìn)程（例如gmond，datanode，tasktracker和regionserver），這些進(jìn)程收集度量并將其發(fā)送到在slave1節(jié)點(diǎn)上運(yùn)行的gmond。 如果我們?cè)趕lave2，slave3和slave4上停止gmonds，但仍運(yùn)行Hadoop的守護(hù)程序，我們?nèi)詫@得與Hadoop相關(guān)的指標(biāo)（但不會(huì)獲得有關(guān)內(nèi)存，cpu使用情況的指標(biāo)，因?yàn)樗鼈兪怯赏Ｖ沟膅mond s發(fā)送的）。 請(qǐng)查看下面的圖片中的slave2節(jié)點(diǎn)，以了解（或多或少）其工作方式（tt，dd和rs分別表示tasktracker，datanode和regionserver，而刪除slave4是為了提高可讀性）。
單點(diǎn)故障
在節(jié)點(diǎn)開(kāi)始出現(xiàn)故障之前，此配置效果良好。 而且我們知道他們會(huì)的！ 而且我們知道，不幸的是，我們的配置至少有兩個(gè)單點(diǎn)故障（SPoF）：
- 在slave1上的gmond（如果該節(jié)點(diǎn)發(fā)生故障，則有關(guān)所有從節(jié)點(diǎn)的所有監(jiān)視統(tǒng)計(jì)信息將不可用）
- gmetad和master上的Web前端（如果該節(jié)點(diǎn)發(fā)生故障，則整個(gè)監(jiān)視系統(tǒng)將不可用。這意味著我們不僅會(huì)釋放最重要的Hadoop節(jié)點(diǎn)（實(shí)際上，它應(yīng)稱為SUPER-master，因?yàn)樗泻芏鄊aster守護(hù)程序）已安裝，但我們也失去了寶貴的監(jiān)視信息源，可通過(guò)查看該節(jié)點(diǎn)在故障發(fā)生前一刻生成的圖形和度量來(lái)幫助我們檢測(cè)故障原因）
避免在slave1節(jié)點(diǎn)上使用Ganglia的SPoF
幸運(yùn)的是，您可以指定任意數(shù)量的udp_send_channels，以將度量標(biāo)準(zhǔn)冗余地發(fā)送到其他gmond（假設(shè)這些gmond指定udp_recv_channels來(lái)監(jiān)聽(tīng)傳入的度量標(biāo)準(zhǔn)）。 在我們的例子中，我們可能選擇slave2作為額外的引導(dǎo)節(jié)點(diǎn)（與slave1一起）以冗余地收集度量（并向gmetad宣布）
- 在所有從屬節(jié)點(diǎn)上運(yùn)行updategmond.conf并定義其他udp_send_channel部分以將度量標(biāo)準(zhǔn)發(fā)送到slave2（端口8649）
- 在slave2上的updategmond.conf上定義udp_recv_channel（端口8649）以偵聽(tīng)傳入的度量，并在tcp_accept_channel（端口8649）上宣布它們（在slave1的gmond.conf中已經(jīng)設(shè)置了相同的設(shè)置）
- 在從屬節(jié)點(diǎn)上運(yùn)行的Hadoop和HBase守護(hù)程序的updatehadoop-metrics.properties文件，以將其度量標(biāo)準(zhǔn)同時(shí)發(fā)送到slave1和slave2，例如：
- 最終updatedata_source“ hadoop-slaves” ingmetad.conf從兩個(gè)冗余gmond s輪詢數(shù)據(jù)（如果gmetad無(wú)法從slave1.node.IP.address提取數(shù)據(jù)，它將繼續(xù)嘗試slave2.node.IP.address）：
也許下面的圖片不是很幸運(yùn)（有很多箭頭），但是它的意思是，如果slave1發(fā)生故障，那么gmetad將能夠從slave2節(jié)點(diǎn)上的gmond獲取指標(biāo)（因?yàn)樗袕墓?jié)點(diǎn)都將指標(biāo)冗余地發(fā)送給在slave1上運(yùn)行的gmond s和slave2）。
避免在主節(jié)點(diǎn)上使用Ganglia的SPoF
這里的主要思想是不要將gmetad（和Web前端）與Hadoop主守護(hù)程序并置，這樣，如果主節(jié)點(diǎn)發(fā)生故障（或根本變得不可用），我們就不會(huì)丟失監(jiān)視統(tǒng)計(jì)信息。 一個(gè)想法是，例如，將gmetad（和Web前端）從slave1移到slave3（或slave4），或者簡(jiǎn)單地引入一個(gè)在slave3（或slave4）上運(yùn)行的冗余gmetad。 前者的想法似乎還可以，而后者則使如此小的集群變得非常復(fù)雜。 我想，更好的主意是引入一個(gè)額外的節(jié)點(diǎn)（如果可能，稱為“邊緣”節(jié)點(diǎn)），該節(jié)點(diǎn)運(yùn)行g(shù)metad和Web前端（它可能還安裝了基本的Hadoop和HBase軟件包，但不運(yùn)行任何Hadoop的守護(hù)程序-它僅充當(dāng)客戶端計(jì)算機(jī)，以啟動(dòng)MapReduce作業(yè)并訪問(wèn)HBase。 實(shí)際上，“邊緣”節(jié)點(diǎn)通常用于在用戶和群集之間提供接口（例如，它運(yùn)行Pig和Hive ， Oozie ）。
故障排除和提示可能會(huì)有所幫助
由于調(diào)試配置的各個(gè)方面是設(shè)置Ganglia的最長(zhǎng)部分，因此我在這里分享了一些技巧。 請(qǐng)注意，本文并不涵蓋所有可能的故障排除，而是基于我們遇到并最終設(shè)法解決的問(wèn)題。
從小開(kāi)始
盡管Ganglia的過(guò)程配置不是那么復(fù)雜，但是最好僅從兩個(gè)節(jié)點(diǎn)開(kāi)始，如果可行，將其擴(kuò)展到更大的集群。 但是之前，您要安裝任何Ganglia的守護(hù)程序…
嘗試將“ Hello”從node1發(fā)送到node2
確保可以使用UDP協(xié)議與給定目標(biāo)主機(jī)上的端口8649進(jìn)行通信。 netcat是一個(gè)簡(jiǎn)單的工具，可以幫助您進(jìn)行驗(yàn)證。 打開(kāi)節(jié)點(diǎn)1（稍后稱為“引導(dǎo)節(jié)點(diǎn)”）上的端口8649以進(jìn)行入站UDP連接，然后從節(jié)點(diǎn)2向其發(fā)送一些文本。
# 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如果不起作用，請(qǐng)仔細(xì)檢查您的iptables規(guī)則（如果使用IPv6，則為iptables或ip6tables）是否為UDP和TCP連接打開(kāi)了端口8649。
讓gmond將數(shù)據(jù)發(fā)送到另一個(gè)gmond
在兩個(gè)節(jié)點(diǎn)上安裝gmond，并驗(yàn)證一個(gè)節(jié)點(diǎn)是否可以使用端口8649上的UDP連接將其度量標(biāo)準(zhǔn)發(fā)送到另一個(gè)節(jié)點(diǎn)。您可以在gmond.conf文件中為兩個(gè)節(jié)點(diǎn)使用以下設(shè)置：
cluster {name = 'hadoop-slaves' } udp_send_channel {host = the.lead.node.IP.addressport = 8649 } udp_recv_channel {port = 8649 } tcp_accept_channel {}運(yùn)行完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要查看是否實(shí)際有任何數(shù)據(jù)發(fā)送到引導(dǎo)節(jié)點(diǎn)，請(qǐng)使用tcpdump轉(zhuǎn)儲(chǔ)端口8649上的網(wǎng)絡(luò)流量：
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使用調(diào)試選項(xiàng)
tcpdump顯示某些數(shù)據(jù)已傳輸，但沒(méi)有告訴您發(fā)送哪種數(shù)據(jù)。 希望在調(diào)試模式下運(yùn)行g(shù)mond或gmetad可以為我們提供更多信息（由于它不能在調(diào)試模式下作為守護(hù)程序運(yùn)行，因此只需使用Ctrl + C即可停止運(yùn)行）
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我們看到收集了各種指標(biāo)并將其發(fā)送到host = hadoop-slave1.IP.address port = 8649。 不幸的是，它只能告訴您您是通過(guò)UDP發(fā)送的，因此無(wú)法成功傳遞它們。
不要混合使用IPv4和IPv6
讓我們看一下集群中遇到的實(shí)際情況（這是神秘而煩人的Ganglia錯(cuò)誤配置的根本原因）。 首先，查看lsof結(jié)果。
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將度量發(fā)送到右側(cè)端口上的hadoop-slave1，并且hadoop-slave1也將在右側(cè)端口上偵聽(tīng)。 除了一個(gè)重要的細(xì)節(jié)外，所有內(nèi)容都與上一節(jié)中的代碼片段幾乎相同– hadoop-slave2通過(guò)IPv6發(fā)送，而hadoop-slave1通過(guò)IPv4讀取！ 最初的猜測(cè)是更新ip6tables（除iptables之外）規(guī)則以打開(kāi)端口8649，以通過(guò)IPv6進(jìn)行UDP和TCP連接。 但這沒(méi)有用。 當(dāng)我們?cè)趃mond.conf文件中將主機(jī)名“ hadoop-slave1.vls”更改為其IP地址時(shí)，它就起作用了（是的，我之前在每個(gè)文件中都使用主機(jī)名而不是IP地址）。 確保將您的IP地址正確解析為主機(jī)名，反之亦然。
使用gstat獲取集群摘要
如果您設(shè)法將發(fā)送指標(biāo)從slave2發(fā)送到slave1，則表明您的集群正在運(yùn)行。 在Ganglia的術(shù)語(yǔ)中，群集是一組主機(jī)，它們?cè)趃mond.conf文件中共享相同的群集名稱屬性，例如“ hadoop-slaves”。 Ganglia提供了一個(gè)有用的名為gstat的功能，它可以打印由在給定節(jié)點(diǎn)上運(yùn)行的gmond表示的主機(jī)列表。
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從哪里輪詢指標(biāo)
在運(yùn)行g(shù)metad的主機(jī)上運(yùn)行以下命令，以檢查其輪詢度量標(biāo)準(zhǔn)的主機(jī)和主機(jī)（以某種方式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'>備擇方案
由于監(jiān)視群集是一個(gè)非常廣泛的主題，因此有許多工具可以幫助您完成此任務(wù)。 對(duì)于Hadoop集群，除了Ganglia之外，您還可以找到許多其他有趣的替代方案。 我只想簡(jiǎn)短地提到其中的幾個(gè)。
Cloudera Manager 4（企業(yè)）
除了極大地簡(jiǎn)化Hadoop集群的安裝和配置過(guò)程外，Cloudera Manager還提供了一些有用的功能來(lái)監(jiān)視和可視化Hadoop的數(shù)十種服務(wù)性能指標(biāo)以及與主機(jī)相關(guān)的信息，包括CPU，內(nèi)存，磁盤(pán)使用率和網(wǎng)絡(luò)I / O。 此外，它會(huì)在您接近關(guān)鍵閾值時(shí)向您發(fā)出警報(bào)（Ganglia本身不提供警報(bào)，但可以與Nagios和Hyperic等警報(bào)系統(tǒng)集成）。 您可以在此處了解有關(guān)Cloudera Manager關(guān)鍵功能的更多信息。
仙人掌，Zabbix，Nagios，Hyperic
請(qǐng)?jiān)L問(wèn)仙人掌網(wǎng)站以了解有關(guān)此工具的更多信息。 這也是有關(guān)使用Cacti進(jìn)行Hadoop Graphing的非常有趣的博客文章。 Zabbix ， Nagios和Hyperic是您可能還需要研究的工具。
致謝
我要非常感謝我的同事Pawel Tecza和Artur Czeczko，他們幫助我在集群上配置和調(diào)試了Ganglia。
參考： 針對(duì)小型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小型集群
總結(jié)
以上是生活随笔為你收集整理的hadoop小型集群_小型Hadoop集群的Ganglia配置和一些故障排除的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： maven 父maven_Maven的春
- 下一篇： 使用Spock Mocks进行Grail