運維行業有句話：“無監控、不運維”，是的，一點也不誇張，監控俗稱“第三隻眼”。沒了監控，什麼基礎運維，業務運維都是“瞎子”。所以說監控是運維這個職業的根本。尤其是在現在DevOps這麼火的時候，用監控數據給自己撐腰，這顯得更加必要，有人說運維是背鍋俠，那麼，有了監控，有了充足的數據，一切以數據說話，運維還需要背鍋嗎，所以作爲一個運維工程師，如何構建一套監控系統是你的第一件工作。
在開篇之前，讓我們以全局的眼光，探討一下運維監控工具如何選型以及構建運維監控平臺的設計思路，如果你是剛剛入行運維這個職業，那麼這個專欄非常適合你，如果你已經在運維職場深耕多年，那麼也能幫助你開闊思路和眼界。
一、常見的運維監控工具
現在運維監控工具非常多，哪個好，哪個不好，哪個適合你，哪個不適合你，其實只有你瞭解了他們的特性後，才知道，所以從這裏開始講起。
1、Cacti
Cacti是一套基於PHP,MySQL,SNMP及RRDTool開發的網絡流量監測圖形分析工具。
簡單的說Cacti就是一個PHP程序。它通過使用SNMP協議獲取遠端網絡設備和相關信息，（其實就是使用Net-SNMP 軟件包的snmpget 和snmpwalk 命令獲取）並通過RRDTOOL工具繪圖，通過PHP程序展現出來。我們使用它可以展現出監控對象一段時間內的狀態或者性能趨勢圖。
cacti是很老的一款監控工具了，其實說它是一款流量監控工具更合適，對流量監控比較精準，但缺點很多，出圖不好看，不支持分佈式，也沒有告警功能，所以使用的人會越來越少。
2、Nagios
Nagios是一款開源的免費網絡監視工具，能有效監控Windows、Linux和Unix的主機狀態，交換機路由器等網絡設置，打印機等。在系統或服務狀態異常時發出郵件或短信報警第一時間通知網站運維人員，在狀態恢復後發出正常的郵件或短信通知。
nagios主要的特徵是監控告警，最強大的就是告警功能，可支持多種告警方式，但缺點是沒有強大的數據收集機制，並且數據出圖也很簡陋，當監控的主機越來越多時，添加主機也非常麻煩，配置文件都是基於文本配置的，不支持web方式管理和配置，這樣很容易出錯，不宜維護。
3、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監控模式等。
4、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的監控，監控指標有近千個，完全滿足了對大數據平臺的監控需求。
5、Centreon
Centreon是一款功能強大的分佈式IT監控系統，它通過第三方組件可以實現對網絡、操作系統和應用程序的監控：首先，它是開源的，我們可以免費使用它；其次，它的底層採用類似nagios的監控引擎作爲監控軟件，同時監控引擎通過ndoutil模塊將監控到的數據定時寫入數據庫中，而Centreon實時從數據庫讀取該數據並通過Web界面展現監控數據；最後，我們可以通過Centreon web一鍵管理和配置主機，或者說Centreon就是nagios的一個管理配置工具，通過Centreon提供的Web配置界面，可以輕鬆完成nagios需要手工配置主機和服務的不足。
centreon的強項是一鍵配置和管理，並支持分佈式監控，nagios能夠完成的功能，通過centreon都能實現，同時，centreon還可以和ganglia進行集成，centreon將ganglia收集到的數據進行整合，可以實現主機自動加入監控以及自動告警的功能。
6、Prometheus
Prometheus是一套開源的系統監控報警框架，它既適用於面向服務器等硬件指標的監控，也適用於高動態的面向服務架構的監控。對於現在流行的微服務，Prometheus的多維度數據收集和數據篩選查詢語言也是非常的強大。Prometheus是爲服務的可靠性而設計的，當服務出現故障時，它可以使你快速定位和診斷問題。
7、Grafana
Grafana是一個開源的度量分析與可視化套件，通俗的說，Grafana就是一個圖形可視化展示平臺，它通過各種炫酷的界面效果展示我們的監控數據，
如果你覺得zabbix的出圖界面不夠好看，逼格不夠高，就可以使用Grafana的可視化展示，同時，Grafana支持許多不同的數據源，Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch和KairosDB都可以完美支持。
8、對比圖
二、統一運維監控平臺設計思路
運維監控平臺不是簡單的下載一個開源工具，然後搭建起來就行了，它需要根據監控的環境和特點進行各種整合和二次開發，以達到與自己的需求完全吻合的程度。那麼下面就談談運維監控平臺的設計思路。
構建一個智能的運維監控平臺，必須以運行監控和故障報警這兩個方面爲重點，將所有業務系統中所涉及的網絡資源、硬件資源、軟件資源、數據庫資源等納入統一的運維監控平臺中，並通過消除管理軟件的差別，數據採集手段的差別，對各種不同的數據來源實現統一管理、統一規範、統一處理、統一展現、統一用戶登錄、統一權限控制，最終實現運維規範化、自動化、智能化的大運維管理。
智能的運維監控平臺，設計架構從低到高可以分爲6層，三大模塊，如下圖：
數據收集層：位於最底層，主要收集網絡數據、業務系統數據、數據庫數據、操作系統數據等，然後將收集到的數據進行規範化並進行存儲。
數據展示層：位於第二層，是一個Web展示界面，主要是將數據收集層獲取到的數據進行統一展示，展示的方式可以是曲線圖、柱狀圖、餅狀態等，通過將數據圖形化，可以幫助運維人員瞭解一段時間內主機或網絡的運行狀態和運行趨勢，並作爲運維人員排查問題或解決問題的依據。
數據提取層：位於第三層，主要是對從數據收集層獲取到的數據進行規格化和過濾處理，提取需要的數據到監控報警模塊，這個部分是監控和報警兩個模塊的銜接點。
報警規則配置層：位於第四層，主要是根據第三層獲取到的數據進行報警規則設置、報警閥值設置、報警聯繫人設置和報警方式設置等。
報警事件生成層：位於第五層，主要是對報警事件進行實時記錄，將報警結果存入數據庫以備調用，並將報警結果形成分析報表，以統計一段時間內的故障率和故障發生趨勢。
用戶展示管理層：位於最頂層，是一個Web展示界面，主要是將監控統計結果、報警故障結果進行統一展示，並實現多用戶、多權限管理，實現統一用戶和統一權限控制。
在這6層中，從功能實現劃分，又分爲三個模塊，分別是數據收集模塊、數據提取模塊和監控報警模塊，每個模塊完成的功能如下：
數據收集模塊：此模塊主要完成基礎數據的收集與圖形展示。數據收集的方式有很多種，可以通過SNMP實現，也可以通過代理模塊實現，還可以通過自定義腳本實現。常用的數據收集工具有Cacti、Ganglia等。
數據提取模塊：此模板主要完成數據的篩選過濾和採集，將需要的數據從數據收集模塊提取到監控報警模塊中。可以通過數據收集模塊提供的接口或自定義腳本實現數據的提取。
監控報警模塊：此模塊主要完成監控腳本的設置、報警規則設置，報警閥值設置、報警聯繫人設置等，並將報警結果進行集中展現和歷史記錄。常見的監控報警工具有Nagios、Centreon等。
在瞭解了運維監控平臺的一般設計思路之後，接下來詳細介紹下如何通過軟件實現這樣一個智能運維監控系統。
下圖是根據上圖的設計思路形成的一個運維監控平臺實現拓撲圖，從圖中可以看出，主要有三大部分組成，分別是數據收集模塊、監控報警模塊和數據提取模塊，其中，數據提取模塊用於其他兩個模塊之間的數據通信，而數據收集模塊可以有一臺或多臺數據收集服務器組成，每個數據收集服務器可以直接從服務器羣組收集各種數據指標，經過規範數據格式，最終將數據存儲到數據收集服務器中。監控報警模塊通過數據抽取模塊從數據收集服務器獲取需要的數據，然後設置報警閥值、報警聯繫人等，最終實現實時報警。報警方式支持手機短信報警、郵件報警等，另外，也可以通過插件或者自定義腳本來擴展報警方式。這樣一整套監控報警平臺就基本實現了。
三、企業運維監控平臺選型
1、中小企業監控平臺選擇Zabbix
Zabbix是一款綜合了數據收集、數據展示、數據提取、監控報警配置、用戶展示等方面的一款綜合運維監控平臺。
Zabbix學習入門較快，功能也很強大，是一個可以迅速用起來的監控軟件，能夠滿足中小企業的監控報警需求，因此是中小型企業運維監控的首選平臺。但是，Zabbix當監控服務器數量較多時，會產生很多問題，如監控數據不準確、報警超時等等問題，這是因爲Zabbix對服務器性能要求較高，當監控的服務器數量超過500臺後，監控性能急劇下降，此時需要進行分佈式監控部署，並且需要提升監控服務器的性能。
安全性方面，Zabbix客戶端的agent如果故障，收集到的數據將丟失，同時Zabbix Server也是單點，可能還需要對Zabbix Server做HA保證數據的安全和監控的高可用。
2、互聯網大企業監控平臺選擇Ganglia+Centreon
開源監控軟件組合應用+二次開發是大型互聯網企業構建監控平臺的一個基本策略，對於有海量服務器、多業務系統的複雜監控，沒有哪個軟件能獨立完成企業的所有監控需求，因此，多種開源監控軟件組合應用+二次開發纔是監控平臺的最終方向。
推薦ganglia是因爲ganglia客戶端軟件對服務資源佔用非常低，並且擴展插件非常多，監控擴展也非常容易，同時結合專業的web監控平臺centreon，可以實現在數據收集、數據展示、數據提取、監控報警配置、用戶展示等方面的完美配合，因此這裏對海量服務器進行監控我們推薦ganglia+centreon組合。
四、說說我們運維監控平臺的演變歷程
這是一個經驗和總結，我結合這麼多年我們監控平臺的演變，總結了一下不同階段、不同機器數量，監控平臺需要的構建思路和策略。
1、機器數量小於100臺的階段
這個時期由於機器數量較少，因此，對監控的需求也很簡單，監控的用途可能主要用於通知問題、快速定位與解決問題，大致總結一下，此階段監控平臺的特點如下：
（1）、部署簡單，上手易用
（2）、穩定運行，不出故障
（3）、可進行報警，以郵件、短信等形式
基於以上特點和需求，可以使用比較流行開源的監控軟件Nagios，Cacti，Zabbix，Ganglia等等。流行的開源產品文檔很多，可快速上手，並且有大量的前人使用經驗，遇到問題也很容易解決。
最初我們選擇了nagios，因爲這款軟件是最早流行的，後來因爲主機和服務添加不方便，切換到了zabbix上了，此階段，zabbix應該是最好的選擇。
2、機器數量200到1000的階段
這個階段，由於機器數量變多，監控需求也開始變得複雜，不過主要還是用於通知、告警，發現問題，並避免同樣的問題再次發生，根據這個階段的特點，我們在這個時期主要對監控平臺做了以下工作：
（1）、監控內容分類：由於要監控的機器很多，監控內容也隨之增多，於是我們將監控根據用途不同，進行了分類，主要分爲系統基礎監控數據、網絡監控數據和業務監控數據。
（2）、全覆蓋式監控：將所有機器均納入監控中，主要包含軟件監控和硬件監控，硬件監控主要是監控硬件性能和故障，軟件監控除了第一步提到的各種基礎監控數據外，還增加了業務邏輯監控，儘可能的覆蓋業務流程，通過大量自定義監控減少和去除重複的問題，保障業務穩定運行。
（3）、多種告警方式，確保無漏報：將所有監控根據重要程度、緊急程度進行分類，分別用郵件，微信，短信，電話等不同級別的方式進行通知，每個監控對應到不同的人，確保每個監控都有人處理，並且對於重要的業務採用持續通知的方式，不處理就一直通知。
這個階段的難點是對告警信息的處理，由於機器越來越多，需要監控的服務也越來越多，告警信息就出現了爆發式增長，每天收到上千封報警郵件是經常的事情。 過多的郵件出現，其實就失去了告警的意義，因爲我們不可能去查看每一封郵件，而這麼多告警郵件中，很多都是非必要的告警，例如系統負載偶爾增高一下，就發了告警郵件，這完全是不需要的。
因此，這個階段，主要是對監控告警策略進行配置和優化，儘量減少不必要的告警郵件，例如，對系統負載的監控，可以選擇連續幾次負載超過閥值，然後持續多久之後才進行告警操作，通過對告警策略的優化，告警信息大大減少，每天最多幾十封，這樣的話，就不會錯過任何告警信息了。
3、機器數量超過1000臺的階段
由於業務持續增長，對服務器需求越來越多，當我們的服務器超過1000臺以後，監控的情況發生了變化，或者說監控出現了很多奇怪的問題，主要
有如下一些：
（1）、告警不及時
當我們服務器超過1000臺以後，我們的zabbix就經常罷工，有時候監控數據不能及時顯示，有時候告警遲遲不來，特別是告警延時，這個是最恐怖的事情，線上業務7*24小時不能出現故障，雖然監控到了異常，但是通過監控系統發出來已經是1個或者幾個小時之後了，那監控還有什麼意義呢，及時性是監控系統的第一要求，這個是必須要解決的問題。
如何解決這個問題呢，除了對監控進行優化，例如分佈式proxy方式部署，開啓zabbix主動模式，還對數據收集進行了擴展和優化，我們對基礎數據的收集，拋棄了zabbix來實現，而採用ganglia，而對業務數據部分實現仍然採用zabbix完成，通過將收集數據的負載進行分擔，大大減低了zabbix的負載，數據收集的準確性，及時性又恢復正常了。
（2）、告警系統出現了單點故障
由於服務器衆多，收集的數據也飛速增長，曾經有一次，監控服務器突然意外宕機了，等系統恢復啓動起來，已經是一個小時以後了，這一個小時運維就變成了睜眼瞎了，多可怕的事情。
自從發生監控系統宕機事故後，我們對監控服務器進行了分佈式高可用部署，以避免單點故障，同時對監控到的數據進行遠程異地備份，當監控服務器故障後，會自動切換到備用監控系統上，並且監控數據自動保存同步。
（3）、告警需求監控系統無法滿足
業務的增加，客戶對業務穩定性要求變得更加苛刻，爲了保證業務系統穩定運行，業務邏輯監控需求被提出來了，業務邏輯監控就是對業務系統的運行邏輯進行監控，當業務運行邏輯故障時候，也需要進行告警，很顯然，對業務邏輯的監控，沒有現成的工具和代碼，只能根據業務邏輯自行開發，通過提高業務邏輯接口，彙報數據等方式，我們對zabbix進行了多項二次開發，以滿足對業務邏輯的監控。
最後，運維監控平臺是運維工作中不可或缺的一部分，如何構建適合自己的運維監控平臺，每個公司的需求不一樣，每個運維面對的痛點也不盡相同，但，不管有什麼需求，多少需求，萬變不離其宗，有了機器上的各種監控數據，運維就能做很多事情。運維監控的路上，我們一起前行。
技術彩蛋
～～～～～～～～～～～～～～～～～～～～～～～～～～～
說了這麼多，那麼問題來了，怎麼構建一套適合自己的運維監控平臺呢，我將多年來工作經驗進行了總結和提煉，寫成了專欄《無監控，不運維》點擊前往，15篇文章打通運維監控任通二脈，讓經驗說話：
能學到什麼技能
