Chukwa:開源分布式數據收集系統

jopen 10年前發布 | 44K 次閱讀 Chukwa 分布式/云計算/大數據

Chukwa 是一個開源的用于監控大型分布式系統的數據收集系統。它構建在 hadoop 的 hdfs 和 map/reduce 框架之上的，繼承了 hadoop 的可伸縮性和魯棒性。Chukwa 還包含了一個強大和靈活的工具集，可用于展示、監控和分析已收集的數據。

Chukwa不是什么？

Chukwa不是一個單機系統，在單個節點部署一個Chukwa 系統基本沒有什么用處，Chukwa是一個構建在hadoop基礎上的分布式日志處理系統。換言之在搭建Chukwa環境之前需要先構建一個hadoop 環境,然后在hadoop的基礎上構建Chukwa環境。

Chukwa 不是一個實時錯誤監控系統，在解決這個問題方面ganglia、nagios等等系統已經做得很好了，這些系統對數據的敏感性都可以達到秒級。 Chukwa分析的是數據是分鐘級別的,它認為像集群的整體 cpu 使用率這樣的數據延遲幾分鐘拿到不是什么問題。

Chukwa不是一個封閉的系統，雖然Chukwa自帶了許多針對hadoop集群的分析項，但是這并不是說它只能監控和分析hadoop。 Chukwa提供了一個對大數據量日志類數據采集、存儲、分析和展示的全套解決方案和框架，在這類數據生命周期的各個階段 Chukwa 都提供了近乎完美的解決方案。

Chukwa 是什么

Chukwa可以用于監控大規模(2000+ 以上的節點, 每天產生數據量在T級別) hadoop 集群的整體運行情況并對它們的日志進行分析。

對于集群的用戶而言:Chukwa展示他們的作業已經運行了多久，占用了多少資源，還有多少資源可用，一個作業是為什么失敗了，一個讀寫操作在哪個節點出了問題。

對于集群的運維工程師而言:Chukwa展示了集群中的硬件錯誤，集群的性能變化，集群的資源瓶頸在哪里。

對于集群的管理者而言:Chukwa展示了集群的資源消耗情況，集群的整體作業執行情況，可以用以輔助預算和集群資源協調。

對于集群的開發者而言:Chukwa展示了集群中主要的性能瓶頸，經常出現的錯誤，從而可以著力重點解決重要問題。

Chukwa的系統架構

Chukwa旨在為分布式數據收集和大數據處理提供一個靈活、強大的平臺，這個平臺不僅現時可用，而且能夠與時俱進的利用更新的存儲技術（比如 HDFS、HBase等），當這些存儲技術變得成熟時。為了保持這種靈活性，Chukwa被設計成收集和處理層級的管道線，在各個層級之間有非常明確和狹窄的界面，下圖為Chukwa架構示意圖：

Chukwa:開源分布式數據收集系統

Chukwa有以下5個主要組成部分：

agents : 負責采集最原始的數據,并發送給 collectors

adaptor : 直接采集數據的接口和工具,一個 agent 可以管理多個 adaptor 的數據采集

collectors 負責收集 agents 收送來的數據,并定時寫入集群中

map/reduce jobs 定時啟動,負責把集群中的數據分類、排序、去重和合并

HICC 負責數據的展示

相關設計

1、adaptors 和 agents

在每個數據的產生端(基本上是集群中每一個節點上), Chukwa 使用一個Agent來采集它感興趣的數據，每一類數據通過一個Adaptor來實現, 數據的類型(Data Model)在相應的配置中指定。默認Chukwa對以下常見的數據來源已經提供了相應的Adaptor：命令行輸出、log文件和http Sender等，這些Adaptor會定期運行(比如每分鐘讀一次df的結果)或事件驅動地執行(比如kernel打了一條錯誤日志)。如果這些 Adaptor 還不夠用，用戶也可以方便地自己實現一個Adaptor來滿足需求。為防止數據采集端的Agent出現故障Chukwa的Agent采用了所謂的 ‘watchdog’機制，會自動重啟終止的數據采集進程防止原始數據的丟失。另一方面，對于重復采集的數據,在Chukwa的數據處理過程中會自動對它們進行去重，這樣就可以對于關鍵的數據在多臺機器上部署相同的Agent從而實現容錯的功能。

2、collectors

agents采集到的數據是存儲到hadoop集群上的。hadoop集群擅長于處理少量大文件，而對于大量小文件的處理則不是它的強項，針對這一點Chukwa設計了collector這個角色，用于把數據先進行部分合并再寫入集群，防止大量小文件的寫入。另一方面，為防止collector成為性能瓶頸或成為單點產生故障， Chukwa允許和鼓勵設置多個collector。agents隨機地從collectors列表中選擇一個collector傳輸數據，如果一個 collector失敗或繁忙就換下一個collector，從而可以實現負載的均衡。實踐證明多個collector的負載幾乎是平均的。

3、demux 和 archive

放在集群上的數據是通過map/reduce作業來實現數據分析的。在map/reduce階段，Chukwa提供了demux和archive任務兩種內置的作業類型。demux作業負責對數據的分類、排序和去重，在agent中提到了數據類型(DataType)的概念，由collector寫入集群中的數據都有自己的類型，demux作業在執行過程中通過數據類型和配置文件中指定的數據處理類執行相應的數據分析工作，一般是把非結構化的數據結構化，抽取中其中的數據屬性。由于demux的本質是一個map/reduce作業，所以我們可以根據自己的需求制定自己的demux作業進行各種復雜的邏輯分析。Chukwa 提供的demux interface可以用java語言來方便地擴展。而archive作業則負責把同類型的數據文件合并，一方面保證了同一類的數據都在一起便于進一步分析, 另一方面減少文件數量減輕 hadoop 集群的存儲壓力。

4、dbadmin

放在集群上的數據雖然可以滿足數據的長期存儲和大數據量計算需求但是不便于展示，為此Chukwa做了兩方面的努力：

使用 mdl 語言把集群上的數據抽取到mysql數據庫中，對近一周的數據完整保存，超過一周的數據按數據離現在的時間長短作稀釋，離現在越久的數據所保存的數據時間間隔越長。通過mysql來作數據源展示數據。

使用hbase或類似的技術直接把索引化的數據在存儲在集群上。

到 Chukwa 0.4.0 版本為止, Chukwa 都是用的第一種方法，但是第二種方法更優雅也更方便一些。

5、hicc

hicc是Chukwa的數據展示端的名字，在展示端Chukwa提供了一些默認的數據展示widget，可以使用“列表”、“曲線圖”、“多曲線圖”、“柱狀圖”、“面積圖式展示一類或多類數據給用戶直觀的數據趨勢展示。而且，在 hicc 展示端對不斷生成的新數據和歷史數據采用 robin 策略防止數據的不斷增長增大服務器壓力并對數據在時間軸上“稀釋”可以提供長時間段的數據展示。從本質上hicc是用jetty來實現的一個web服務端，內部用的是jsp技術和javascript技術，各種需要展示的數據類型和頁面的局都可以通過簡直地拖拽方式來實現，更復雜的數據展示方式可以使用 sql語言組合出各種需要的數據。如果這樣還不能滿足需求動手修改它的jsp代碼就可以了

6、其它數據接口

如果對原始數據還有新的需要用戶還可以通過map/reduce作業或pig語言直接訪問集群上的原始數據以生成所需要的結果。Chukwa 還提供了命令行的接口，可以直接訪問到集群上數據。

7、默認數據支持

對于集群各節點的cpu使用率、內存使用率、硬盤使用率、集群整體的 cpu 平均使用率、集群整體的內存使用率、集群整體的存儲使用率、集群文件數變化、作業數變化等等hadoop相關數據，從采集到展示的一整套流程Chukwa 都提供了內建的支持，只需要配置一下就可以使用。可以看出，Chukwa從數據的產生、收集、存儲、分析到展示的整個生命周期都提供了全面的支持。

了解了主要部件后，也許有讀者已經在腦海中有了大致的數據流程圖了。是的，它就是這么簡單：數據被 Agent 收集，并傳送到 Collector，由 Collector 寫入 HDFS，然后由 Map-Reduce job 進行數據的預處理。

Chukwa:開源分布式數據收集系統

內部數據處理時序介紹

Chukwa:開源分布式數據收集系統

Collector將Agent發送的數據寫入到logs/*.Chukwa文件，直到文件大小達到64M或者達到一定的時間間隔之后，Collector會將*.Chukwa文件重命名為*.done文件表明文件寫入結束。

DemuxManager每隔20秒中檢查一次*.done文件，如果文件存在，則將文件移動到demuxProcessing/mrInput 文件夾下。而Demux MapReduce job將會以此文件夾為輸入進行map/reduce操作。如果此操作成功(可重試3次)則會將map/reduce的輸出結果從 demuxProcessing/mrOutput文件夾下歸檔并移動到dataSinkArchives/[yyyyMMdd]/*/*.done。同時會將文件輸出到postProcess目錄下。否則如果操作失敗，則會將輸出結果移動到dataSinkArchives/InError /[yyyyMMdd]/*/*.done。