深入探索監控領域的知識體系

導讀	監控是整個維運乃至整個產品生命週期中最重要的一環，事前及時預警發現故障，事後提供詳盡的數據用於追查定位問題。目前業界有很多不錯的開源產品可供選擇。選擇一款開源的監控系統，是省時省力，效率最高的方案。當然對監控不是很明白的朋友們，看了以下文章可能會對監控整個體係有比較深刻的認知。

1、監控目標

我們先來了解什麼是監控、監控的重要性以及監控的目標，當然每個人所在的行業不同、公司不同、業務不同、職位不同，對監控的理解也不同，但是我們需要注意，監控是需要站在公司的業務角度去考慮，而不是針對某個監控技術的使用。

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

即時回饋系統目前狀態：我們監控某個硬體、或某個系統，都是需要能即時看到目前系統的狀態，是正常、異常、或故障；

保證服務可靠度安全性：我們監控的目的就是要確保系統、服務、業務正常運作；

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

#2、監控方法

既然我們了解到了監控的重要性、以及監控的目的，那麼下面我們需要了解下監控有哪些方法。

了解監控對象：我們要監控的對像你是否了解呢？例如 CPU 到底是如何運作的？

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

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

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

3、監控核心

我們了解了監控的方法、監控對象、效能指標、警報閾值定義、以及故障處理流程幾步驟，當然我們更需要知道監控的核心是什麼？

發現問題：當系統發生故障警報，我們會收到故障警報的訊息 ;

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

解決問題：當然我們了解到故障的原因後，就需要透過故障解決的優先順序去解決該故障；

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

4、監控工具

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

老牌監控工具:

#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化、圖形化等。

王牌監控工具:

#Zabbix 是一個分散式監控系統，支援多種採集方式和採集客戶端，有專用的Agent 代理，也支援SNMP、IPMI、JMX、Telnet、SSH 等多種協議，它將採集到的資料存放到資料庫，然後進行分析整理，達到條件觸發警告。其靈活的擴充性和豐富的功能是其他監控系統所不能比的。相對來說，它的整體功能做的非常優秀。從以上各種監控系統的對比來看，Zabbix 都是具有優勢的，其豐富的功能、可擴展的能力、二次開發的能力和簡單易用的特點，讀者只要稍加學習，即可構建自己的監控系統。

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

三方監控工具：

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

5、監控流程

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

但本文還是基於 Zabbix 來建構整個監控體系生態圈。

那麼下面我們就來聊聊，Zabbix 的整個流程：

資料擷取：Zabbix 透過 SNMP、Agent、ICMP、SSH、IPMI 等對系統進行資料擷取；

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

數據分析：當我們事後需要復盤分析故障時，Zabbix 能為我們提供圖形以及時間等相關信息，方面我們確定故障所在；

資料展示：web 介面展示、(行動 APP、java_php 開發一個 web 介面也可以)；

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

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

6、監控指標

我們上面了解了監控方法、目標、流程、也了解了監控有哪些工具，可能有人會疑惑，我們具體要監控些什麼？那我在這裡進行了分類整理:

6.1 硬體監控

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

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

IPMI監控硬體服務參考資料

6.2 系統監控

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

監控主要物件:

CPU 有幾個重要的概念：上下文切換、運行佇列和使用率。

這也是我們 CPU 監控的幾個重點指標。

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

針對 CPU 常用的工具有：htop、top、vmstat、mpstat、dstat、glances

Zabbix 提供系統監控範本：Zabbix Agent Interface

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

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

記憶體使用率：IO 分為磁碟 IO 和網路 IO。除了在做效能調優我們要監控更詳細的資料外，那麼日常監控，只關注磁碟使用率、磁碟吞吐量、磁碟寫入繁忙程度，網路也是監控網路卡流量即可。

常用工具有：iostat、iotop、df、iftop、sar、glances

其它的系統監控還有運行的進程端口、進程數、登陸用戶、Open File 等（詳細查看 zabbix 自帶 OS Linux 模板） 6.3 應用程式監控

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

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

筆者之前寫過服務監控詳細的操作過程，這裡就不一一展示了。

Zabbix 提供應用程式服務監控：Zabbix Agent UserParameter
Zabbix 提供的Java監控：Zabbix JMX Interface

percona 提供 MySQL 資料庫監控：percona-monitoring-plulgins 6.4 網路監控

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

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

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

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

網站流量分析對於維運人員來說，更是一門必須掌握的知識了。例如對於一家電商公司：

透過對訂單來源的統計和分析，可以了解我們在某個網站上的廣告投入有沒有收到預期的效果。

可以區分不同地區的訪客人數、甚至商品交易額等。

百度統計、google 分析、站長工具等等，只需要在頁面嵌入一個js即可。

但是，資料總是在對方手中，個人化客製化不方便，於是 google 出一個叫 piwik 的開源分析工具 6.6 日誌監控

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

對於日誌監控來說，最見的需求就是收集、儲存、查詢、展示。 ###

開源社群正好有相對應的開源專案： logstash（收集） elasticsearch（儲存 搜尋） kibana（展示）

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

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

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

6.7 安全監控

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

三方廠商提供全面的漏洞庫，涵蓋服務、後門、資料庫、設定偵測、CGI、SMTP 等多種類型

全面偵測主機、Web 應用漏洞自主挖掘和產業共享結合第一時間更新 0day 漏洞，杜絕最新安全隱憂

6.8 API監控

#由於 API 變得越來越重要，很顯然我們也需要這樣的數據來分辨我們提供的 API 是否能夠正常運作。
監控 API 介面 GET、POST、PUT、DELETE、HEAD、OPTIONS 的請求， 可用性、正確性、回應時間為三大重效​​能指標

6.9 效能監控

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

6.10 業務監控

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

例如電商產業：

每分鐘產生多少訂單；

每分鐘註冊多少用戶；

每天有多少活躍用戶；

每天有多少推廣活動；

推廣活動引進多少用戶；

推廣活動引入多少流量；

推廣活動引進多少利潤;

等等 重要指標都可以加到 Zabbix 上，然後透過 screen 展示。

7、監控警報

故障警報通知的方式有很多種，當然我們最常用的還是短信，郵件，短信警報

8、警報處理

一般警報後我們故障如何處理，首先，我們可以透過告警升級機制先自動處理，例如Nginx服務down了，可以設定告警升級自動啟動Nginx。　　但是如果一般業務出現了嚴重故障，我們通常根據故障的級別，故障的業務，來指派不同的運維人員進行處理。　　當然不同業務形態、不同架構、不同服務可能採用的方式都不同，這個沒有一個固定的模式應用。

9、面試監控

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

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

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

服務監控。例如公司用的 LAMP 架構，nginx 自帶 Status 模組、PHP也有相關的 Status、MySQL 可以透過 percona 官方工具來進行監控、Redis 這些透過自身的 info 取得資訊進行過濾等。方法都類似。要么服務自備。要麼透過腳本來實現想監控的內容，以及警報和圖形功能。

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

安全監控。如果是雲端主機可以考慮使用自備的安全防護。當然也可以使用 iptables。如果是硬件，那麼建議使用硬體防火牆。使用雲端可以購買防 DDoS，避免故障導致 down 機一天。如果是系統，那麼權限、密碼、備份、復原等基礎方案要做好。 web 同時也可以使用 Nginx Lua 來實作一個web層面的防火牆。當然也可以使用整合好的Openresty。

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

日誌監控。如果是 web 的話可以使用監控 Nginx 的50x、40x的錯誤日誌，PHP 的 ERROR 日誌。其實這些需求無非是，收集、儲存、查詢、展示，我們其實可以使用開源的 ELKstack 來實現。 Logstash（收集）、elasticsearch（儲存 搜尋）、kibana（展示）
業務監控。我們上面做了那麼多，其實最後還是保證業務的運作。這樣我們做的監控才有意義。所以業務層面這塊的監控需要和開發以及總監開會討論，監控比較重要的業務指標，（需要開會確認）然後通過簡單的腳本就可以實現，最後設置觸發器即可 。

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

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

自動化監控。如上我們做了那麼多的工作，當然不能是一台一台的來加 key 實作。可以透過 Zabbix 的主動模式以及被動模式來實現。當然最好還是透過 API 來實現。
總結

真正想做到更完整的監控體系，目前的開源軟體，確實無法很好的滿足，有條件的公司都開始自己開發自己的監控系統，例如小米開源的Open-Falcon。也有比較好的開源的監控架構如Sensu等，再加上influxdb、grafana可以用來客製化符合自己企業的監控平台。

當然我說的還是很簡單，經驗有限、思路也僅能提供這麼多。　　以上就是我分享一些對監控的方法和心得。 （老鳥勿噴）

以上是深入探索監控領域的知識體系的詳細內容。更多資訊請關注PHP中文網其他相關文章！