2         原理

Ganglia專案是由加州大學發起的，現在已經成為一個應用非常廣泛叢集監控軟體。可以監視和顯示叢集中的節點的各種狀態資訊，比如如：cpu 、mem、硬碟利用率， I/O負載、網路流量情況等，同時可以將歷史資料以曲線方式通過php頁面呈現。同時具有很好的擴充套件性，允許使用者加入自己所要監控的狀態資訊。

2.1      ganglia工作原理

                                                                              圖 1  Ganglia整體結構圖

Ganglia包括如下幾個程式，他們之間通過XDL(xml的壓縮格式)或者XML格式傳遞監控資料，達到監控效果。叢集內的節點，通過執行gmond收集釋出節點狀態資訊，然後gmetad週期性的輪詢gmond收集到的資訊，然後存入rrd資料庫，通過web伺服器可以對其進行查詢展示。

Gmetad 這個程式負責週期性的到各個datasource收集各個cluster的資料，並更新到rrd資料庫中。 可以把它理解為服務端。

Gmond 收集本機的監控資料，傳送到其他機器上，收集其他機器的監控資料，gmond之間通過udp通訊，傳遞檔案格式為xdl。收集的資料供Gmetad讀取，預設監聽埠8649 ，監聽到gmetad請求後傳送xml格式的檔案。可以把它理解為客戶端。

web front-end 一個基於web的監控介面，通常和Gmetad安裝在同一個節點上(還需確認是否可以不在一個節點上，因為php的配置檔案中ms可配置gmetad的地址及埠)，它從Gmetad取資料，並且讀取rrd資料庫，生成圖片，顯示出來。

 如上圖所示，gmetad週期性的去gmond節點或者gmetad節點poll資料。一個gmetad可以設定多個datasource，每個datasource可以有多個備份，一個失敗還可以去其他host取資料。

 如果是muticast模式的話，gmond之間還會通過多播來相互傳遞資料。Gmond本身具有udp send和recv通道，還有一個tcp recv通道。其中udp通道用於向其他gmond節點發送或接受資料，tcp則用來export xml檔案，主要接受來自gmetad的請求。Gmetad只有tcp通道，一方面他向datasource傳送請求，另一方面會使用一個tcp埠，釋出自身收集的xml檔案，預設使用8651埠。所以gmetad即可以從gmond也可以從其他的gmetad得到xml資料。

 Gmond節點內部模組圖如下所示：

                                                                         圖 2  Gmond節點模組結構圖

如上圖所示，主要由三個模組組成，collect and publish模組，該模組週期性的呼叫一些內部指令獲得metric data，然後將這些資料通過udp通道釋出給其他gmond節點。Listen Threads，監聽其他gmond節點的傳送的udp資料，然後將資料存放到記憶體中。XML export thread負責將資料以xml格式釋出出去，比如交給gmetad。

 下面重點介紹下unicast模式下ganglia系統內的資料流。

                                                            圖 3單播狀況下叢集節點間的資料流

如上圖所示，多個gmond節點通過udp向單播的目標host的gmond傳送資料，gmetad然後向該目標host的gmond請求xml檔案，然後存入rrdtool資料庫。 在unicast模式中，圖中方框內的元件通常是位於叢集內的同一個節點。該節點負責收集儲存 顯示被監控的各節點的狀態資訊。

2.2      自定義metrics

向ganglia加入自定義metric有兩種方法，一種是通過命令列的方式執行gmetric，另一種是通過ganglia提供的面向c和python的擴充套件模組，加入自定義的模組支援。

2.3      優點及可能存在的問題
2.3.1     優點

n  自動收集資料

叢集內各個節點的資訊收集可以通過ganglia系統自動的收集起來，這個收集是獨立進行地。其通訊效能都是經過良好設計和優化的。具體的機制是：週期性的將這些資訊傳送給gmond，這樣資訊就加入了ganglia監控系統。通過ganglia的監控機制完成監控資料的收集顯示的功能。Ganglia系統的機制可以參考2.1ganglia工作原理。

n  圖形介面

資料可以通過圖形顯示出來。通過登入web伺服器即可檢視。目前可以通過該檢視檢視叢集及單獨節點的狀態曲線。同時具有基本的排序機制，可以根據值降序或者升序排序。可以檢視過去1小時 1天 1周 1年等時間段的狀態曲線。

n  資料庫rrdtool儲存了歷史資料

由於採用了rrd儲存資料，這樣我們不單可以檢視當前的狀態，還可以檢視之前的狀態歷史，同時可以將metrics隨時間的變化以曲線的方式變現表現出來。而單獨的向檔案寫日誌很難儲存和方便地檢視之前的歷史記錄。而且有可能使得日誌檔案很大。RRDtool具有如下優點:

1）除了儲存資料之外，它具有可以建立圖形的工具；

2）它的資料庫檔案大小是固定的，新的資料新增到已有資料的後面，當到了檔案末尾的時候就開始從檔案開始寫資料，Round Robin就是指這個意思；

3）一般的資料庫只能儲存資料本身，而rrd可以儲存相對與以前的資料的變動

4）一般的資料庫是在提供資料的時候才更新，而RRD是在每一個預先設好的時間間隔都會更新，每次更新的時候，time stamp也會儲存進去

 
2.3.2     可能存在的問題及瓶頸

n  開銷估計：網路 IO CPU

只執行gmond程序的節點開銷很小，通常需要1m左右記憶體，cpu大概1%不到，同時gmond只把資料儲存在記憶體中，因此io開銷可以忽略。同時向其他節點單播本身的資訊本身的網路壓力也不會很大。因此對於只執行gmond的節點來說，開銷很小。 如果採用了unicast模式，主要的開銷就會在各節點的gmond程序向中央節點發送的udp資料帶來的網路開銷，此外gmond和gmetad的通訊，web服務也在該中央節點上進行。這樣主要的瓶頸就在中央節點上，其網路 IO CPU的壓力都會很大。

對於網路來說，中央節點將收到來自其他所有節點發送的udp包，如果一個節點每秒發10個包，500個節點將會發出5000個，每個包有200位元組，就有1m位元組，5000個包的處理所需要的cpu使用也會上升。 

對於記憶體來說每個狀態資訊儲存在記憶體大概要耗費300byte，如果一個job有10萬個instance，每個instance又有10個狀態需要監控，那麼將耗費10000*10*300=30m的記憶體，其對應的xml檔案大小也應該是10m級別的。

對於IO來說，Gmetad預設15秒向gmond取一次xml資料，如果gmond和gmetad都是在同一個節點，這樣就相當於本地io請求。同時gmetad請求完xml檔案後，還需要對其解析，也就是說按預設設定每15秒需要解析一個10m級別的xml檔案，這樣cpu的壓力就會很大。同時它還有寫入RRD資料庫，還要處理來自web客戶端的解析請求，也會讀RRD資料庫。這樣本身的IO CPU 網路壓力就很大，因此這個節點至少應該是個空閒的而且能力比較強的節點。

n  Gmetad RRD寫入瓶頸

需要格外注意的是gmetad守護程序使用RRDtool，會在/var/lib/ganglia/rrds/目錄下的一個子目錄儲存這些rrd資料資訊，如果叢集節點超過100個，你可能應將這個目錄放在RAM檔案系統上，因為這個資料庫的磁碟I/O將會非常高。由於RRD特有的儲存方式，它會為每個metric存放一個檔案，如果配置了多個取樣頻率，它還會為每個取樣頻率儲存一個單獨的檔案。這就意味著gmetad將metric的值儲存到rrd資料庫的操作，將是針對大量小檔案的IO，假設叢集有300個節點，每個節點有50個metric，那麼意味著gmetad會記錄15000個metric，如果這些metric都是一秒更新一次，那麼意味著每秒15000的隨機寫入操作，通常來說硬碟都是撐不住的。

一個可能的解決方法就是將叢集內的節點劃分為多個子集，為每個子集配置一箇中央收集節點。但這樣會帶來部署和結果檢視的不方便性。另外可以通過RRDcached來緩解這個gmetad使用RRDTool的問題大量隨機寫入，它會快取這些寫入，批量進行更新。此外就是降低metric的取樣頻率，減少metrics的數目，儘量減少這種寫入請求量。如果機器具有多塊磁碟，儘量利用多個磁碟來儲存RRD資料。還有就是使用上面我們所說的將rrd目錄載入為tmpfs。

n  使用的服務及埠以及依賴的庫

Ganglia的gmond程序使用了udp進行單播，預設埠8649，同時還有負責tcp監控的埠8651 8652 8650也會被使用，這些埠需要在叢集內部開啟，這些使用的埠可以進行配置。另外apache也需要一個埠提供服務，這個埠會被從外部訪問，預設是80。

n  同一個host的不同程序的相同Metirc可能混淆

由於ganglia本身是根據host+metric_name來區分不同的狀態引數的，也就是它無法區分同一host內的不同程序相同的名稱的狀態變數。但是對於單純的一個狀態量，雖然可能是多個程序的狀態，但對它來說只能看到一個名稱，所以當多個程序同時向它報告具有同一個名稱的狀態的value時，它無法區分出程序間的不同。如果要區分它們，就需要加入一個命名機制區分它們。

程式執行完畢，該程式對應的自定義的那些metric不會消失，這意味著雖然程式執行結束，但我們依然可以檢視其歷史記錄。但另一方面這樣也會帶來新的問題，由於我們採用的針對metric的命名機制，會導致metric積累到很多，這樣會導致xml變得越來越大，增加中央節點解析該檔案時的壓力，也不方面查閱。目前有一個可行的方法就是修改gmetad的配置檔案，減少資料的儲存時間的設定。

 
2.3.3     執行需要做的部署工作

基於ganglia的監控執行時，需要各個客戶端安裝gangliang的客戶端gmond。收集資料的那個節點還需要安裝ganglia的服務端gmetad，為了可以從web顯示結果，還需要安裝http伺服器。安裝這些還有很多依賴軟體。具體參見1環境安裝配置。

 
3         高階擴充套件

3.1      直接讀取xml檔案
 

除了使用ganglia內建的網頁頁面外，也可以自行得到xml檔案去進行自己的分析。通常需要自己編寫一個指令碼來完成該任務。通過直接telnet gmond或者gmetad的tcp服務監聽埠，可以直接得到xml檔案，然後我們就可以對該xml檔案進行需要的處理了。在單播模式下，應該telnet那個gmond的中央節點，登入該節點才能得到叢集內所有節點的資訊，否則只能得到單獨節點的資訊。

4         參考文獻

The ganglia distributed monitoring system-design  implementation

Wide Area Cluster Monitoring with Ganglia