本文以開源項目Ganglia為例，介紹多集群環境下，利用監控系統進行故障診斷、性能瓶頸分析的一般方法。
回顧
通過前面的發布過的兩篇文章，我們已經大致掌握了描述單個服務器的性能情況的方法?？梢詮膌oad avgerage等總括性的數據著手，獲得系統資源利用率（CPU、內存、I/O、網絡）和進程運行情況的整體概念。參考CPU使用率和I/O等待時間等具體的數字，從而自頂向下快速排查各進程狀態。也可以在60秒內，通過運行以下10個基本命令，判斷是否存在異常、評估飽和度，度量請求隊列長度等等。
在真實的工程實踐中，并不能總是通過幾行簡單的命令，直接獲得性能問題的答案。一般不會存在一臺單獨運行的服務器，它們一定屬于某個服務集群之中，就算是同一集群的服務器，也可能屬于不同建設周期、硬件配置不同、分工角色不同?；蛘哂刹煌瑱C房、不通集群的服務器共同協作完成任務。
另外，很多性能問題也需要長時間的追蹤、對比才能作出判斷。正如任何一個高明的醫生，都需要盡可能多地了解、記錄病人的病史，不掌握這些情況，盲目下藥，無異于庸醫殺人。誠如醫者曰：
夫經方之難精，由來尚矣。今病有內同而外異，亦有內異而外，
故五臟六腑之盈虛，血脈榮衛之通塞，固非耳目之所察，
必先診候以審之。世有愚者，讀方三年，便謂天下無病可治；
及治病三年，乃知天下無方可用。
基于Ganglia項目，我們可以快速搭建一套高性能的監控系統，展開故障診斷分析、資源擴容預算甚至故障預測。
Ganglia框架簡析
一般應用中，需要用到兩個核心組件：
** Gmond （Ganglia Monitoring Daemon） **
Gmond承擔雙重角色：1、作為Agent，部署在所有需要監控的服務器上。
2、作為收發機，接收或轉發數據包。
** Gmetad (Ganglia Meta Daemon)**
負責收集所在集群的數據，并持久化到RRD數據庫。根據集群的組網情況，可以部署1-N個。
** Web frontend **
Ganglia項目提供一個PHP編寫的通用型的Web包，主要實現數據可視化，能提供一些簡單的數據篩選UI。頁面不多，大量使用了模版技術。HTTP Server方面，用Apache和Nginx都可以。
** RRDTool (Round Robin Database) **
Gmetad收集的時間序列數據都通過RRD存儲，RRDTool作為繪圖引擎使用。
** 插件生態 **
Ganglia最重要的特性之一就是提供了一個靈活的數據標準和插件API。
它使得我們可以根據系統的情況，很容易地在默認的監控指標集之上，引用或定制其他擴展指標。
這一特性在大數據領域也獲得了認可，Hadoop,Spark等都開放了面向Ganglia的指標集。
在Github上也有很多現成的擴展插件。
Ganglia工作模式
項目的名稱其實已經反映了作者的設計思路。
Ganglia（又作：ganglion）,直譯為“神經節”、“中樞神經”。在解剖學上是一個生物組織叢集，通常是神經細胞體的集合。在神經學中，神經節主要是由核周體和附隨連結的樹突組合而成。神經節經常與其他神經節相互連接以形成一個復雜的神經節系統。神經節提供了身體內不同神經體系之間的依靠點和中介連結，例如周圍神經系統和中樞神經系統。
Ganglia的作者意圖將服務器集群理解為生物神經系統，每臺服務器都是獨立工作神經節，通過多層次樹突結構連接起來，
既可以橫向聯合，也可以從低向高，逐層傳遞信息。具體例證就是Ganglia的收集數據工作可以工作在單播（unicast)或多播(multicast)模式下，
默認為多播模式。
單播：Gmond收集到的監控數據發送到特定的一臺或幾臺機器上，可以跨網段
多播：Gmond收集到的監控數據發送到同一網段內所有的機器上，同時收集同一網段內的所有機器發送過來的監控數據。
因為是以廣播包的形式發送，因此需要同一網段內。但同一網段內，又可以定義不同的發送通道。
vi /usr/local/ganglia/etc/gmond.conf
** 默認配置：**
cluster {
name = "cluster01"
}
udp_send_channel {
mcast_join = 239.2.11.71
port = 8649
ttl = 1
}
udp_recv_channel {
mcast_join = 239.2.11.71
port = 8649
bind = 239.2.11.71
retry_bind = true
}
tcp_accept_channel {
port = 8649
gzip_output = no
}
** 單播模式Gmetad增加配置：**
udp_recv_channel {
port = 8666
}
** 單播模式Gmond增加配置：**
udp_send_channel {
host = 192.168.0.39
port = 8666
ttl = 1
}
** 默認裝載指標集：**
modules {
module {
name = "core_metrics"
}
module {
name = "cpu_module"
path = "modcpu.so"
}
module {
name = "disk_module"
path = "moddisk.so"
}
module {
name = "load_module"
path = "modload.so"
}
module {
name = "mem_module"
path = "modmem.so"
}
module {
name = "net_module"
path = "modnet.so"
}
module {
name = "proc_module"
path = "modproc.so"
}
module {
name = "sys_module"
path = "modsys.so"
}
}
vi /usr/local/ganglia/etc/gmetad.conf
### 配置數據源，可以多個
data_source "cluster01" localhost:8649
data_source "cluster02" 192.168.0.39:8666 192.168.0.48:8666
gridname "mygrid"
### 指定RRD數據路徑
rrd_rootdir "/home/data/ganglia/rrds"
查看數據流向
[root@zynm-gddx-col13 etc]# netstat -an | grep 86
tcp 0 0 0.0.0.0:8649 0.0.0.0:* LISTEN ##tcp_accept_channel
udp 0 0 192.168.0.45:52745 239.2.11.71:8649 ESTABLISHED ##組播
udp 0 0 239.2.11.71:8649 0.0.0.0:*
udp 0 0 0.0.0.0:8666 0.0.0.0:* ##udp_recv_channel
Gmetad所在位置，已經可以收到監控數據的服務器列表：
# telnet localhost 8649 | grep HOST
<HOST NAME="192.168.0.56" IP="192.168.0.56" TAGS="" REPORTED="1478226772" TN="6" TMAX="20" DMAX="86400" LOCATION="GZ" GMOND_STARTED="1477817579">
</HOST>
<HOST NAME="192.168.0.39" IP="192.168.0.39" TAGS="" REPORTED="1478226771" TN="7" TMAX="20" DMAX="86400" LOCATION="GZ" GMOND_STARTED="1477473541">
......
Gmond所在位置，收到的監控指標數據明細：
# telnet localhost 8649 | grep cpu_idle
telnet: connect to address ::1: Connection refused
<METRIC NAME="cpu_idle" VAL="96.7" TYPE="float" UNITS="%" TN="33" TMAX="90" DMAX="0" SLOPE="both">
<METRIC NAME="cpu_idle" VAL="100.0" TYPE="float" UNITS="%" TN="20" TMAX="90" DMAX="0" SLOPE="both">
<METRIC NAME="cpu_idle" VAL="91.2" TYPE="float" UNITS="%" TN="4" TMAX="90" DMAX="0" SLOPE="both">
<METRIC NAME="cpu_idle" VAL="96.3" TYPE="float" UNITS="%" TN="28" TMAX="90" DMAX="0" SLOPE="both">
<METRIC NAME="cpu_idle" VAL="99.9" TYPE="float" UNITS="%" TN="5" TMAX="90" DMAX="0" SLOPE="both">
<METRIC NAME="cpu_idle" VAL="83.9" TYPE="float" UNITS="%" TN="14" TMAX="90" DMAX="0" SLOPE="both">
<METRIC NAME="cpu_idle" VAL="84.2" TYPE="float" UNITS="%" TN="0" TMAX="90" DMAX="0" SLOPE="both">
<METRIC NAME="cpu_idle" VAL="44.1" TYPE="float" UNITS="%" TN="9" TMAX="90" DMAX="0" SLOPE="both">
......
數據可視化
注意事項
沒有任何一個開源項目是完美的。
1、告警流程框架：Ganglia本身并不具備，可以選用Nagios補充。
2、日志管理框架：Ganglia本身并不具備，可以選用Splunk補充。
3、性能開銷預算
對于單純的Gmond節點來說，性能開銷很低。主要的瓶頸在中央節點。
各節點的gmond進程向中央節點發送的udp數據帶來的網絡開銷。如果一個節點每秒發10個包，
1000個節點將會發出10000個，每個包有200字節，就有2m字節，10000個包的處理所需要的cpu使用也會上升。
Gmetad默認15秒向gmond取一次xml數據,解析xml文件帶來的CPU負荷也會隨著管理節點數線性增長。
格外需要注意的是RRD的寫入瓶頸。實際應用中需要根據資源情況，調整采樣頻率、權衡指標數量、引入RRDCached等方式優化。
4、網絡流向監控：Ganglia原生支持sFlow
GitHub:gmond-proxy project。what are some of the benefits of using the proxy?
Firstly, the proxy allows metrics to be filtered, reducing the amount of data logged and increasing the scaleability of the Ganglia collector.
Secondly, sFlow-RT generates traffic flow metrics, making them available to Ganglia.
Finally, Ganglia is typically used in conjunction with additional monitoring tools that can all be driven using the analytics stream generated by sFlow-RT.
參考資料
1、《 The ganglia distributed monitoring system: design, implementation, and experience》（必讀）
2、《Wide Area Cluster Monitoring with Ganglia》（必讀）
3、這篇本來沒有什么直接關系，是Ganglia作者的最新研究成果，僅供娛樂。
