前言

大家好，我是愛維Linux的南非螞蟻，今天跟大家一起分享如何構建統一的運維監控平臺。

談到運維，監控應該是運維的重中之重。也有很多人說監控是運維的第三隻眼睛，一個好的監控平臺對運維工作來說，有很大的幫助。那麼，如何構建一個完善的監控平臺，就是我們今天要討論的話題。

從我個人的理解來說，運維的核心工作其實是監控和故障處理這兩個方面的內容。所以，首先要對業務系統有一個精確、完善的監控，這樣能夠保證在第一時間發現問題並通知相關人員解決。

其實出現問題了並不可怕，可怕的是我們很久都沒有發現問題，而是被客戶發現我們的業務系統出了故障，這就是個很嚴重的問題了。這些故障其實靠業務系統監控平臺就可以完成。

統一監控報警平臺設計思路

構建一個智慧的運維監控平臺，必須以執行監控和故障報警這兩個方面為重點，將所有業務系統中所涉及的網路資源、硬體資源、軟體資源、資料庫資源等納入統一的運維監控平臺中。

並通過消除管理軟體的差別，資料採集手段的差別，對各種不同的資料來源實現統一管理、統一規範、統一處理、統一展現、統一使用者登入、統一許可權控制，最終實現運維規範化、自動化、智慧化的大運維管理。

智慧運維監控平臺六大層

智慧的運維監控平臺，設計架構從低到高可以分為6層，三大模組，請看下圖：

• 資料收集層：位於最底層，主要收集網路資料、業務系統資料、資料庫資料、作業系統資料等，然後將收集到的資料進行規範化，並進行儲存。
• 資料展示層：位於第二層，是一個web展示介面，主要是將資料收集層獲取到的資料進行統一展示，展示的方式可以是曲線圖、柱狀圖、餅狀態等，通過將資料圖形化，可以幫助運維人員瞭解一段時間內主機或網路的執行狀態和執行趨勢，並作為運維人員排查問題或解決問題的依據。
• 資料提取層：位於第三層，主要是將資料收集層獲取到的資料進行規格化和過濾處理，提取需要的資料到監控報警模組，這個部分是監控和報警兩個模組的銜接點。
• 報警規則配置層：位於第四層，主要是根據第三層獲取到的資料進行報警規則設定、報警閥值設定、報警聯絡人設定和報警方式設定等。
• 報警事件生成層：位於第五層，主要是將報警事件進行實時記錄，並將報警結果存入資料庫以備呼叫，並將報警結果形成分析報表，以統計一段時間內的故障率和故障發生趨勢。
• 使用者展示管理層：位於最頂層，是一個web展示介面，主要是將監控統計結果、報警故障結果進行統一展示，並實現多使用者、多許可權管理，實現統一使用者和統一許可權控制。

智慧運維監控平臺三大模組

在這6層中，從功能實現劃分，又分為三個模組，分別是資料收集模組、資料提取模組和監控報警模組，每個模組完成的功能如下：

• 資料收集模組：此模組主要完成基礎資料的收集與圖形展示，資料收集的方式有很多種，可以通過SNMP實現，也可以通過代理模組實現，還可以通過自定義指令碼實現，這裡採用資料收集工具Ganglia來實現。
• 資料提取模組：此模板主要完成資料的篩選過濾和採集，將需要的資料從資料收集模組提取到監控報警模組中。可以通過資料收集模組提供的介面或者自定義指令碼實現資料的提取。
• 監控報警模組：此模組主要完成監控指令碼的設定、報警規則設定，報警閥值設定、報警聯絡人設定等，並將報警結果進行集中展現和歷史記錄，常見的監控報警工具有Nagios、Centreon等。

平臺總覽

下面根據上面的設計架構圖的思路形成一個運維監控平臺實現拓撲圖，請看下圖：

從圖中可以看出，主要有三大部分組成，分別是資料收集模組、資料抽取模和監控報警模組。

其中，資料抽取模組用於其它兩個模組之間的資料通訊，而資料收集模組可以有一臺或多臺資料收集伺服器組成，每個資料收集伺服器可以直接從伺服器群組收集各種資料指標，經過規範資料格式，最終將資料儲存到資料收集伺服器中。

監控報警模組通過資料抽取模組從資料收集伺服器獲取需要的資料，然後對資料設定報警閥值、報警聯絡人等，最終實現實時報警，報警方式支援手機簡訊報警、郵件報警等，另外，也可以通過外掛或者自定義指令碼來擴充套件報警方式。這樣一整套監控報警平臺就基本實現了。

Ganglia作為資料收集模組

Ganglia是一款為HPC(高效能運算)叢集而設計的可擴充套件的分散式監控系統，它可以監視和顯示叢集中的節點的各種狀態資訊。

它由執行在各個節點上的gmond守護程序來採集cpu、mem、硬碟利用率、I/O負載、網路流量情況等方面的資料，然後彙總到gmetad守護程序下，使用rrdtools儲存資料，最後將歷史資料以曲線方式通過php頁面呈現。

Ganglia特點如下：

• 靈活的分散式、分層體系結構，使Ganglia支援上萬個監控節點的資料收集，並且效能表現穩定，同時，Ganglia也可以根據地域環境、網路結構的不同，分地域、分層次的靈活部署Ganglia資料收集點，而對於資料收集節點可以動態新增或刪除，對Ganglia整體監控不產生任何影響。因此，可以靈活的擴充套件Ganglia資料收集節點。
• Ganglia收集到的資料更加精確，它不但可以收集實時資料，以圖表的形式展示出來，而且還允許使用者檢視歷史統計資料，因此，使用者可以通過這些資料，做出效能調整、升級、擴容等決策，從而保證應用系統能夠滿足不斷增長的業務需求。
• Ganglia可以通過組播、單播的方式收集資料，在監控的節點較多時通過組播方式收集資料可以大大降低資料收集的負載，提高監控和資料收集效能。而對於不能使用組播收集資料的網路環境，還可以通過單播的方式收集資料，因此Ganglia在資料收集方式上非常靈活。
• Ganglia可收集各種度量的資料，Ganglia預設情況下可收集cpu、memory、disk、I/O、process、network六大方面的資料，同時Ganglia提供了C或者Python介面，使用者通過這個介面可以自定義資料收集模組，並且這些模組可以被直接插入到Ganglia中以監控使用者自定義的應用。

Ganglia通過gmond完成自定義監控，現成可利用的模組有很多，地址如下：

基於以上Ganglia這些優點，使它非常適合作為監控報警平臺的資料收集模組。雖然Cacti/Zabbix也可以實現資料的收集和圖形報表的展示，但是當監控節點越來越多時，Cacti和Zabbix的缺點就慢慢暴露出來了，資料收集的準確性、實時性就很難得到保障了。

因此，要構建一個高效能的監控報警平臺，Ganglia是首選的資料收集模組。我們之前在線上監控三地機房10000多臺伺服器，效能表現穩定，資料報警延時基本在10s左右。

Centreon作為監控報警模組

有了Ganglia收集資料還是不夠的，運維人員不可能天天盯著資料報表。

因此，還需要對收集到的資料進行監控和報警：

對每個需要監控的主機或服務，設定一個報警閥值，當收集到的資料超過這個閥值時，在第一時間能自動報警並通知到運維人員，而如果收集到的資料沒有超過指定的報警閥值，運維人員就可以去做別的事情，而不用時刻盯著資料報表，這是構建智慧監控報警平臺必須要實現的一個功能。

對主機或服務的狀態值進行監控，當達到指定閥值時進行報警，要實現這個功能並不是什麼難的事情，可以寫個簡單的指令碼就能實現，但是這樣太原始了，沒有層次，維護性差，並且當需要監控報警的主機或服務越來越多時，指令碼的效能就變得很差，管理也非常不方便，更別說有什麼視覺化效果了，因此，就需要有一個專業的監控報警工具來實現這個功能。

Centreon是一款功能強大的分散式IT監控系統，它通過第三方元件可以實現對網路、作業系統和應用程式的監控，它的特點如下：

• 它是開源的，我們可以免費使用它。
• 底層與Nagios緊密整合，它的底層採用nagios作為監控軟體(目前官方已經開發出了自己的底層監控)，同時nagios通過ndoutil模組將監控到的資料定時寫入資料庫中，而Centreon實時從資料庫讀取該資料並通過Web介面展現監控資料。
• 可以通過Centreon管理和配置nagios，或者說Centreon就是nagios的一個管理配置工具，通過Centreon提供的Web配置介面，可以輕鬆完成nagios的各種繁瑣配置。
• 支援多種外掛，Centreon還支援NRPE、SNMP、NSClient等外掛，可以通過這些外掛構建分散式的監控報警系統。

Centreon通過第三方元件可以實現對網路、作業系統和應用程式的監控與報警。

在資料層，Centreon通過ndoutil模組將監控到的資料定時寫入資料庫中。

在展示層，Centreon提供了Web介面來配置、管理需要監控的主機或服務，並提供多種報警通知方式，同時還可以展現監控資料和報警狀態，並可查詢歷史報警記錄。

Ganglia與Centreon的無縫整合

Nagios和Ganglia都是很好的資料中心監控工具，雖然它們的功能有重疊部分，但是兩者對監控的側重點並不相同：

• Ganglia側重於收集資料，並隨時跟蹤資料狀態。通過Ganglia不但可以看到資料的歷史狀態，也可以預計資料的未來發展趨勢，為我們的應用程式修正和硬體採購提供決策。
• Nagios更側重於監控資料並進行過載報警。

綜合Ganglia和Nagios的優缺點，同時執行這兩個工具可以相互彌補它們的不足：

1. Ganglia暫時沒有內建報警通知機制，而Nagios這方面是強項。
2. Nagios沒有內建代理和分散式監控機制，而Ganglia設計之初就考慮到了這些。
3. Nagios沒有直觀的報表展示(雖然可通過PNP外掛實現)，而Ganglia報表功能很強大。
4. Ganglia內建了基於很多開發介面，通過這些介面，可以將Ganglia統計到的資料納入Nagios監控之下。

確定了以Ganglia作為資料收集模組，Centreon作為監控報警模組的方案。

這樣，一個智慧監控報警平臺兩大主要功能模組已經基本實現了，但現在的問題是：如何將收集到的資料傳送給監控報警模組呢?這就是資料抽取模組要完成的功能。

資料抽取模組要完成的功能

從資料收集模組中定時採集指定的資料，然後將採集到的資料與指定的報警閥值進行比較。如果發現採集到的資料大於或小於指定的報警閥值，那麼就通過監控報警模組設定的報警方式進行故障通知。

這個過程，只有採集資料是在資料收集模組中完成，其他操作，例如，採集資料時間間隔、報警閥值設定、報警方式設定、報警聯絡人設定等都在監控報警模組中完成的。

從資料抽取模組完成的功能可以看出，此模組主要用來銜接資料收集模組和監控報警模組，進而完成Ganglia和Centreon的無縫整合。

要實現資料抽取模組的功能，沒有現成的方法可用，需要在ganglia基礎上做二次開發，較簡單的方法是通過程式在ganglia上開發一個數據提取介面，然後將資料抽取到nagios中，初步方案是通過python程式來實現。

當然也有現成的方案，推薦兩個現成的資料提取指令碼：

PHP版本：

Python版本：

統一監控系統架構圖

下面看看整個監控平臺的系統架構：

Cluster1-N均為分散式叢集，也可以認為是機房資料中心。每個資料中心的Node server都執行一個Gmond守護程序，進行資料收集，將收集到的資料彙總到Ganglia proxy主機，Ganglia proxy主機上執行著Gmetad守護程序。

同時Ganglia proxy和Node server都載入通過C或者Python編寫的Ganglia外掛，擴充套件Ganglia監控功能。

Manager Server是管理主機，主要用於收集各個資料中心的監控資料，通過資料抽取模組將Nagios和Ganglia整合到一起。

考慮到資料的安全性及服務可用性，Manager Server建議做一個備機，平時主機和備機同時工作，進行資料收集，主機故障時，自動切換到備機，保證管理主機高可用。

監控資料和報表通過Web方式展示出來，將Nagios和Ganglia的web進行整合，並作二次開發，通過一個統一的介面展示監控狀態和報表資訊。

Ganglia資料流向圖

在Ganglia分散式監控系統中，gmond和gmetad之間是如何傳輸資料呢?接下來介紹一下Ganglia是如何實現資料的傳輸和收集的，請看下圖：

基本流程如下：

1. gmond收集本機的監控資料，傳送到其他機器上，並收集其他機器的監控資料，gmond之間通過udp通訊，傳遞檔案格式為XDL。
2. gmond節點間的資料傳輸方式除支援單播點對點傳送外，還支援多播傳送。
3. gmetad週期性的去gmond節點或者gmetad節點pull資料，gmetad只有tcp通道，gmond與gmetad之間的資料都以XML格式傳輸。
4. gmetad既可以從gmond也可以從其他的gmetad得到xml資料。
5. gmetad將獲取到的資料更新到rrds資料庫中。
6. Nagios通過資料抽取模組監控ganglia獲取到的資料並進行報警。
7. 通過web監控介面，從Gmetad取資料，並且讀取rrd資料庫，生成圖片顯示出來。

至此，ganglia內部結構完全剖析。

這樣，一個完整的運維監控平臺就構建起來了。我們通過這種架構做運維監控平臺，已經穩定執行3年多，監控1萬2千多臺伺服器。

問答環節

問題1：gmetad是單機嗎?1萬臺主機的監控gmetad需要什麼配置?

回答：gmetad是資料收集核心，不建議單機，至少兩臺做成主備模式，1w臺主機分佈在3個機房，gmetad做成分散式結構，本身ganglia也支援分散式資料彙總，這個看剛才的資料流向圖就可以看到。

問題2：告警策略，只有大於XX或小於XX嗎?還有其他策略嗎?

回答：告警策略都整合在了Centreon裡面，設定策略很靈活，大於、小於、等於，重試次數、間隔等，都可以設定，這個根據自己需要來定義即可。

問題3：中介軟體，資料庫的監控內容是什麼?

回答：監控內容需根據業務需求進行自定義，通常監控內容有三種類型：

• 系統底層資料。
• 業務系統無邏輯關係資料。
• 業務系統有邏輯關係資料。

定義監控內容，加入到監控報警平臺即可。

問題4：Gmond收集本機的監控資料，傳送到其他機器上，並收集其他機器的監控資料，gmond之間通過udp通訊，傳遞檔案格式為XDL，這個怎麼理解?

回答：gmond支援單播和組播收集和傳送資料，單播僅僅是上報資料到上級節點，組播是互相收集資料，然後上報，傳遞檔案格式是xdl的，通過telnet gmond埠可以看到傳送的資料格式。

問題5：監控平臺支援對window、linux全平臺的監控嗎?

回答：支援全平臺監控，支援各種系統平臺、網路、交換機等。

問題6：咱們監控系統是有專門的團隊維護嗎?

回答：我們的監控平臺有運維團隊維護並做二次開發。

問題7：支援波動監控嗎?

回答：波動監控是肯定存在的，本身udp方式傳送資料，資料更新速度很快，最重要一點，ganglia非常適合做分散式多機房監控，各個機房通過vpn傳輸資料，網路間的波動影響，可以通過監控引數調整。

問題8：一萬多臺機器，有多少個監控項?每天多少告警?

回答：我們的資料監控項超過1w，每次獲取的xdl資料都在20-30M左右，核心資料是hadoop，這種方式建議通過單播來收集，因為組播對網路消耗較大。

問題9：文中提到1w臺伺服器監控延時三，秒如果有些監控點取數執行時間太長，做不到這麼快速，怎麼規避?如果機器本來資源不足，頻繁跑監控，機器會不會掛?

回答：我們最大延時報警是10s，每個節點都是gmond在獲取資料，gmond是主動傳送資料到上級的gmond，因此消耗很小，幾乎可以忽略不計，需要關注的是上級gmond資料匯聚點，這些伺服器需要配置高效能cpu和磁碟，因此磁碟io消耗極大，對於執行時間過長的監控點，可以設定超時機制，這種情況一般是跨機房監控會出現，機房內部基本不會出現這種情況。

選ganglia就是看中了gmond對客戶端資源消耗很小的緣故。

問題10：監控運維和開發團隊有多少人?

回答：6個人，開發運維2人，系統(業務)運維3人，網路運維1人。