談到運維，監控應該是運維的重中之重。怎么說呢？有很多人說這個監控應該是運維的第三只眼睛，一個好的監控平台對我們這個工作本身來說，應該有很大的幫助。那么，如何要構建一個完善的監控平台。那就是我們今天要討論的話題：
以我的理解來說這個運維的核心工作其實是監控和故障處理。兩個方面的工作首先是對這個業務系統我們要有一個精確的完善的監控。那么他的目的就是能夠保證在第一時間去發現問題並且去通知相關人員解決問題。其實出現問題了並不可怕，可怕的是我們很久沒有發現問題，那么最終被客戶發現我們的業務系統出現故障，那么就是個很嚴重的問題了，這些都是靠業務系統監控平台來完成的。
提綱介紹：
1、統一監控報警平台設計思路
2、Ganglia作為數據收集模塊
3、Centreon作為監控報警模塊
4、Ganglia與Centreon的無縫整合
5、統計監控系統架構圖
6、數據流向圖
第一：統一監控報警平台設計思路
構建一個智能的運維監控平台，必須以運行監控和故障報警這兩個方面為重點，將所有業務系統中所涉及的網絡資源、硬件資源、軟件資源、數據庫資源等納入統一的運維監控平台中，並通過消除管理軟件的差別，數據采集手段的差別，對各種不同的數據來源實現統一管理、統一規范、統一處理、統一展現、統一用戶登錄、統一權限控制，最終實現運維規范化、自動化、智能化的大運維管理。
智能的運維監控平台，設計架構從低到高可以分為6層，三大模塊，如圖1所示：
數據收集層：位於最底層，主要收集網絡數據、業務系統數據、數據庫數據、操作系統數據等，然后將收集到的數據進行規范化，並進行存儲。
數據展示層：位於第二層，是一個web展示界面，主要是將數據收集層獲取到的數據進行統一展示，展示的方式可以是曲線圖、柱狀圖、餅狀態等，通過將數據圖形化，可以幫助運維人員了解一段時間內主機或網絡的運行狀態和運行趨勢，並作為運維人員排查問題或解決問題的依據。
數據提取層：位於第三層，主要是將數據收集層獲取到的數據進行規格化和過濾處理，提取需要的數據到監控報警模塊，這個部分是監控和報警兩個模塊的銜接點。
報警規則配置層：位於第四層，主要是根據第三層獲取到的數據進行報警規則設置、報警閥值設置、報警聯系人設置和報警方式設置等。
報警事件生成層：位於第五層，主要是將報警事件進行實時記錄，並將報警結果存入數據庫以備調用，並將報警結果形成分析報表，以統計一段時間內的故障率和故障發生趨勢。
用戶展示管理層：位於最頂層，是一個web展示界面，主要是將監控統計結果、報警故障結果進行統一展示，並實現多用戶、多權限管理，實現統一用戶和統一權限控制。
在這6層中，從功能實現划分，又分為三個模塊，分別是數據收集模塊、數據提取模塊和監控報警模塊，每個模塊完成的功能如下：
數據收集模塊：此模塊主要完成基礎數據的收集與圖形展示，數據收集的方式有很多種，可以通過SNMP實現，也可以通過代理模塊實現，還可以通過自定義腳本實現，這里采用數據收集工具Ganglia來實現。
數據提取模塊：此模板主要完成數據的篩選過濾和采集，將需要的數據從數據收集模塊提取到監控報警模塊中。可以通過數據收集模塊提供的接口或者自定義腳本實現數據的提取。
監控報警模塊：此模塊主要完成監控腳本的設置、報警規則設置，報警閥值設置、報警聯系人設置等，並將報警結果進行集中展現和歷史記錄，常見的監控報警工具有Nagios、Centreon等。
圖2是根據圖1的設計思路形成的一個運維監控平台實現拓撲圖，從圖中可以看出，主要有三大部分組成，分別是數據收集模塊、監控報警模塊和數據提取模塊。
其中，數據提取模塊用於其它兩個模塊之間的數據通信，而數據收集模塊可以有一台或多台數據收集服務器組成，每個數據收集服務器可以直接從服務器群組收集各種數據指標，經過規范數據格式，最終將數據存儲到數據收集服務器中。
監控報警模塊通過數據抽取模塊從數據收集服務器獲取需要的數據，然后對數據設置報警閥值、報警聯系人等，最終實現實時報警，報警方式支持手機短信報警、郵件報警等，另外，也可以通過插件或者自定義腳本來擴展報警方式。這樣一整套監控報警平台就基本實現了。
第二：Ganglia作為數據收集模塊
Ganglia是一款為HPC（高性能計算）集群而設計的可擴展的分布式監控系統，它可以監視和顯示集群中的節點的各種狀態信息，它由運行在各個節點上的gmond守護進程來采集cpu 、mem、硬盤利用率、I/O負載、網絡流量情況等方面的數據，然后匯總到gmetad守護進程下，使用rrdtools存儲數據，最后將歷史數據以曲線方式通過php頁面呈現。
特點如下：
1、靈活的分布式、分層體系結構，使Ganglia支持上萬個監控節點的數據收集，並且性能表現穩定，同時，Ganglia也可以根據地域環境、網絡結構的不同，分地域、分層次的靈活部署Ganglia數據收集點，而對於數據收集節點可以動態添加或刪除，對Ganglia整體監控不產生任何影響。因此，可以靈活的擴展Ganglia數據收集節點。
2、Ganglia收集到的數據更加精確，它不但可以收集實時數據，以圖表的形式展示出來，而且還允許用戶查看歷史統計數據，因此，用戶可以通過這些數據，做出性能調整、升級、擴容等決策，從而保證應用系統能夠滿足不斷增長的業務需求。
3、Ganglia可以通過組播、單播的方式收集數據，在監控的節點較多時通過組播方式收集數據可以大大降低數據收集的負載，提高監控和數據收集性能。而對於不能使用組播收集數據的網絡環境，還可以通過單播的方式收集數據，因此Ganglia在數據收集方式上非常靈活。
4、Ganglia可收集各種度量的數據，Ganglia默認情況下可收集cpu、memory、disk、I/O、process、network六大方面的數據，同時Ganglia提供了C或者Python接口，用戶通過這個接口可以自定義數據收集模塊，並且這些模塊可以被直接插入到Ganglia中以監控用戶自定義的應用。
基於以上Ganglia這些優點，使它非常適合作為監控報警平台的數據收集模塊，雖然Cacti/zabbix也可以實現數據的收集和圖形報表的展示，但是當監控節點越來越多時，Cacti和zabbix的缺點就慢慢暴露出來了，數據收集的准確性、實時性就很難得到保障了。因此，要構建一個高性能的監控報警平台，Ganglia是首選的數據收集模塊。
第三：Centreon作為監控報警模塊
有了Ganglia收集數據還是不夠的，運維人員不可能天天盯着數據報表，因此，還需要對收集到的數據進行監控和報警：對每個需要監控的主機或服務，設置一個報警閥值，當收集到的數據超過這個閥值時，在第一時間能自動報警並通知到運維人員，而如果收集到的數據沒有超過指定的報警閥值，運維人員就可以去做別的事情，而不用時刻盯着數據報表，這是構建智能監控報警平台必須要實現的一個功能。
對主機或服務的狀態值進行監控，當達到指定閥值時進行報警，要實現這個功能並不是什么難的事情，可以寫個簡單的腳本就能實現，但是這樣太原始了，沒有層次，維護性差，並且當需要監控報警的主機或服務越來越多時，腳本的性能就變得很差，管理也非常不方便，更別說有什么可視化效果了，因此，就需要有一個專業的監控報警工具來實現這個功能。
Centreon就是這樣一個專業的分布式監控、報警工具，它通過第三方組件可以實現對網絡、操作系統和應用程序的監控與報警，在底層，centreon通過nagios作為監控軟件，在數據層，Centreon通過ndoutil模塊將監控到的數據定時寫入數據庫中，在展示層，Centreon提供了Web界面來配置、管理需要監控的主機或服務，並提供多種報警通知方式，同時還可以展現監控數據和報警狀態，並可查詢歷史報警記錄。
第四：Ganglia與Centreon的無縫整合
Nagios和Ganglia都是很好的數據中心監控工具，雖然它們的功能有重疊部分，但是兩者對監控的側重點並不相同：Ganglia側重於收集數據，並隨時跟蹤數據狀態，通過Ganglia不但可以看到數據的歷史狀態，也可以預計數據的未來發展趨勢，為我們的應用程序修正和硬件采購提供決策。而Nagios更側重與監控數據並進行過載報警，綜合Ganglia和Nagios的優缺點，同時運行這兩個工具可以相互彌補它們的不足：
Ganglia暫時沒有內置報警通知機制，而Nagios這方面是強項。
Nagios沒有內置代理和分布式監控機制，而Ganglia設計之初就考慮到了這些。
Nagios沒有直觀的報表展示（雖然可通過PNP插件實現），而Ganglia報表功能很強大。
Ganglia內置了基於很多開發接口，通過這些接口，可以將Ganglia統計到的數據納入Nagios監控之下。
確定了以Ganglia作為數據收集模塊，Centreon作為監控報警模塊的方案，這樣，一個智能監控報警平台兩大主要功能模塊已經基本實現了，但現在的問題是，如何將收集到的數據傳送給監控報警模塊呢，這就是數據抽取模塊要完成的功能。
數據抽取模塊要完成的功能是：從數據收集模塊中定時采集指定的數據，然后將采集到的數據與指定的報警閥值進行比較，如果發現采集到的數據大於或小於指定的報警閥值，那么就通過監控報警模塊設置的報警方式進行故障通知，這個過程，只有采集數據是在數據收集模塊中完成，其他操作，例如：采集數據時間間隔、報警閥值設置、報警方式設置、報警聯系人設置等都在監控報警模塊中完成。
從數據抽取模塊完成的功能可以看出，此模塊主要用來銜接數據收集模塊和監控報警模塊，進而完成Ganglia和Centreon的無縫整合。
要實現數據抽取模塊的功能，沒有現成的方法可用，需要在ganglia基礎上做二次開發，較簡單的方法是在通過程序在ganglia上開發一個數據提取接口，然后將數據抽取到nagios中，初步方案是通過python程序來實現。
第五：統計監控系統架構圖
簡單描述如下：
Cluster1-N均為一個分布式集群，也可以認為是一個機房數據中心。每個數據中心的Node server都運行一個Gmond守護進程，進行數據收集，將收集到的數據匯總到Ganglia proxy主機，Ganglia proxy主機上運行着Gmetad守護進程。同時Gangliaproxy和Node server都加載通過C或者Python編寫的Ganglia插件，擴展Ganglia監控功能。
Managerserver是一個管理主機，主要用於收集從各個機房數據中心的監控數據，通過數據抽取模塊將Nagios和Ganglia整合到一起，考慮到數據的安全性，Manager server建議做一個備機，平時主機和備機同時工作，進行數據收集，主機故障時，自動切換到備機，保證管理主機高可用。
監控數據和報表通過Web方式展示出來，將Nagios和Ganglia的web進行整合，並作二次開發，通過一個統一的界面展示監控狀態和報表信息。
第六：數據流向圖
基本流程如下：
Gmond收集本機的監控數據，發送到其他機器上，並收集其他機器的監控數據，gmond之間通過udp通信，傳遞文件格式為XDL。
Gmond節點間的數據傳輸方式支持單播點對點傳送外，還支持多播傳送。
gmetad周期性的去gmond節點或者gmetad節點poll數據，Gmetad只有tcp通道，gmond與gmetad之間的數據都以XML格式傳輸。
gmetad既可以從gmond也可以從其他的gmetad得到xml數據。
gmetad將獲取到的數據更新到rrds數據庫中。
Nagios通過數據抽取模塊監控ganglia獲取到的數據並進行報警。
通過web監控界面，從Gmetad取數據，並且讀取rrd數據庫，生成圖片顯示出來。
接下來是QA環節：
1、gmond在客戶端之間通過udp方式互相傳遞的，有什么意義？
答：通過udp方式傳輸數據，一方面是輕量級傳輸，在大量服務器監控的情況下，不會過大消耗服務器和網絡資源，另一方面udp方式的組播方式可以將數據保存到多個節點，這樣可以在管理端設置多個收集數據節點，當一個節點故障時，自動去另一個節點收集數據，保證了數據收集的穩定性。
2、如何監控系統不通過tcpip而是通過讀取數據庫形式完成數據抓取，發現故障的延時會好很多么？
答：抓取數據的方式決定了是否存在延時，這個跟ganglia無關，ganglia可以接收接口過來的任意數據，但是是否有延時，決定權在你的數據收集腳本。
3、如果為了備份數據的話，采用udp方式，一旦各個節點之間發生網絡抖動，數據完整性如何保證？
答：數據在每個節點的保存時間基本在10秒左右，超過這個時間，數據會再次進行更新，因此不存在抖動問題，至於數據完整性，也可以不用考慮，在收集到數據后，gmetad會對數據進行統一整理，更多關注的是數據的及時性。