chukwa是一個開源的用于監控大型分布式系統的數據收集系統。這是構建在Hadoop 的hdfs和map/reduce框架之上的，繼承了hadoop的可伸縮性和健壯性。
基本介紹
apache 的開源項目 hadoop，作為一個分布式存儲和計算系統，已經被業界廣泛應用。很多大型企業都有了各自基于 hadoop 的應用和相關擴展。當 1000+ 以上個節點的 hadoop 集群變得常見時，集群自身的相關信息如何收集和分析呢？針對這個問題， apache 同樣提出了相應的解決方案，那就是 chukwa。
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 或類似的技術，直接把索引化的數據在存儲在集群上
到chukwa0.4.0 版本為止,chukwa都是用的第一種方法，但是第二種方法更優雅也更方便一些.
hicc
hicc 是chukwa的數據展示端的名字。在展示端，chukwa提供了一些默認的數據展示 widget，可以使用“列表”、“曲線圖”、“多曲線圖”、“柱狀圖”、“面積圖式展示一類或多類數據，給用戶直觀的數據趨勢展示。而且，在 hicc 展示端，對不斷生成的新數據和歷史數據，采用 robin 策略，防止數據的不斷增長增大服務器壓力，并對數據在時間軸上“稀釋”，可以提供長時間段的數據展示
從 本質上, hicc 是用 jetty 來實現的一個 web 服務端，內部用的是 jsp 技術和 ECMAScript 技術。各種需要展示的數據類型和頁面的局都可以通過簡直地拖拽方式來實現，更復雜的數據展示方式，可以使用 sql 語言組合出各種需要的數據。如果這樣還不能滿足需求，不用怕，動手修改它的 jsp 代碼就可以了.
其它數據接口
如果對原始數據還有新的需要，用戶還可以通過 map/reduce 作業或 pig 語言直接訪問集群上的原始數據，以生成所需要的結果。chukwa還提供了命令行的接口，可以直接訪問到集群上數據。
默認數據支持
對 于集群各節點的cpu使用率、內存使用率、硬盤使用率、集群整體的 cpu 平均使用率、集群整體的內存使用率、集群整體的存儲使用率、集群文件數變化、作業數變化等等 Hadoop 相關數據，從采集到展示的一整套流程,chukwa都提供了內建的支持，只需要配置一下就可以使用。可以說是相當方便的.
可以看出，chukwa從數據的產生、收集、存儲、分析到展示的整個生命周期都提供了全面的支持。
參考資料 >