雲計算平臺管理的三大利器Nagios、Ganglia和Splunk

綜合利用Nagios、Ganglia和Splunk搭建起的雲計算平臺監控體系，具有錯誤報警、性能調優、問題追蹤和自動生成運維報表的功能。實現這套監控體系系統，可輕鬆管理Hadoop/HBase雲計算平臺。

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

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

朋友們，當咱們管理起公司寄予厚望的雲計算平臺時，當咱們面對如此多充滿挑戰的實際問題時，該怎麼辦？

概述

咱們在搭建趨勢雲計算平臺時，遇到了不少的問題和挑戰。開始搭建時，第一次來了那麼多性能強勁的機器，咱們在感到興奮的同時，也難免有些顧慮。你們坐在一塊兒討論，問題就列了滿滿一白板。

• 出了問題怎麼辦，有沒有預警機制？
• 有沒有可視化的管理界面？
• 管理平臺須要本身開發嗎？開發難度有多大？
• 有沒有開源的管理工具？
• 那麼多日誌分佈在各個機器上，有沒有更有效的方法管理？
• 可否生成好的報表？
• 機器宕機，管理員可否收到短信通知？
• 如何作性能調優？
• 擴容升級時，可否給出依據？

帶着這些問題，咱們開始了本身的雲計算平臺管理和運營之旅，一路走來，收穫頗豐。如今基本上造成了如圖1所示的一整套雲計算平臺監控體系。

圖1 雲計算平臺監控架構

在這個系統中，咱們綜合利用了Nagios、Ganglia和Splunk，搭建起雲計算平臺監控體系，使其具有錯誤報警、性能調優、問題追蹤和自動生成運維報表的功能。有了這套系統，咱們終於可以輕鬆管理Hadoop/HBase雲計算平臺了。接下來將簡單介紹它們的特色和功能。

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

總不能每天盯着機器看吧，所以咱們首先關心的是機器的監控與報警。最理想的境界是：若是機器出故障了，我能第一時間處理；若是機器沒有問題（最好永遠沒有問題），我能去喝茶、釣魚和睡大覺。

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

有，你能夠用Nagios。

Nagios是一個可運行在Linux/Unix平臺之上的開源監視系統，能夠用來監視系統運行狀態和網絡信息。Nagios能夠監視所指定的本地或遠程主機以及服務，同時提供異常通知功能。

Nagios能夠提供如下幾種監控功能。

• 監控網絡服務（SMTP、POP三、HTTP、NNTP、Ping等）。
• 監控主機資源（處理器負荷、磁盤利用率等）。
• 簡單的插件設計使得用戶能夠方便地擴展本身服務的檢測方法。
• 並行服務檢查機制。
• 具有定義網絡分層結構的能力，並使用「parent」主機定義來表達網絡主機間的關係，這種關係可被用來發現和明晰主機宕機或不可達狀態。
• 當服務或主機問題產生與解決時將告警發送給聯繫人（經過電子郵件、短信、用戶定義方式）。
• 具有定義事件處理功能，能夠在主機或服務的事件發生時獲取更多問題定位。
• 自動的日誌回滾。
• 能夠支持並實現對主機的冗餘監控。
• 可選的Web界面用於查看當前的網絡狀態、通知和故障歷史、日誌文件等。

Nagios最好用的地方就是它將這些天天管理員作的工做自動化，你只需設定好要監聽的端口便可，它會默默地工做，幫忙定時地去檢測服務端口的狀態，一旦發現問題，會及時發出報警。報警能夠是電子郵件也能夠是手機，從而使得管理員第一時間就能收到系統的情況。

Nagios的報表功能也很強大。管理員能夠很容易地獲得天天、每週和每個月的Service運行情況。

圖2 SPN 後臺運行的全部Service的當前狀態

 

如圖2所示，紅色部分清楚地標註有問題的機器，點開連接，就能夠獲得有問題機器的狀況。雖然在HBase中，幾臺Region Server宕機不會對總體服務產生大的影響，但多少會影響到系統的Performance。並且，若是某幾臺Region Server頻繁宕機，對整個系統的穩定性也會產生很差的影響。有了Nagios，咱們能夠快速定位有問題的機器，及時地將一些機器移除出HBase系統，待調整好了再上線運行，以保證系統的穩定性。

如今，Nagios已經成爲了不少公司必備的監控工具。只須要簡單地配置，就能夠實現強大的功能，將管理員從平常煩瑣的工做中解放出來。

有了Nagios，哪怕就是管理上千臺機器，也不會手忙腳亂，而是有一種統領千軍、指揮若定的感受。

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

Nagios的確不錯，但你是否是真的能夠喝茶、釣魚、睡大覺呢？顯然還不行。有了Nagios，你基本上能夠作個優秀的救火隊員，能在事發第一時間到達現場、處理事故。但如何防患於未然，真正作到指揮若定、遊刃有餘呢？

咱們須要更加精確的數據，可以看到雲計算平臺的方方面面，能根據這些數據，作出性能調整、升級、擴容等的決策，從而保證Service可以知足不斷增加的業務需求。

這時候，你須要Ganglia。

Ganglia是UC Berkeley發起的一個開源實時監視項目，用於測量數以千計的節點，爲雲計算系統提供系統靜態數據以及重要的性能度量數據。Ganglia系統基本包含如下三大部分。

Gmond：Gmond運行在每臺計算機上，它主要監控每臺機器上收集和發送度量數據（如處理器速度、內存使用量等）。

Gmetad：Gmetad運行在Cluster的一臺主機上，做爲Web Server，或者用於與Web Server進行溝通。

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

Hadoop和HBase自己對於Ganglia的支持很是好。經過簡單的配置，咱們能夠將Hadoop和HBase的一些關鍵參數以圖表的形式展示在Ganglia的Web Console上。這些對於咱們洞悉Hadoop和HBase的內部系統狀態有很大的幫助。

在Hadoop的conf文件夾下面，找到hadoop-metrics.properties，配置好Ganglia的Server便可。這裏要注意，Ganglia 3.0和Ganglia 3.1的區別，它們使用了不一樣的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任什麼時候刻的狀況，都會一目瞭然。因爲圖標的跨度能夠是小時、天、月甚至是年，這樣，就能夠很是方便地按期生成周報、月報和年報。同時，根據圖中Metrics的情況，咱們能夠經過調整參數、增長內存和硬盤、增長機器等的方法調整單個機器或者整個Service的性能。

圖3 Hadoop其中一個DataNode的Metrics

 

Nagios 最大的問題在於不能洞悉到Service內部的情況。像Hadoop、HBase這樣的分佈式系統，一個節點的故障並不等於整個Service的故障，影響的只是Service的性能。因此，在測定Service的SLA時，咱們不能以某一臺機器的故障做爲Service故障的評判標準。好比在咱們的HBase SLA的設定上，咱們定義了HBase Service徹底不能工做的評判標準以下。

• Master Server 聯繫不上。
• 全部RegionServer 都沒法聯繫上。
• -ROOT- 表沒法訪問。
• .META. 表沒法訪問。

   

  圖4 Ganglia對Hadoop/HBase使用狀況的監測

那麼，咱們就能夠根據這個規則定義SLA，經過按期調用HBaseAdmin相應API ，將測試的結果發給Ganglia。採用一樣的方法，咱們還能夠自定義一些規則，監視HBase Master、Zookeeper等的狀況。

經過這些方法，咱們徹底可以針對Hadoop/HBase使用的實際狀況，作出Service級別而不是機器級別的監控系統並生成報表。

此外，Ganglia還能夠經過Server反饋回來的Load信息，給出各個機器的Load狀況，給咱們作升級和擴容提供依據。

如圖5所示，Ganglia分別會用不一樣顏色，標註出當前時刻的機器Load分佈狀況。若是Load太重，就應該檢查機器的具體使用狀況。

圖5 HBase Cluster Load Metrics

Ganglia的安裝配置，能夠參考：http://www.spnguru.com/?p=604。

Splunk：像查Google同樣查日誌

有了Nagios和Ganglia，算是成功了一大半。做爲一名優秀的管理員，咱們須要具有必定的Troubleshooting能力，對一些常見的問題能給出解決方案。那麼，對日誌的分析就必不可少。

但Hadoop/HBase的日誌分佈在各個機器上面，而日誌之間關聯性強。Client端的錯誤有多是Region Server引發，而Region Server的錯誤有多是Zookeeper致使。有沒有一個統一的日誌管理平臺呢？

衆裏尋它千百度，驀然回首，咱們找到了Splunk——日誌界的Google。

很遺憾，Splunk不是開源的，但它的免費版本提供天天500MB日誌索引。若是數據量較小，經過定義好Log的級別，基本上也能知足需求。但對於數據量較大的公司，就有些捉襟見肘。

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

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

 

對Hadoop和HBase有了進一步瞭解後，咱們能夠利用Splunk實時檢測日誌中的關鍵字，定義關鍵字規則，如監控「shutdown」、「quit」、「ERROR」、「Zookeeper Session Expired」等，一旦出現，利用Splunk的Notification功能，發出郵件通知管理員，管理員經過Splunk定位問題，就能夠在系統真正出現問題以前，對系統進行調整，防患於未然。

具體Splunk的設置，能夠參考：http://www.spnguru.com/?p=122。

總結

搭建一套雲計算平臺，強大的監控管理系統是必不可少的。固然，任何工具都不是萬能的，在實際維護過程當中，咱們也發現，Nagios和Splunk常常出現誤報，若是規則定義得很差，大量的警報郵件如潮水同樣涌來，反而掩蓋了真正的問題。能夠說，在雲計算平臺的運維管理上，沒有一勞永逸的事情，隨着規模的不斷增大和應用的不斷多樣化，須要你們不斷地實踐和總結。