apache 的開源項目 hadoop， 作為一個分布式存儲和計算系統，已經被業界廣泛應用。很多大型企業都有了各自基于 hadoop 的應用和相關擴充。當 1000+ 以上個節點的 hadoop 叢集變得常見時，叢集自身的相關資訊如何收集和分析呢？針對這個問題， apache 同樣提出了相應的解決方案，那就是 chukwa。
概述
chukwa 的官方網站是這樣描述自己的： chukwa 是一個開源的用于監控大型分布式系統的資料收集系統。這是建構在 hadoop 的 hdfs 和 map/reduce 架構之上的，繼承了 hadoop 的可伸縮性和魯棒性。chukwa 還包含了一個強大和靈活的工具集，可用于展示、監控和分析已收集的資料。
在一些網站上，甚至聲稱 chukwa 是一個“日志處理/分析的full stack solution”。
說了這麼多，你心動了嗎？
我們先來看看 chukwa 是什麼樣子的：
chukwa 不是什麼
1. chukwa 不是一個單機系統. 在單個節點部署一個 chukwa 系統,基本沒有什麼用處. chukwa 是一個建構在 hadoop 基礎上的分布式日志處理系統.換言之,在搭建 chukwa 環境之前,你需要先建構一個 hadoop 環境,然後在 hadoop 的基礎上建構 chukwa 環境,這個關系也可以從稍後的 chukwa 架構圖上看出來.這也是因為 chukwa 的假設是要處理的資料量是在 t 級别的.
2. chukwa 不是一個實時錯誤監控系統.在解決這個問題方面, ganglia,nagios 等等系統已經做得很好了,這些系統對資料的敏感性都可以達到秒級. chukwa 分析的是資料是分鐘級别的,它認為像叢集的整體 cpu 使用率這樣的資料,延遲幾分鐘拿到,不是什麼問題.
3. chukwa 不是一個封閉的系統.雖然 chukwa 自帶了許多針對 hadoop 叢集的分析項,但是這并不是說它隻能監控和分析 hadoop.chukwa 提供了一個對大資料量日志類資料采集、存儲、分析和展示的全套解決方案和架構,在這類資料生命周期的各個階段, chukwa 都提供了近乎完美的解決方案,這一點也可以從它的架構中看出來.
chukwa 是什麼
上一節說了很多 chukwa 不是什麼,下面來看下 chukwa 具體是幹什麼的一個系統呢?
具體而言, chukwa 緻力于以下幾個方面的工作:
1. 總體而言, chukwa 可以用于監控大規模(2000+ 以上的節點, 每天産生資料量在t級别) hadoop 叢集的整體運作情況并對它們的日志進行分析
2. 對于叢集的使用者而言: chukwa 展示他們的作業已經運作了多久,占用了多少資源,還有多少資源可用,一個作業是為什麼失敗了,一個讀寫操作在哪個節點出了問題.
3. 對于叢集的運維工程師而言: chukwa 展示了叢集中的硬體錯誤,叢集的性能變化,叢集的資源瓶頸在哪裡.
4. 對于叢集的管理者而言: chukwa 展示了叢集的資源消耗情況,叢集的整體作業執行情況,可以用以輔助預算和叢集資源協調.
5. 對于叢集的開發者而言: chukwa 展示了叢集中主要的性能瓶頸,經常出現的錯誤,進而可以着力重點解決重要問題.
基本架構
有了一個感性的認識後,我們來看下它的構架, chukwa 的整體結構圖是下面這個樣子的:
其中主要的部件為:
1. agents : 負責采集最原始的資料,并發送給 collectors
2. adaptor : 直接采集資料的接口和工具,一個 agent 可以管理多個 adaptor 的資料采集
3. collectors 負責收集 agents 收送來的資料,并定時寫入叢集中
4. map/reduce jobs 定時啟動,負責把叢集中的資料分類、排序、去重和合并
5. hicc 負責資料的展示
相關設計
adaptors 和 agents
在每個資料的産生端(基本上是叢集中每一個節點上), chukwa 使用一個 agent 來采集它感興趣的資料,每一類資料通過一個 adaptor 來實作, 資料的類型(datatype?)在相應的配置中指定. 預設地, chukwa 對以下常見的資料來源已經提供了相應的 adaptor ： 指令行輸出、log 檔案和 httpsender等等. 這些 adaptor 會定期運作(比如每分鐘讀一次 df 的結果)或事件驅動地執行(比如 kernel 打了一條錯誤日志). 如果這些 adaptor 還不夠用，使用者也可以友善地自己實作一個 adaptor 來滿足需求。
為防止資料采集端的 agent 出現故障，chukwa 的 agent 采用了所謂的 ‘watchdog’ 機制，會自動重新開機終止的資料采集程序，防止原始資料的丢失。
另一方面, 對于重複采集的資料, 在 chukwa 的資料處理過程中,會自動對它們進行去重. 這樣,就可以對于關鍵的資料在多台機器上部署相同的 agent,進而實作容錯的功能.
collectors
agents 采集到的資料,是存儲到 hadoop 叢集上的. hadoop 叢集擅長于處理少量大檔案，而對于大量小檔案的處理則不是它的強項，針對這一點，chukwa 設計了 collector 這個角色，用于把資料先進行部分合并，再寫入叢集，防止大量小檔案的寫入。
另一方面,為防止 collector 成為性能瓶頸或成為單點,産生故障, chukwa 允許和鼓勵設定多個 collector, agents 随機地從 collectors 清單中選擇一個 collector 傳輸資料,如果一個 collector 失敗或繁忙,就換下一個 collector. 進而可以實作負載的均衡,實踐證明,多個 collector 的負載幾乎是平均的.
demux 和 archive
放在叢集上的資料,是通過 map/reduce 作業來實作資料分析的. 在 map/reduce 階段， chukwa 提供了 demux 和 archive 任務兩種内置的作業類型.
demux 作業負責對資料的分類、排序和去重. 在 agent 一節中,我們提到了資料類型(datatype?)的概念.由 collector 寫入叢集中的資料,都有自己的類型. demux 作業在執行過程中,通過資料類型和配置檔案中指定的資料處理類,執行相應的資料分析工作,一般是把非結構化的資料結構化,抽取中其中的資料屬性.由于 demux 的本質是一個 map/reduce 作業,是以我們可以根據自己的需求制定自己的 demux 作業,進行各種複雜的邏輯分析. chukwa 提供的 demux interface 可以用 java 語言來友善地擴充.
而 archive 作業則負責把同類型的資料檔案合并，一方面保證了同一類的資料都在一起，便于進一步分析, 另一方面減少檔案數量, 減輕 hadoop 叢集的存儲壓力。
dbadmin
放在叢集上的資料,雖然可以滿足資料的長期存儲和大資料量計算需求,但是不便于展示.為此, chukwa 做了兩方面的努力:
1. 使用 mdl 語言,把叢集上的資料抽取到 mysql 資料庫中,對近一周的資料,完整儲存,超過一周的資料,按資料離現在的時間長短作稀釋,離現在越久的資料,所儲存的資料時間間隔越長.通過 mysql 來作資料源,展示資料.
2. 使用 hbase 或類似的技術,直接把索引化的資料在存儲在叢集上
到 chukwa 0.4.0 版本為止, chukwa 都是用的第一種方法,但是第二種方法更優雅也更友善一些.
hicc
hicc 是 chukwa 的資料展示端的名字.在展示端， chukwa 提供了一些預設的資料展示 widget，可以使用“清單”、“曲線圖”、“多曲線圖”、“柱狀圖”、“面積圖式展示一類或多類資料，給使用者直覺的資料趨勢展示。而且，在 hicc 展示端，對不斷生成的新資料和曆史資料，采用 robin 政策，防止資料的不斷增長增大伺服器壓力，并對資料在時間軸上“稀釋”，可以提供長時間段的資料展示
從本質上, hicc 是用 jetty 來實作的一個 web 服務端,内部用的是 jsp 技術和 javascript 技術.各種需要展示的資料類型和頁面的局都可以通過簡直地拖拽方式來實作,更複雜的資料展示方式,可以使用 sql 語言組合出各種需要的資料.如果這樣還不能滿足需求,不用怕,動手修改它的 jsp 代碼就可以了.
其它資料接口
如果對原始資料還有新的需要，使用者還可以通過 map/reduce 作業或 pig 語言直接通路叢集上的原始資料，以生成所需要的結果。chukwa 還提供了指令行的接口，可以直接通路到叢集上資料。
預設資料支援
對于叢集各節點的cpu使用率、記憶體使用率、硬碟使用率、叢集整體的 cpu 平均使用率、叢集整體的記憶體使用率、叢集整體的存儲使用率、叢集檔案數變化、作業數變化等等 hadoop 相關資料,從采集到展示的一整套流程, chukwa 都提供了内建的支援,隻需要配置一下就可以使用.可以說是相當友善的.
可以看出，chukwa 從資料的産生、收集、存儲、分析到展示的整個生命周期都提供了全面的支援。