運維必知必會的監控知識體系全梳理總結

監控是整個運維乃至整個產品生命週期中最重要的一環，事前及時預警發現故障，事後提供詳實的資料用於追查定位問題。

目前業界有很多不錯的開源產品可供選擇。選擇一款開源的監控系統，是一個省時省力、效率最高的方案。當然，對監控不是很明白的朋友們，看了以下文章可能會對監控整個體系有比較深刻的認識。

一、監控目標

每個人由於所在的行業、公司、業務、崗位不同，對監控的理解也不盡相同，但是我們需要注意，監控是需要站在公司的業務角度去考慮，而不是針對某個監控技術的使用。

1. 對系統不間斷的實時監控：實際上是對系統不間斷的實時監控(這就是監控)；

2. 實時反饋系統當前狀態：我們監控某個硬體、或者某個系統，都是需要能實時看到當前系統的狀態，是正常、異常、或者故障。

3. 保證服務可靠性安全性：我們監控的目的就是要保證系統、服務、業務正常執行

4. 保證業務持續穩定執行：如果我們的監控做得很完善，即使出現故障，能第一時間接收到故障報警，在第一時間處理解決，從而保證業務持續性的穩定執行。

二、監控方法

1. 瞭解監控物件： 我們要監控的物件你是否瞭解呢？比如CPU到底是如何工作的？

2. 效能基準指標：我們要監控這個東西的什麼屬性？比如CPU的使用率、負載、使用者態、核心態、上下文切換。

3. 報警閾值定義：怎麼樣才算是故障，要報警呢？比如CPU的負載到底多少算高，使用者態、核心態分別跑多少算高？

4. 故障處理流程：收到了故障報警，我們怎麼處理呢？有什麼更高效的處理流程嗎？

三、監控核心

1. 發現問題：當系統發生故障報警，我們會收到故障報警的資訊。

2. 定位問題：故障郵件一般都會寫某某主機故障、具體故障的內容，我們需要對報警內容進行分析。比如一臺伺服器連不上，我們就需要考慮是網路問題、還是負載太高導致長時間無法連線，又或者某開發觸發了防火牆禁止的相關策略等，我們就需要去分析故障具體原因。

3. 解決問題：當然我們瞭解到故障的原因後，就需要通過故障解決的優先順序去解決該故障。

4. 總結問題：當我們解決完重大故障後，需要對故障原因以及防範進行總結歸納，避免以後重複出現。

四、監控工具

下面我們需要選擇一款適合公司業務的監控工具進行監控,。這裡我對監控工具進行了簡單的分類。

1、老牌監控

• MRTG（Multi Route Trffic Grapher）是一套可用來繪製網路流量圖的軟體，由瑞士奧爾滕的Tobias Oetiker與Dave Rand所開發，以GPL授權。

  MRTG最好的版本是1995年推出的，用Perl語言寫成，可跨平臺使用，資料採集用SNMP協議，MRTG將手機到的資料通過Web頁面以GIF或者PNG格式繪製出影象。

• Ganglia是一個跨平臺的、可擴充套件的、高效能的分散式監控系統，如叢集和網格。它基於分層設計，使用廣泛的技術，用RRDtool儲存資料。具有視覺化介面，適合對叢集系統的自動化監控。其精心設計的資料結構和演算法使得監控端到被監控端的連線開銷非常低。目前已有成千上萬的叢集正在使用這個監控系統，可以輕鬆地處理2000個節點的叢集環境。

• Cacti（英文含義為仙人掌）是一套基於PHP、MySQL、SNMP和RRDtool開發的網路流量監測圖形分析工具，它通過snmpget來獲取資料使用RRDtool繪圖，但使用者無須瞭解RRDtool複雜的引數。提供了非常強大的資料和使用者管理功能，可以指定每一個使用者能檢視樹狀結構、主機裝置以及任何一張圖，還可以與LDAP結合進行使用者認證，同時也能自定義模板。在歷史資料展示監控方面，其功能相當不錯。

  Cacti通過新增模板，使不同裝置的監控新增具有可複用性，並且具備可自定義繪圖的功能，具有強大的運算能力（資料的疊加功能）

• Nagios是一個企業級監控系統，可監控服務的執行狀態和網路資訊等，並能監視所指定的本地或遠端主機狀態以及服務，同時提供異常告警通知功能等。

  Nagios可執行在Linux和UNIX平臺上。同時提供Web介面，以方便系統管理人員檢視網路狀態、各種系統問題、以及系統相關日誌等。

  Nagios的功能側重於監控服務的可用性，能根據監控指標狀態觸發告警。

  目前Nagios也佔領了一定的市場份額，不過Nagios並沒有與時俱進，已經不能滿足於多變的監控需求，架構的擴充套件性和使用的便捷性有待增強，其高階功能整合在商業版Nagios XI中。

• Smokeping主要用於監視網路效能，包括常規的ping、www伺服器效能、DNS查詢效能、SSH效能等。底層也是用RRDtool做支援，特點是繪製圖非常漂亮，網路丟包和延遲用顏色和陰影來標示，支援將多張圖疊放在一起，其作者還開發了MRTG和RRDtll等工具。 Smokeping的站點為：http://tobi.oetiker.cn/hp。

• 開源監控系統OpenTSDB用HBase儲存所有時序（無須取樣）的資料，來構建一個分散式、可伸縮的時間序列資料庫。它支援秒級資料採集，支援永久儲存，可以做容量規劃，並很容易地接入到現有的告警系統裡。OpenTSDB可以從大規模的叢集（包括叢集中的網路裝置、作業系統、應用程式）中獲取相應的採集指標，並進行儲存、索引和服務，從而使這些資料更容易讓人理解，如Web化、圖形化等。

2、王牌監控

• Zabbix是一個分散式監控系統，支援多種採集方式和採集客戶端，有專用的Agent代理，也支援SNMP、IPMI、JMX、Telnet、SSH等多種協議，它將採集到的資料存放到資料庫，然後對其進行分析整理，達到條件觸發告警。其靈活的擴充套件性和豐富的功能是其他監控系統所不能比的。相對來說，它的總體功能做得非常優秀。

  從以上各種監控系統的對比來看，Zabbix都是具有優勢的，其豐富的功能、可擴充套件的能力、二次開發的能力和簡單易用的特點，讀者只要稍加學習，即可構建自己的監控系統。

• 小米的監控系統：Open-Falcon。Open-Falcon的目標是做最開放、最好用的網際網路企業級監控產品。

3、三方監控

現在市場上有很多不錯的第三方監控，比如：監控寶、監控易、聽雲、還有很多雲廠商自帶監控，但在這裡我不打算著重介紹，如果想了解三方監控可自行上官網諮詢。（避免說廣告植入）

五、監控流程

上面介紹了這麼多，到底選擇什麼監控工具最合適呢？我這裡推薦幾款開源監控工具：Zabbix、Open-Falcon、LEPUS天兔(專用於監控資料庫)。

但本文還是基於Zabbix來構建整個監控體系生態圈。 下面我們就來聊聊Zabbix的整個流程：

1. 資料採集：Zabbix通過SNMP、Agent、ICMP、SSH、IPMI等對系統進行資料採集；

2. 資料儲存：Zabbix儲存在MySQL上，也可以儲存在其他資料庫服務；

3. 資料分析：當我們事後需要覆盤分析故障時，Zabbix能給我們提供圖形以及時間等相關資訊，方面我們確定故障所在；

4. 資料展示：Web介面展示、(移動APP、java_php開發一個Web介面也可以)；

5. 監控報警：電話報警、郵件報警、微信報警、簡訊報警、報警升級機制等（無論什麼報警都可以）；

6. 報警處理：當接收到報警，我們需要根據故障的級別進行處理，比如:重要緊急、重要不緊急，等。根據故障的級別，配合相關的人員進行快速處理。

六、監控指標

上面瞭解了監控方法、目標、流程、也瞭解了監控有哪些工具，可能有人會疑惑，我們具體要監控些什麼東西，在這裡我進行了分類整理，包含硬體監控、系統監控、應用監控、網路監控、流量分析、日誌監控、安全監控、API監控、效能監控、業務監控。

1、硬體監控

早期我們通過機房巡檢的方式，檢視硬體裝置燈光閃爍情況判斷是否故障，這樣非常浪費人力，並且是重複性無技術含量的工作，大家懂得。

當然我們現在可以通過IPMI對硬體詳細情況進行監控，並對CPU、記憶體、磁碟、溫度、風扇、電壓等設定報警設定報警閾值(自行對監控報警內容編寫合理的報警範圍) 。

IPMI監控硬體服務參考資料：Zabbix IPMI Interface

2、系統監控

中小型企業基本全是Linux伺服器，那麼我們肯定是要監控起系統資源的使用情況，系統監控是監控體系的基礎。

監控主要物件：

CPU有幾個重要的概念：上下文切換、執行佇列和使用率。這也是我們CPU監控的幾個重點指標。

通常情況，每個處理器的執行佇列不要高於3，CPU 利用率中用“戶態/核心態”比例維持在70/30，空閒狀態維持在50%，上下文切換要根據系統繁忙程度來綜合考量。

針對CPU常用的工具有：htop、top、vmstat、mpstat、dstat、glances。Zabbix提供系統監控模板：Zabbix Agent Interface。

CPU整體狀態

上下文切換

負載狀態

記憶體：通常我們需要監控記憶體的使用率、SWAP使用率、同時可以通過Zabbix描繪記憶體使用率的曲線圖形發現某服務記憶體溢位等。

針對記憶體常用的工具有：free、top、vmstat、glances。

記憶體使用率

IO分為磁碟IO和網路IO。除了在做效能調優我們要監控更詳細的資料外，日常監控只關注磁碟使用率、磁碟吞吐量、磁碟寫入繁忙程度，網路也是監控網路卡流量即可。常用工具有：iostat、iotop、df、iftop、sar、glances。

磁碟使用率

磁碟讀/寫吞吐

網路卡進出口流量

TCP11種狀態資訊

其它系統監控還有執行的程式埠、程式數、登陸使用者、Open File等（詳細檢視Zabbix自帶OS Linux模板）。

其它相關監控

3、應用監控

把硬體監控和系統監控研究明白後，我們進一步操作是需要登陸到伺服器上檢視伺服器執行了哪些服務，都需要監控起來。

應用服務監控也是監控體系中比較重要的內容，例如： LVS、HAProxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、RabbitMQ等，相關的服務都需要使用zabbix監控起來。

nginx_status

PHP-FPM_status

Redis_status

JVM監控

筆者之前寫過服務監控詳細的操作過程，這裡就不一一展示，詳情訪問：Zabbix監控各種應用服務。

• Zabbix提供應用服務監控：Zabbix Agent UserParameter

• Zabbix提供的Java監控：Zabbix JMX Interface

• Percona提供MySQL資料庫監控：percona-monitoring-plulgins

4、網路監控

作為一個針對全國使用者的電商網站，時刻掌握各地到機房的網路狀態也是必須的。

網路監控是我們構建監控平臺是必須要考慮的，尤其是針對有多個機房的場景，各個機房之間的網路狀態，機房和全國各地的網路狀態都是我們需要重點關注的物件，那如何掌握這些狀態資訊呢？我們需要藉助於網路監控工具Smokeping。

Smokeping 是rrdtool的作者Tobi Oetiker的作品，是用Perl寫的，主要是監視網路效能，www伺服器效能，DNS查詢效能等，使用rrdtool繪圖，而且支援分散式，直接從多個agent進行資料的彙總。

同時，由於自己監控點比較少，還可以藉助很多商業的監控工具，比如監控寶、基調、博瑞等。同時這些服務提供商還可以幫助你監控CDN的狀態。

smokeping

監控寶

5、流量分析

網站流量分析對於運維人員來說，更是一門必須掌握的知識了。比如對於一家電商公司來說：通過對訂單來源的統計和分析，可以瞭解我們在某個網站上的廣告投入有沒有收到預期的效果。 可以區分不同地區的訪問人數、甚至商品交易額等。百度統計、Google分析、站長工具等，只需要在頁面嵌入一個js即可。

但是，資料始終是在對方手中，個性化定製不方便，於是Google出一個叫Piwik的開源分析工具。

piwik

百度統計

6、日誌監控

通常情況下，隨著系統的執行，作業系統會產生系統日誌，應用程式會產生應用程式的訪問日誌、錯誤日誌，執行日誌，網路日誌，我們可以使用ELK來進行日誌監控。

對於日誌監控來說，最見的需求就是收集、儲存、查詢、展示，開源社群正好有相對應的開源專案：Logstash（收集）+ElasticSearch（儲存+搜尋）+Kibana（展示）。

我們將這三個組合起來的技術稱之為ELK Stack，所以說ELK Stack指的是Elasticsearch、Logstash、Kibana技術棧的結合。

如果收集了日誌資訊，部署更新有異常出現，可以立即在Kibana上看到。

ELK日誌展示

當然也可以通過Zabbix過濾錯誤日誌來進行告警。

Zabbix日誌展示

7、安全監控

雖然Linux開源的安全產品不少，比如四層iptables，七層WEB防護Nginx+Lua實現WAF，最後將相關的日誌都收至ELkstack，通過圖形化進行不同的攻擊型別展示。但是始終是一件比較耗費時間，並且個人效果並不是很好。這個時候我們可以選擇接入第三方服務廠商。

某某三方安全

三方廠商提供全面的漏洞庫，涵蓋服務、後門、資料庫、配置檢測、CGI、SMTP等多種型別。

全面檢測主機、Web應用漏洞自主挖掘和行業共享相結合第一時間更新0-day漏洞，杜絕最新安全隱患。

8、API監控

由於API變得越來越重要，很顯然我們也需要這樣的資料來分辨我們提供的 API是否能夠正常運作。

監控API介面GET、POST、PUT、DELETE、HEAD、OPTIONS的請求。可用性、正確性、響應時間為三大重效能指標。

API監控

三方API監控

響應時間

9、效能監控

全面監控網頁效能，DNS響應時間、HTTP建立連線時間、頁面效能指數、響應時間、可用率、元素大小等。Zabbix提供URL監控：Zabbix Web 監控。

Zabbix站點監控

終端響應時間

第三方監控監控大盤。各類圖表一目瞭然，全面體現網頁效能健康狀況。

10、業務監控

沒有業務指標監控的監控平臺，不是一個完善的監控平臺，通常在我們的監控系統中，必須將我們重要的業務指標進行監控，並設定閾值進行告警通知。比如電商行業：

每分鐘產生多少訂單、每分鐘註冊多少使用者、每天有多少活躍使用者、每天有多少推廣活動、推廣活動引入多少使用者、推廣活動引入多少流量、推廣活動引入多少利潤等，重要指標都可以加入Zabbix上，然後通過Screen展示。

注：由於業務監控圖表，涉及到隱私的資料太多，就不截圖了。

七、監控報警

故障報警通知的方式有很多種，當然最常用的還是簡訊和郵件。

簡訊報警

郵件報警

八、報警處理

一般報警後故障如何處理，首先我們可以通過告警升級機制先自動處理，比如Nginx服務down了，可以設定告警升級自動啟動Nginx。

但是如果一般業務出現了嚴重故障，我們通常根據故障的級別、業務，來指派不同的運維人員進行處理。 當然不同業務形態、不同架構、不同服務可能採用的方式都不同，這個沒有一個固定的模式套用。

九、面試監控

在運維面試中，常常會被問題監控相關的問題，這個問題到底該如何來回答，我針對本文給大家提供了一個簡單的回答思路。

1、硬體監控

通過SNMP來進行路由器交換機的監控(這些可以跟一些廠商溝通來了解如何做)、伺服器的溫度以及其它，可以通過IPMI來實現。當然如果沒有硬體全都是雲，直接跳過這一步驟。

2、系統監控

如CPU的負載，上下文切換、記憶體使用率、磁碟讀寫、磁碟使用率、磁碟inode使用率。當然這些都是需要配置觸發器，因為預設太低會頻繁報警。

3、服務監控

比如公司用的LNMP架構，Nginx自帶Status模組、PHP也有相關的Status、MySQL的話可以通過Percona官方工具來進行監控。Redis這些通過自身的info獲取資訊進行過濾等。方法都類似。要麼服務自帶。要麼通過指令碼來實現想監控的內容，以及報警和圖形功能。

4、網路監控

如果是雲主機又不是跨機房，那麼可以選擇不監控網路。當然你說我們是跨機房以及如何如何，推薦使用smokeping來做網路相關的監控，或者直接交給你們的網路工程師來做，因為術業有專攻。

5、安全監控

如果是雲主機可以考慮使用自帶的安全防護。當然也可以使用iptables。如果是硬體，那麼推薦使用硬體防火牆。使用雲可以購買防DDOS，避免出現故障導致down機一天。如果是系統，那麼許可權、密碼、備份、恢復等基礎方案要做好。Web同時也可以使用Nginx+Lua來實現一個Web層面的防火牆。當然也可以使用整合好的OpenResty。

6、Web監控

Web監控的話題其實還是很多。比如可以使用自帶的Web監控來監控頁面相關的延遲、js響應時間、下載時間、等等。這裡我推薦使用專業的商業軟體監控寶或聽雲來實現。畢竟人家全國各地都有機房（如果本身是多機房那就另說了）。

7、日誌監控

如果是Web的話可以使用監控Nginx的50x、40x的錯誤日誌，PHP的ERROR日誌。其實這些需求無非是，收集、儲存、查詢、展示，我們其實可以使用開源的ELKStack來實現。Logstash（收集）、Elasticsearch（儲存+搜尋）、Kibana（展示）。

8、業務監控

上面做了那麼多，其實最終還是保證業務的執行。這樣我們做的監控才有意義。所以業務層面這塊的監控需要和開發以及總監開會討論，監控比較重要的業務指標，（需要開會確認）然後通過簡單的指令碼就可以實現，最後設定觸發器即可 。

9、流量分析

平時我們分析日誌都是拿awk sed xxx一堆工具來實現。這樣對我們統計IP、PV、UV不是很方便。那麼可以使用百度統計、Google統計、商業，讓開發嵌入程式碼即可。為了避免隱私也可以使用Piwik來做相關的流量分析。

10、視覺化

通過Screen以及引入一些第三方的庫來美化介面，同時我們也需要知道，訂單量突然增加、突然減少。或者說突然來了一大波流量，這流量從哪兒來，是不是推廣了，還是被攻擊了。可以結合監控平來梳理各個系統之間的業務關係。

11、自動化監控

如上我們做了那麼多的工作，當然不能是一臺一臺的來加key實現。可以通過Zabbix的主動模式以及被動模式來實現。當然最好還是通過API來實現。

總結

真正想做到更完整的監控體系，目前的開源軟體確實無法很好地滿足，有條件的公司都開始自己開發自己的監控系統，比如小米開源的Open-Falcon。

也有比較好的開源的監控框架如Sensu等，再加上InfluxDB、Grafana可以用來定製符合自己企業的監控平臺。

當然我說的還是很簡單，經驗有限、思路也僅能提供這麼多。希望能對你有所幫助。