嘉賓簡介：

[[164472]]

高俊峰(南非螞蟻)，Linux資深技術專家，暢銷書籍《循序漸進Linux》、《高性能Linux服務器構建實戰》作者，曾就職于新浪、萬網，具有多年的自動化運維和管理經驗，擅長Linux、集群應用、MySQL、Oracle等方面的系統管理、性能調優，規劃設計，實戰經驗豐富。

目前關注于Hadoop數據平臺以及和Hadoop相關的生態系統的運維、監控、部署、優化等技術。

前言

大家好，我是愛維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完成自定義監控，現成可利用的模塊有很多，地址如下：

https://github.com/ganglia/gmond_python_modules

基于以上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版本：

http://www.iivey.com/ganglia/check_ganglia_metric.php.txt

Python版本：

http://www.iivey.com/ganglia/check_ganglia_metric.py.txt

統一監控系統架構圖

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

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人。