用云存儲實現對云計算的監控

　　引言

　　大凡集群系統的性能、壓力測試，都要通過監控系統進行收集整理。其中ganglia是集群監控最常用的工具之一。它與Hadoop生態圈結合的非常好，且性能優良，不會對系統本身性能造成影響。

　　Ganglia是UC Berkeley發起的一個開源集群監視項目，包含gmond、gmetad兩個服務，以及一個web展示前端。本身部署后就立即可以對cpu、memory、network、disk等情況進行監控匯總。gmond負責收集系統的這些監控指標數據，一般若干個節點會有一個master，負責從子節點上通過tcp協議抓取這些節點的xml格式的監控數據。若干master再向更上一層的master匯總，直到gmetad這一層會將所有數據保存到rrd數據庫中。這樣層層抓取進而匯總的模式，保證了節點性能不至于受到gmond監控的影響，且各級master也不會產生過多的網絡IO壓力。

　　RRDTool負責保存這些監控數據到RRD(Round RobinDatabase)文件中，RRD數據庫顧名思義是一個環裝的數據庫。越久遠的數據在這個數據庫中就會被不斷規整合并，點與點之間的時間差距越來越大，越來越稀疏，當時的細節也跟著逐漸丟失。這樣的數據庫對于存儲大規模集群的監控數據是非常有好處的。它保證了RRD文件的大小可以限制在一定范圍內，而且對于集群運維來說，我們往往只關心近期的數據細節，至于過去很久的監控數據看不到細節也沒多大妨礙。RRDTool還可以負責繪圖，ganglia的web展示上的圖正是由此而來。

　　ganglia和RRD雖然占用系統資源極少，但當集群規模超過5K之后，gmetad對監控數據的收集越來越顯得力不從心，而RRD文件即使是高效且壓縮的，也同樣面臨機器IO能力不足的問題。這些都是ganglia這套體系的短板，對于大多數公司團體來說，集群規模遠沒有達到觸發ganglia瓶頸的程度，但是對于云梯來說，這個天花板卻是觸手可及。

　　同時RRD數據庫的遠期數據細節丟失問題，對于集群運維來說毫無影響，但是對于測試人員來說卻是一個災難。因為細節的丟失將導致剛做的性能測試無法與一個月前甚至一年前的同樣的測試用例得到的結果進行對比。如果不解決這個問題，那么集群的性能監控對于測試人員的幫助將非常有限。

　　破解難題

　　上面提到的問題，在云梯這種大規模集群的測試中都遇到了。早期云梯測試人員試圖將監控數據從RRD數據庫中提取出來保存到mysql中，這樣方便查詢、對比、展示。但是對于上百個節點的測試集群來說，mysql數據庫往往只需一周時間就會被撐爆。一個簡單的指標數據的查詢往往就要等上半個多小時才能從mysql中提取出來。而監控數據保存到RRD文件，再使用RRDTool導出監控數據到mysql中，整個過程也是及其低效的。在我接手云梯1項目的集成測試之后，深深的被這個問題所困擾，整理測試數據讓每一次的集成測試結果匯總都苦不堪言。

　　2012年上半年，測試這邊開始主導設計DST(分布式測試工具)測試框架，隨著云梯項目的進行，DST也在不斷迭代中向前發展。其中集群監控數據的收集整理展示被我標記為首要必須完成的功能。經過深思熟慮，最終采用了“替代gmetad，并直接存儲監控數據至HBase”這個解決方案，設計的工具被我命名為“GGL2HBase”。

　　這個方案是做成一個與gmetad類似的服務，直接去所有節點的gmond master上抓取監控數據，從網絡拿到后，直接從內存中存儲到一個HBase集群中。利用HBase的高效解決了查詢慢的問題，同時RRD文件遠期數據細節丟失的問題也迎刃而解。

　　設計細節

　　HBase是一個典型的key/value結構的nosql數據庫，利用其RowKey自動排序的功能，我按機器編號(4字節int型)、指標編號(4字節int型)、時間戳(8字節long型)這樣的順序組合成了RowKey，Value中保存的則是這臺機器這個指標當前時間戳的監控數據(16個字節的double型數值)。這樣在查詢的時候，我可以根據機器名+指標名，快速的scan出一段時間內的監控數據。而存儲的時候，我在創建該表時，主動根據開始字節做了split，切分成1024個region(原本設想會有不到1000臺機器的監控數據導入HBase，后來隨著DST的推廣發展，導入的機器數量并發高峰期達到了3000多臺的規模，歷史上共有6000多臺機器正在或曾經導入過監控數據)，這樣保證了寫入的監控數據不會集中分布在某臺regionserver上，提高了寫入性能。

原文轉自：http://www.anti-gravitydesign.com/deltestingadmindd/