經過前面的發佈過的兩篇文章,咱們已經大體掌握了描述單個服務器的性能狀況的方法。能夠從load avgerage等總括性的數據着手,得到系統資源利用率(CPU、內存、I/O、網絡)和進程運行狀況的總體概念。參考CPU使用率和I/O等待時間等具體的數字,從而自頂向下快速排查各進程狀態。也能夠在60秒內,經過運行如下10個基本命令,判斷是否存在異常、評估飽和度,度量請求隊列長度等等。linux
2.Netflix性能分析模型:In 60 Secondsgit
在真實的工程實踐中,並不能老是經過幾行簡單的命令,直接得到性能問題的答案。通常不會存在一臺單獨運行的服務器,它們必定屬於某個服務集羣之中,就算是同一集羣的服務器,也可能屬於不一樣建設週期、硬件配置不一樣、分工角色不一樣。或者由不一樣機房、不通集羣的服務器共同協做完成任務。github
另外,不少性能問題也須要長時間的追蹤、對比才能做出判斷。正如任何一個高明的醫生,都須要儘量多地瞭解、記錄病人的病史,不掌握這些狀況,盲目下藥,無異於庸醫殺人。誠如醫者曰:數據庫
夫經方之難精,由來尚矣。今病有內同而外異,亦有內異而外, 故五臟六腑之盈虛,血脈榮衛之通塞,固非耳目之所察, 必先診候以審之。世有愚者,讀方三年,便謂天下無病可治; 及治病三年,乃知天下無方可用。
基於Ganglia項目,咱們能夠快速搭建一套高性能的監控系統,展開故障診斷分析、資源擴容預算甚至故障預測。服務器
通常應用中,須要用到兩個核心組件:微信
** Gmond (Ganglia Monitoring Daemon) ** Gmond承擔雙重角色:一、做爲Agent,部署在全部須要監控的服務器上。 二、做爲收發機,接收或轉發數據包。網絡
** Gmetad (Ganglia Meta Daemon)** 負責收集所在集羣的數據,並持久化到RRD數據庫。根據集羣的組網狀況,能夠部署1-N個。框架
** Web frontend ** Ganglia項目提供一個PHP編寫的通用型的Web包,主要實現數據可視化,能提供一些簡單的數據篩選UI。頁面很少,大量使用了模版技術。HTTP Server方面,用Apache和Nginx均可以。frontend
** RRDTool (Round Robin Database) ** Gmetad收集的時間序列數據都經過RRD存儲,RRDTool做爲繪圖引擎使用。
** 插件生態 ** Ganglia最重要的特性之一就是提供了一個靈活的數據標準和插件API。 它使得咱們能夠根據系統的狀況,很容易地在默認的監控指標集之上,引用或定製其餘擴展指標。 這一特性在大數據領域也得到了承認,Hadoop,Spark等都開放了面向Ganglia的指標集。 在Github上也有不少現成的擴展插件。
項目的名稱其實已經反映了做者的設計思路。 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"
# 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"> ......
沒有任何一個開源項目是完美的。
一、告警流程框架:Ganglia自己並不具有,能夠選用Nagios補充。
二、日誌管理框架:Ganglia自己並不具有,能夠選用Splunk補充。
三、性能開銷預算
對於單純的Gmond節點來講,性能開銷很低。主要的瓶頸在中央節點。
各節點的gmond進程向中央節點發送的udp數據帶來的網絡開銷。若是一個節點每秒發10個包, 1000個節點將會發出10000個,每一個包有200字節,就有2m字節,10000個包的處理所須要的cpu使用也會上升。
Gmetad默認15秒向gmond取一次xml數據,解析xml文件帶來的CPU負荷也會隨着管理節點數線性增加。
格外須要注意的是RRD的寫入瓶頸。實際應用中須要根據資源狀況,調整採樣頻率、權衡指標數量、引入RRDCached等方式優化。
四、網絡流向監控: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.
以Linux性能爲核心,覆蓋評估診斷、監控、優化工具、方法論和參考案例,歡迎訂閱、下載、批評指正。 本書發表在GitBook平臺: https://www.gitbook.com/book/riboseyim/linux-perf-master/details
更多精彩內容掃碼關注公衆號:RiboseYim's Blog:https://riboseyim.github.io