第一：統一監控報警平臺設計思路php
構建一個智能的運維監控平臺，必須以運行監控和故障報警這兩個方面爲重點，將全部業務系統中所涉及的網絡資源、硬件資源、軟件資源、數據庫資源等歸入統一的運維監控平臺中，並經過消除管理軟件的差異，數據採集手段的差異，對各類不一樣的數據來源實現統一管理、統一規範、統一處理、統一展示、統一用戶登陸、統一權限控制，最終實現運維規範化、自動化、智能化的大運維管理。python
智能的運維監控平臺，設計架構從低到高能夠分爲6層，三大模塊，如圖1所示：ios
數據收集層：位於最底層，主要收集網絡數據、業務系統數據、數據庫數據、操做系統數據等，而後將收集到的數據進行規範化，並進行存儲。web
數據展現層：位於第二層，是一個web展現界面，主要是將數據收集層獲取到的數據進行統一展現，展現的方式能夠是曲線圖、柱狀圖、餅狀態等，經過將數據圖形化，能夠幫助運維人員瞭解一段時間內主機或網絡的運行狀態和運行趨勢，並做爲運維人員排查問題或解決問題的依據。數據庫
數據提取層：位於第三層，主要是將數據收集層獲取到的數據進行規格化和過濾處理，提取須要的數據到監控報警模塊，這個部分是監控和報警兩個模塊的銜接點。安全
報警規則配置層：位於第四層，主要是根據第三層獲取到的數據進行報警規則設置、報警閥值設置、報警聯繫人設置和報警方式設置等。服務器
報警事件生成層：位於第五層，主要是將報警事件進行實時記錄，並將報警結果存入數據庫以備調用，並將報警結果造成分析報表，以統計一段時間內的故障率和故障發生趨勢。網絡
用戶展現管理層：位於最頂層，是一個web展現界面，主要是將監控統計結果、報警故障結果進行統一展現，並實現多用戶、多權限管理，實現統一用戶和統一權限控制。架構
在這6層中，從功能實現劃分，又分爲三個模塊，分別是數據收集模塊、數據提取模塊和監控報警模塊，每一個模塊完成的功能以下：運維
數據收集模塊：此模塊主要完成基礎數據的收集與圖形展現，數據收集的方式有不少種，能夠經過SNMP實現，也能夠經過代理模塊實現，還能夠經過自定義腳本實現，這裏採用數據收集工具Ganglia來實現。
數據提取模塊：此模板主要完成數據的篩選過濾和採集，將須要的數據從數據收集模塊提取到監控報警模塊中。能夠經過數據收集模塊提供的接口或者自定義腳本實現數據的提取。
監控報警模塊：此模塊主要完成監控腳本的設置、報警規則設置，報警閥值設置、報警聯繫人設置等，並將報警結果進行集中展示和歷史記錄，常見的監控報警工具備Nagios、Centreon等。
圖2是根據圖1的設計思路造成的一個運維監控平臺實現拓撲圖，從圖中能夠看出，主要有三大部分組成，分別是數據收集模塊、監控報警模塊和數據提取模塊。
其中，數據提取模塊用於其它兩個模塊之間的數據通訊，而數據收集模塊能夠有一臺或多臺數據收集服務器組成，每一個數據收集服務器能夠直接從服務器羣組收集各類數據指標，通過規範數據格式，最終將數據存儲到數據收集服務器中。
監控報警模塊經過數據抽取模塊從數據收集服務器獲取須要的數據，而後對數據設置報警閥值、報警聯繫人等，最終實現實時報警，報警方式支持手機短信報警、郵件報警等，另外，也能夠經過插件或者自定義腳原本擴展報警方式。這樣一整套監控報警平臺就基本實現了。
第二：Ganglia做爲數據收集模塊
Ganglia是一款爲HPC（高性能計算）集羣而設計的可擴展的分佈式監控系統，它能夠監視和顯示集羣中的節點的各類狀態信息，它由運行在各個節點上的gmond守護進程來採集cpu 、mem、硬盤利用率、I/O負載、網絡流量狀況等方面的數據，而後彙總到gmetad守護進程下，使用rrdtools存儲數據，最後將歷史數據以曲線方式經過php頁面呈現。
特色以下：
一、靈活的分佈式、分層體系結構，使Ganglia支持上萬個監控節點的數據收集，而且性能表現穩定，同時，Ganglia也能夠根據地域環境、網絡結構的不一樣，分地域、分層次的靈活部署Ganglia數據收集點，而對於數據收集節點能夠動態添加或刪除，對Ganglia總體監控不產生任何影響。所以，能夠靈活的擴展Ganglia數據收集節點。
二、Ganglia收集到的數據更加精確，它不但能夠收集實時數據，以圖表的形式展現出來，並且還容許用戶查看歷史統計數據，所以，用戶能夠經過這些數據，作出性能調整、升級、擴容等決策，從而保證應用系統可以知足不斷增加的業務需求。
三、Ganglia能夠經過組播、單播的方式收集數據，在監控的節點較多時經過組播方式收集數據能夠大大下降數據收集的負載，提升監控和數據收集性能。而對於不能使用組播收集數據的網絡環境，還能夠經過單播的方式收集數據，所以Ganglia在數據收集方式上很是靈活。
四、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環節：
一、gmond在客戶端之間經過udp方式互相傳遞的，有什麼意義？
答：經過udp方式傳輸數據，一方面是輕量級傳輸，在大量服務器監控的狀況下，不會過大消耗服務器和網絡資源，另外一方面udp方式的組播方式能夠將數據保存到多個節點，這樣能夠在管理端設置多個收集數據節點，當一個節點故障時，自動去另外一個節點收集數據，保證了數據收集的穩定性。
二、如何監控系統不經過tcpip而是經過讀取數據庫形式完成數據抓取，發現故障的延時會好不少麼？
答：抓取數據的方式決定了是否存在延時，這個跟ganglia無關，ganglia能夠接收接口過來的任意數據，可是是否有延時，決定權在你的數據收集腳本。
三、若是爲了備份數據的話，採用udp方式，一旦各個節點之間發生網絡抖動，數據完整性如何保證？
答：數據在每一個節點的保存時間基本在10秒左右，超過這個時間，數據會再次進行更新，所以不存在抖動問題，至於數據完整性，也能夠不用考慮，在收集到數據後，gmetad會對數據進行統一整理，更多關注的是數據的及時性。
