綜合利用Nagios、Ganglia和Splunk搭建起的云計算平臺監(jiān)控體系，具備錯誤報警、性能調(diào)優(yōu)、問題追蹤和自動生成運維報表的功能。有了這套系統(tǒng)，就可輕松管理Hadoop/HBase云計算平臺。

云計算早已不是停留在概念階段了，各大公司都購買了大量的機器，開始正式的部署和運營。而動輒上百臺的性能強勁的服務(wù)器，為運營管理帶來了巨大的挑戰(zhàn)。

• 如果沒有方便的監(jiān)控報警平臺，對于管理員而言猶如噩夢，每天都將如救火隊員一樣，飛快地敲擊鍵盤，用原始的Unix命令在多臺機器中疲于奔命。
• 如果沒有好的日志管理平臺，對于開發(fā)者Troubleshooting更是一件淚流滿面的事情。
• 而如果你是運維團隊的總負責(zé)人，簡潔清晰的Report則非常重要。Stakeholder們動不動就可能問起系統(tǒng)的SLA、機器的利用率等諸多問題，畢竟，公司為此投入了巨大的資金和人力。

朋友們，當(dāng)我們管理起公司寄予厚望的云計算平臺時，當(dāng)我們面對如此多充滿挑戰(zhàn)的實際問題時，該怎么辦？

概述

我們在搭建趨勢云計算平臺時，遇到了很多的問題和挑戰(zhàn)。開始搭建時，***次來了那么多性能強勁的機器，我們在感到興奮的同時，也不免有些顧慮。大家坐在一起討論，問題就列了滿滿一白板。

• 出了問題怎么辦，有沒有預(yù)警機制？
• 有沒有可視化的管理界面？
• 管理平臺需要自己開發(fā)嗎？開發(fā)難度有多大？
• 有沒有開源的管理工具？
• 那么多日志分布在各個機器上，有沒有更有效的方法管理？
• 能否生成好的報表？
• 機器宕機，管理員能否收到短信通知？
• 如何做性能調(diào)優(yōu)？
• 擴容升級時，能否給出依據(jù)？

帶著這些問題，我們開始了自己的云計算平臺管理和運營之旅，一路走來，收獲頗豐。現(xiàn)在基本上形成了如圖1所示的一整套云計算平臺監(jiān)控體系。

圖1 云計算平臺監(jiān)控架構(gòu)

在這個系統(tǒng)中，我們綜合利用了Nagios、Ganglia和Splunk，搭建起云計算平臺監(jiān)控體系，使其具備錯誤報警、性能調(diào)優(yōu)、問題追蹤和自動生成運維報表的功能。有了這套系統(tǒng)，我們終于能夠輕松管理Hadoop/HBase云計算平臺了。接下來將簡單介紹它們的特點和功能。#p#

Nagios：云計算平臺的智能報警器

總不能天天盯著機器看吧，因此我們首先關(guān)心的是機器的監(jiān)控與報警。最理想的境界是：如果機器出故障了，我能***時間處理；如果機器沒有問題（***永遠沒有問題），我能去喝茶、釣魚和睡大覺。

發(fā)現(xiàn)機器有沒有問題，對我們而言不是什么難事。寫個腳本，Ping一下IP，Telnet每臺機器的Service端口，如果增加了新機器就改改配置即可。但這樣也太原始了吧，可視化效果差，不好維護，沒有層次，不好管理，出不來報表，總不能老是用Excel人工寫報表吧。有沒有更好的方法呢？

有，你可以用Nagios。

Nagios是一個可運行在Linux/Unix平臺之上的開源監(jiān)視系統(tǒng)，可以用來監(jiān)視系統(tǒng)運行狀態(tài)和網(wǎng)絡(luò)信息。Nagios可以監(jiān)視所指定的本地或遠程主機以及服務(wù)，同時提供異常通知功能。

Nagios可以提供以下幾種監(jiān)控功能。

• 監(jiān)控網(wǎng)絡(luò)服務(wù)（SMTP、POP3、HTTP、NNTP、Ping等）。
• 監(jiān)控主機資源（處理器負荷、磁盤利用率等）。
• 簡單的插件設(shè)計使得用戶可以方便地擴展自己服務(wù)的檢測方法。
• 并行服務(wù)檢查機制。
• 具備定義網(wǎng)絡(luò)分層結(jié)構(gòu)的能力，并使用“parent”主機定義來表達網(wǎng)絡(luò)主機間的關(guān)系，這種關(guān)系可被用來發(fā)現(xiàn)和明晰主機宕機或不可達狀態(tài)。
• 當(dāng)服務(wù)或主機問題產(chǎn)生與解決時將告警發(fā)送給聯(lián)系人（通過電子郵件、短信、用戶定義方式）。
• 具備定義事件處理功能，可以在主機或服務(wù)的事件發(fā)生時獲取更多問題定位。
• 自動的日志回滾。
• 可以支持并實現(xiàn)對主機的冗余監(jiān)控。
• 可選的Web界面用于查看當(dāng)前的網(wǎng)絡(luò)狀態(tài)、通知和故障歷史、日志文件等。

Nagios***用的地方就是它將這些每天管理員做的工作自動化，你只需設(shè)定好要監(jiān)聽的端口即可，它會默默地工作，幫忙定時地去檢測服務(wù)端口的狀態(tài)，一旦發(fā)現(xiàn)問題，會及時發(fā)出報警。報警可以是電子郵件也可以是手機，從而使得管理員***時間就能收到系統(tǒng)的狀況。

Nagios的報表功能也很強大。管理員可以很容易地得到每天、每周和每月的Service運行狀況。

圖2 SPN 后臺運行的所有Service的當(dāng)前狀態(tài)

如圖2所示，紅色部分清楚地標(biāo)注有問題的機器，點開鏈接，就可以得到有問題機器的情況。雖然在HBase中，幾臺Region Server宕機不會對整體服務(wù)產(chǎn)生大的影響，但多少會影響到系統(tǒng)的Performance。而且，如果某幾臺Region Server頻繁宕機，對整個系統(tǒng)的穩(wěn)定性也會產(chǎn)生不好的影響。有了Nagios，我們可以快速定位有問題的機器，及時地將一些機器移除出HBase系統(tǒng)，待調(diào)整好了再上線運行，以保證系統(tǒng)的穩(wěn)定性。

現(xiàn)在，Nagios已經(jīng)成為了很多公司必備的監(jiān)控工具。只需要簡單地配置，就可以實現(xiàn)強大的功能，將管理員從日常煩瑣的工作中解放出來。

有了Nagios，哪怕就是管理上千臺機器，也不會手忙腳亂，而是有一種統(tǒng)領(lǐng)千軍、運籌帷幄的感覺。#p#

Ganglia：看到云計算平臺的方方面面

Nagios的確不錯，但你是不是真的可以喝茶、釣魚、睡大覺呢？顯然還不行。有了Nagios，你基本上可以做個優(yōu)秀的救火隊員，能在事發(fā)***時間到達現(xiàn)場、處理事故。但如何防患于未然，真正做到運籌帷幄、游刃有余呢？

我們需要更加精確的數(shù)據(jù)，能夠看到云計算平臺的方方面面，能根據(jù)這些數(shù)據(jù)，做出性能調(diào)整、升級、擴容等的決策，從而保證Service能夠滿足不斷增長的業(yè)務(wù)需求。

這時候，你需要Ganglia。

Ganglia是UC Berkeley發(fā)起的一個開源實時監(jiān)視項目，用于測量數(shù)以千計的節(jié)點，為云計算系統(tǒng)提供系統(tǒng)靜態(tài)數(shù)據(jù)以及重要的性能度量數(shù)據(jù)。Ganglia系統(tǒng)基本包含以下三大部分。

Gmond：Gmond運行在每臺計算機上，它主要監(jiān)控每臺機器上收集和發(fā)送度量數(shù)據(jù)（如處理器速度、內(nèi)存使用量等）。

Gmetad：Gmetad運行在Cluster的一臺主機上，作為Web Server，或者用于與Web Server進行溝通。

Ganglia Web前端：Web前端用于顯示Ganglia的Metrics圖表。

Hadoop和HBase本身對于Ganglia的支持非常好。通過簡單的配置，我們可以將Hadoop和HBase的一些關(guān)鍵參數(shù)以圖表的形式展現(xiàn)在Ganglia的Web Console上。這些對于我們洞悉Hadoop和HBase的內(nèi)部系統(tǒng)狀態(tài)有很大的幫助。

在Hadoop的conf文件夾下面，找到hadoop-metrics.properties，配置好Ganglia的Server即可。這里要注意，Ganglia 3.0和Ganglia 3.1的區(qū)別，它們使用了不同的class。

dfs.class=org.apache.hadoop.metrics.ganglia.GangliaContext31 
dfs.period=10 
dfs.servers={Ganglia_Server}:8649 

有了這些圖表，Hadoop和HBase就不再是一個黑盒。無論是Hadoop的Namenode、Datanode，還是HBase的MasterServer、RegionServer任何時刻的情況，都會一目了然。由于圖標(biāo)的跨度可以是小時、天、月甚至是年，這樣，就可以非常方便地定期生成周報、月報和年報。同時，根據(jù)圖中Metrics的狀況，我們可以通過調(diào)整參數(shù)、增加內(nèi)存和硬盤、增加機器等的方法調(diào)整單個機器或者整個Service的性能。

圖3 Hadoop其中一個DataNode的Metrics

Nagios ***的問題在于不能洞悉到Service內(nèi)部的狀況。像Hadoop、HBase這樣的分布式系統(tǒng)，一個節(jié)點的故障并不等于整個Service的故障，影響的只是Service的性能。所以，在測定Service的SLA時，我們不能以某一臺機器的故障作為Service故障的評判標(biāo)準(zhǔn)。比如在我們的HBase SLA的設(shè)定上，我們定義了HBase Service完全不能工作的評判標(biāo)準(zhǔn)如下。

• Master Server 聯(lián)系不上。
• 所有RegionServer 都無法聯(lián)系上。
• -ROOT- 表無法訪問。
• .META. 表無法訪問。

  

  圖4 Ganglia對Hadoop/HBase使用情況的監(jiān)測

   

那么，我們就可以根據(jù)這個規(guī)則定義SLA，通過定期調(diào)用HBaseAdmin相應(yīng)API ，將測試的結(jié)果發(fā)給Ganglia。采用同樣的方法，我們還可以自定義一些規(guī)則，監(jiān)視HBase Master、Zookeeper等的情況。

通過這些方法，我們完全能夠針對Hadoop/HBase使用的實際情況，做出Service級別而不是機器級別的監(jiān)控系統(tǒng)并生成報表。

此外，Ganglia還可以通過Server反饋回來的Load信息，給出各個機器的Load情況，給我們做升級和擴容提供依據(jù)。

如圖5所示，Ganglia分別會用不同顏色，標(biāo)注出當(dāng)前時刻的機器Load分布情況。如果Load過重，就應(yīng)該檢查機器的具體使用情況。

圖5 HBase Cluster Load Metrics

Ganglia的安裝配置，可以參考這里。#p#

Splunk：像查Google一樣查日志

有了Nagios和Ganglia，算是成功了一大半。作為一名優(yōu)秀的管理員，我們需要具備一定的Troubleshooting能力，對一些常見的問題能給出解決方案。那么，對日志的分析就必不可少。

但Hadoop/HBase的日志分布在各個機器上面，而日志之間關(guān)聯(lián)性強。Client端的錯誤有可能是Region Server引起，而Region Server的錯誤有可能是Zookeeper導(dǎo)致。有沒有一個統(tǒng)一的日志管理平臺呢？

眾里尋它千百度，驀然回首，我們找到了Splunk——日志界的Google。

很遺憾，Splunk不是開源的，但它的免費版本提供每天500MB日志索引。如果數(shù)據(jù)量較小，通過定義好Log的級別，基本上也能滿足需求。但對于數(shù)據(jù)量較大的公司，就有些捉襟見肘。

Splunk支持AdHoc的日志搜索，而且可以與Nagios配合使用。比如Nagios報警某臺RegionServer端口不可達，我們收到Notification后，登錄Splunk，直接搜索shutdown和host名稱，找到RegionServer退出的日志。點擊詳細信息，分析日志，就能快速定位問題。如圖6所示。

圖6 Splunk與Nagios配合使用進行日志搜索

對Hadoop和HBase有了進一步了解后，我們可以利用Splunk實時檢測日志中的關(guān)鍵字，定義關(guān)鍵字規(guī)則，如監(jiān)控“shutdown”、“quit”、“ERROR”、“Zookeeper Session Expired”等，一旦出現(xiàn)，利用Splunk的Notification功能，發(fā)出郵件通知管理員，管理員通過Splunk定位問題，就可以在系統(tǒng)真正出現(xiàn)問題之前，對系統(tǒng)進行調(diào)整，防患于未然。

具體Splunk的設(shè)置，可以參考這里。

總結(jié)

搭建一套云計算平臺，強大的監(jiān)控管理系統(tǒng)是必不可少的。當(dāng)然，任何工具都不是***的，在實際維護過程中，我們也發(fā)現(xiàn)，Nagios和Splunk經(jīng)常出現(xiàn)誤報，如果規(guī)則定義得不好，大量的警報郵件如潮水一樣涌來，反而掩蓋了真正的問題。可以說，在云計算平臺的運維管理上，沒有一勞永逸的事情，隨著規(guī)模的不斷增大和應(yīng)用的不斷多樣化，需要大家不斷地實踐和總結(jié)。

【作者簡介】作者楊俊華，趨勢科技研發(fā)中心資深開發(fā)工程師，2009年至今一直從事Hadoop和HBase開發(fā)和運維工作，關(guān)注Hadoop開源社區(qū)的發(fā)展。