無監控，不運維！運維監控工具平臺建設總結

本文摘自微信公衆號《高效運維》

運維行業有句話：「無監控、不運維」，是的，一點也不誇張，監控俗稱「第三隻眼」。沒了監控，什麼基礎運維，業務運維都是「瞎子」。因此說監控是運維這個職業的根本。 尤爲是在如今DevOps這麼火的時候，用監控數據給本身撐腰，這顯得更加必要，有人說運維是背鍋俠，那麼，有了監控，有了充足的數據，一切以數聽說話，運維還須要背鍋嗎，因此做爲一個運維工程師，如何構建一套監控系統是你的第一件工做。

---

1、常見的運維監控工具

如今運維監控工具很是多，哪一個好，哪一個很差，哪一個適合你，哪一個不適合你，其實只有你瞭解了他們的特性後，才知道，因此從這裏開始講起。

一、Cacti

        Cacti是一套基於PHP，MySQL，SNMP及RRDTool開發的網絡流量監測圖形分析工具。 簡單的說Cacti就是一個PHP程序。它經過使用SNMP協議獲取遠端網絡設備和相關信息（其實就是使用Net-SNMP 軟件包的snmpget 和snmpwalk 命令獲取）並經過RRDTOOL工具繪圖，經過PHP程序展示出來。咱們使用它能夠展示出監控對象一段時間內的狀態或者性能趨勢圖。

        cacti是很老的一款監控工具了，其實說它是一款流量監控工具更合適，對流量監控比較精準，但缺點不少，出圖很差看，不支持分佈式，也沒有告警功能，因此使用的人會愈來愈少。

二、Nagios

        Nagios是一款開源的免費網絡監視工具，能有效監控Windows、Linux和Unix的主機狀態，交換機路由器等網絡設置，打印機等。在系統或服務狀態異常時發出郵件或短信報警第一時間通知網站運維人員，在狀態恢復後發出正常的郵件或短信通知。

        nagios主要的特徵是監控告警，最強大的就是告警功能，可支持多種告警方式，但缺點是沒有強大的數據收集機制，而且數據出圖也很簡陋，當監控的主機愈來愈多時，添加主機也很是麻煩，配置文件都是基於文本配置的，不支持web方式管理和配置，這樣很容易出錯，不宜維護。

三、Zabbix

        zabbix是一個基於WEB界面的提供分佈式系統監視以及網絡監視功能的企業級的開源解決方案。zabbix能監視各類網絡參數，保證服務器系統的安全運營；並提供強大的通知機制以讓系統運維人員快速定位/解決存在的各類問題。

        zabbix由2部分構成，zabbix server與可選組件zabbix agent。zabbix server能夠經過SNMP，zabbix agent，ping，端口監視等方法提供對遠程服務器/網絡狀態的監視，數據收集等功能，它能夠運行在Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X等平臺上。

        zabbix解決了cacti沒有告警的不足，也解決了nagios不能經過web配置的缺點，同時還支持分佈式部署，這使得它迅速流行起來，zabbix也成爲目前中小企業監控最流行的運維監控平臺。

        固然，zabbix也有不足之處，它消耗的資源比較多，若是監控的主機很是多時，可能會出現監控超時、告警超時等現象，不過也有不少解決辦法，好比提升硬件性能、改變zabbix監控模式等。

四、Ganglia

        Ganglia是一款爲HPC（高性能計算）集羣而設計的可擴展的分佈式監控系統，它能夠監視和顯示集羣中的節點的各類狀態信息，它由運行在各個節點上的gmond守護進程來採集CPU 、內存、硬盤利用率、I/O負載、網絡流量狀況等方面的數據，而後彙總到gmetad守護進程下，使用rrdtool存儲數據，最後將歷史數據以曲線方式經過PHP頁面呈現。

        Ganglia監控系統有三部分組成，分別是gmond、gmetad、webfrontend。gmond安裝在須要收集數據的客戶端，gmetad是服務端，webfrontend是一個php的web ui界面，ganglia經過gmond收集數據，而後在webfrontend進行展現。

        ganglia的主要特徵是收集數據，並集中展現數據，這是ganglia的優點和特點，ganglia能夠將全部數據彙總到一個界面集中展現，而且支持多種數據接口，能夠很方面的擴展監控，同時，最爲重要的是，ganglia收集數據很是輕量級，客戶端的gmond程序基本不耗費系統資源，而這個特色恰好彌補了zabbix消耗性能的不足。

        最後，ganglia在對大數據平臺的監控更爲智能，只須要一個配置文件，便可開通ganglia對hadoop、spark的監控，監控指標有近千個，徹底知足了對大數據平臺的監控需求。

五、Centreon

        Centreon是一款功能強大的分佈式IT監控系統，它經過第三方組件能夠實現對網絡、操做系統和應用程序的監控：首先，它是開源的，咱們能夠無償使用它； 其次，它的底層採用相似nagios的監控引擎做爲監控軟件，同時監控引擎經過ndoutil模塊將監控到的數據定時寫入數據庫中，而Centreon實時從數據庫讀取該數據並經過Web界面展示監控數據； 最後，咱們能夠經過Centreon web一鍵管理和配置主機，或者說Centreon就是nagios的一個管理配置工具，經過Centreon提供的Web配置界面，能夠輕鬆完成nagios須要手工配置主機和服務的不足。

        centreon的強項是一鍵配置和管理，並支持分佈式監控，nagios可以完成的功能，經過centreon都能實現，同時，centreon還能夠和ganglia進行集成，centreon將ganglia收集到的數據進行整合，能夠實現主機自動加入監控以及自動告警的功能。

 六、Prometheus

        Prometheus是一套開源的系統監控報警框架，它既適用於面向服務器等硬件指標的監控，也適用於高動態的面向服務架構的監控。對於如今流行的微服務，Prometheus的多維度數據收集和數據篩選查詢語言也是很是的強大。Prometheus是爲服務的可靠性而設計的，當服務出現故障時，它可使你快速定位和診斷問題。

七、Grafana

        Grafana是一個開源的度量分析與可視化套件，通俗的說，Grafana就是一個圖形可視化展現平臺，它經過各類炫酷的界面效果展現咱們的監控數據。 若是你以爲zabbix的出圖界面不夠好看，逼格不夠高，就可使用Grafana的可視化展現，同時，Grafana支持許多不一樣的數據源，Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch和KairosDB均可以完美支持。

八、對比圖

2、統一運維監控平臺設計思路

        運維監控平臺不是簡單的下載一個開源工具，而後搭建起來就好了，它須要根據監控的環境和特色進行各類整合和二次開發，以達到與本身的需求徹底吻合的程度。那麼下面就談談運維監控平臺的設計思路。

        構建一個智能的運維監控平臺，必須以運行監控和故障報警這兩個方面爲重點，將全部業務系統中所涉及的網絡資源、硬件資源、軟件資源、數據庫資源等歸入統一的運維監控平臺中，並經過消除管理軟件的差異，數據採集手段的差異，對各類不一樣的數據來源實現統一管理、統一規範、統一處理、統一展示、統一用戶登陸、統一權限控制，最終實現運維規範化、自動化、智能化的大運維管理。

智能的運維監控平臺，設計架構從低到高能夠分爲6層，三大模塊，以下圖：

 

數據收集層：位於最底層，主要收集網絡數據、業務系統數據、數據庫數據、操做系統數據等，而後將收集到的數據進行規範化並進行存儲。

數據展現層：位於第二層，是一個Web展現界面，主要是將數據收集層獲取到的數據進行統一展現，展現的方式能夠是曲線圖、柱狀圖、餅狀態等，經過將數據圖形化，能夠幫助運維人員瞭解一段時間內主機或網絡的運行狀態和運行趨勢，並做爲運維人員排查問題或解決問題的依據。

數據提取層：位於第三層，主要是對從數據收集層獲取到的數據進行規格化和過濾處理，提取須要的數據到監控報警模塊，這個部分是監控和報警兩個模塊的銜接點。

報警規則配置層：位於第四層，主要是根據第三層獲取到的數據進行報警規則設置、報警閥值設置、報警聯繫人設置和報警方式設置等。

報警事件生成層：位於第五層，主要是對報警事件進行實時記錄，將報警結果存入數據庫以備調用，並將報警結果造成分析報表，以統計一段時間內的故障率和故障發生趨勢。

用戶展現管理層：位於最頂層，是一個Web展現界面，主要是將監控統計結果、報警故障結果進行統一展現，並實現多用戶、多權限管理，實現統一用戶和統一權限控制。

在這6層中，從功能實現劃分，又分爲三個模塊，分別是數據收集模塊、數據提取模塊和監控報警模塊，每一個模塊完成的功能以下：

數據收集模塊：此模塊主要完成基礎數據的收集與圖形展現。數據收集的方式有不少種，能夠經過SNMP實現，也能夠經過代理模塊實現，還能夠經過自定義腳本實現。經常使用的數據收集工具備Cacti、Ganglia等。

數據提取模塊：此模板主要完成數據的篩選過濾和採集，將須要的數據從數據收集模塊提取到監控報警模塊中。能夠經過數據收集模塊提供的接口或自定義腳本實現數據的提取。

監控報警模塊：此模塊主要完成監控腳本的設置、報警規則設置，報警閥值設置、報警聯繫人設置等，並將報警結果進行集中展示和歷史記錄。常見的監控報警工具備Nagios、Centreon等。

在瞭解了運維監控平臺的通常設計思路以後，接下來詳細介紹下如何經過軟件實現這樣一個智能運維監控系統。

下圖是根據上圖的設計思路造成的一個運維監控平臺實現拓撲圖，從圖中能夠看出，主要有三大部分組成，分別是數據收集模塊、監控報警模塊和數據提取模塊。

其中，數據提取模塊用於其餘兩個模塊之間的數據通訊，而數據收集模塊能夠有一臺或多臺數據收集服務器組成，每一個數據收集服務器能夠直接從服務器羣組收集各類數據指標，通過規範數據格式，最終將數據存儲到數據收集服務器中。

監控報警模塊經過數據抽取模塊從數據收集服務器獲取須要的數據，而後設置報警閥值、報警聯繫人等，最終實現實時報警。報警方式支持手機短信報警、郵件報警等，另外，也能夠經過插件或者自定義腳原本擴展報警方式。這樣一整套監控報警平臺就基本實現了。

3、企業運維監控平臺選型

一、中小企業監控平臺選擇Zabbix

Zabbix是一款綜合了數據收集、數據展現、數據提取、監控報警配置、用戶展現等方面的一款綜合運維監控平臺。

Zabbix學習入門較快，功能也很強大，是一個能夠迅速用起來的監控軟件，可以知足中小企業的監控報警需求，所以是中小型企業運維監控的首選平臺。可是，Zabbix當監控服務器數量較多時，會產生不少問題，如監控數據不許確、報警超時等等問題，這是由於Zabbix對服務器性能要求較高，當監控的服務器數量超過500臺後，監控性能急劇降低，此時須要進行分佈式監控部署，而且須要提高監控服務器的性能。

安全性方面，Zabbix客戶端的agent若是故障，收集到的數據將丟失，同時Zabbix Server也是單點，可能還須要對Zabbix Server作HA保證數據的安全和監控的高可用。

二、互聯網大企業監控平臺選擇 Ganglia+Centreon

開源監控軟件組合應用+二次開發是大型互聯網企業構建監控平臺的一個基本策略，對於有海量服務器、多業務系統的複雜監控，沒有哪一個軟件能獨立完成企業的全部監控需求，所以，多種開源監控軟件組合應用+二次開發纔是監控平臺的最終方向。

推薦ganglia是由於ganglia客戶端軟件對服務資源佔用很是低，而且擴展插件很是多，監控擴展也很是容易，同時結合專業的web監控平臺centreon，能夠實如今數據收集、數據展現、數據提取、監控報警配置、用戶展現等方面的完美配合，所以這裏對海量服務器進行監控咱們推薦ganglia+centreon組合。

4、說說咱們運維監控平臺的演變歷程

這是一個經驗和總結，我結合這麼多年咱們監控平臺的演變，總結了一下不一樣階段、不一樣機器數量，監控平臺須要的構建思路和策略。

一、機器數量小於100臺的階段

這個時期因爲機器數量較少，所以，對監控的需求也很簡單，監控的用途可能主要用於通知問題、快速定位與解決問題，大體總結一下，此階段監控平臺的特色以下：

（1）、部署簡單，上手易用
（2）、穩定運行，不出故障
（3）、可進行報警，以郵件、短信等形式

基於以上特色和需求，可使用比較流行開源的監控軟件Nagios，Cacti，Zabbix，Ganglia等等。流行的開源產品文檔不少，可快速上手，而且有大量的前人使用經驗，遇到問題也很容易解決。

最初咱們選擇了nagios，由於這款軟件是最先流行的，後來由於主機和服務添加不方便，切換到了zabbix上了，此階段，zabbix應該是最好的選擇。

二、機器數量200到1000的階段

這個階段，因爲機器數量變多，監控需求也開始變得複雜，不過主要仍是用於通知、告警，發現問題，並避免一樣的問題再次發生，根據這個階段的特色，咱們在這個時期主要對監控平臺作了如下工做：

1）監控內容分類：因爲要監控的機器不少，監控內容也隨之增多，因而咱們將監控根據用途不一樣，進行了分類，主要分爲系統基礎監控數據、網絡監控數據和業務監控數據。

2）全覆蓋式監控：將全部機器均歸入監控中，主要包含軟件監控和硬件監控，硬件監控主要是監控硬件性能和故障，軟件監控除了第一步提到的各類基礎監控數據外，還增長了業務邏輯監控，儘量的覆蓋業務流程，經過大量自定義監控減小和去除重複的問題，保障業務穩定運行。

3）多種告警方式，確保無漏報：將全部監控根據重要程度、緊急程度進行分類，分別用郵件，微信，短信，電話等不一樣級別的方式進行通知，每一個監控對應到不一樣的人，確保每一個監控都有人處理，而且對於重要的業務採用持續通知的方式，不處理就一直通知。

這個階段的難點是對告警信息的處理，因爲機器愈來愈多，須要監控的服務也愈來愈多，告警信息就出現了爆發式增加，天天收到上千封報警郵件是常常的事情。 過多的郵件出現，其實就失去了告警的意義，由於咱們不可能去查看每一封郵件，而這麼多告警郵件中，不少都是非必要的告警，例如系統負載偶爾增高一下，就發了告警郵件，這徹底是不須要的。

所以，這個階段，主要是對監控告警策略進行配置和優化，儘可能減小沒必要要的告警郵件，例如，對系統負載的監控，能夠選擇連續幾回負載超過閥值，而後持續多久以後才進行告警操做，經過對告警策略的優化，告警信息大大減小，天天最多幾十封，這樣的話，就不會錯過任何告警信息了。

（1）告警不及時

當咱們服務器超過1000臺之後，咱們的zabbix就常常罷工，有時候監控數據不能及時顯示，有時候告警遲遲不來，特別是告警延時，這個是最恐怖的事情，線上業務7*24小時不能出現故障，雖然監控到了異常，可是經過監控系統發出來已是1個或者幾個小時以後了，那監控還有什麼意義呢，及時性是監控系統的第一要求，這個是必需要解決的問題。

如何解決這個問題呢，除了對監控進行優化，例如分佈式proxy方式部署，開啓zabbix主動模式，還對數據收集進行了擴展和優化，咱們對基礎數據的收集，拋棄了zabbix來實現，而採用ganglia，而對業務數據部分實現仍然採用zabbix完成，經過將收集數據的負載進行分擔，大大減低了zabbix的負載，數據收集的準確性，及時性又恢復正常了。

（2）告警系統出現了單點故障

因爲服務器衆多，收集的數據也飛速增加，曾經有一次，監控服務器忽然意外宕機了，等系統恢復啓動起來，已是一個小時之後了，這一個小時運維就變成了睜眼瞎了，多可怕的事情。

自從發生監控系統宕機事故後，咱們對監控服務器進行了分佈式高可用部署，以免單點故障，同時對監控到的數據進行遠程異地備份，當監控服務器故障後，會自動切換到備用監控系統上，而且監控數據自動保存同步。

（3）告警需求監控系統沒法知足

業務的增長，客戶對業務穩定性要求變得更加苛刻，爲了保證業務系統穩定運行，業務邏輯監控需求被提出來了，業務邏輯監控就是對業務系統的運行邏輯進行監控，當業務運行邏輯故障時候，也須要進行告警，很顯然，對業務邏輯的監控，沒有現成的工具和代碼，只能根據業務邏輯自行開發，經過提升業務邏輯接口，彙報數據等方式，咱們對zabbix進行了多項二次開發，以知足對業務邏輯的監控。

最後，運維監控平臺是運維工做中不可或缺的一部分，如何構建適合本身的運維監控平臺，每一個公司的需求不同，每一個運維面對的痛點也不盡相同，但，無論有什麼需求，多少需求，萬變不離其宗，有了機器上的各類監控數據，運維就能作不少事情。運維監控的路上，咱們一塊兒前行。

 

做者：南非螞蟻 來源：http://blog.51cto.com/ixdba/2310782