一篇文章全面瞭解監控知識體系
作者簡介
徐亮偉 江湖人稱標杆徐，曾負責大規模叢集架構自動化運維工作。擅長自動化運維，並且在分散式、Python自動化、雲端計算虛擬化等領域有較深入研究。個人部落格：徐亮偉架構師之路；
前言
監控是整個運維乃至整個產品生命週期中最重要的一環，事前及時預警發現故障，事後提供詳實的資料用於追查定位問題。目前業界有很多不錯的開源產品可供選擇。選擇一款開源的監控系統，是一個省時省力，效率最高的方案。當然對監控不是很明白的朋友們，看了以下文章可能會對監控整個體系有比較深刻的認識。
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監控硬體服務參考資料
IPMI
6.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 模板）
其他相關監控
6.3 應用監控
把硬體監控和系統監控研究明白後，我們進一步操作是需要登陸到伺服器上檢視伺服器運行了哪些服務，都需要監控起來。
應用服務監控也是監控體系中比較重要的內容，例如：LVS、Haproxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、Rabbitmq 等等，相關的服務都需要使用zabbix監控起來
nginx_status
PHP-FPM_status
Redis_status
JVM 監控
筆者之前寫過服務監控詳細的操作過程，這裡就不一一展示了。
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 的狀態。
smokeping
監控寶
6.5 流量分析
網站流量分析對於運維人員來說，更是一門必須掌握的知識了。比如對於一家電商公司來說：
通過對訂單來源的統計和分析，可以瞭解我們在某個網站上的廣告投入有沒有收到預期的效果。
可以區分不同地區的訪問人數、甚至商品交易額等。
百度統計、google 分析、站長工具等等，只需要在頁面嵌入一個js即可。
但是，資料始終是在對方手中，個性化定製不方便，於是 google 出一個叫 piwik 的開源分析工具
piwik
百度統計
6.6 日誌監控
通常情況下，隨著系統的執行，作業系統會產生系統日誌，應用程式會產生應用程式的訪問日誌、錯誤日誌、執行日誌、網路日誌，我們可以使用 ELK 來進行日誌監控。
對於日誌監控來說，最見的需求就是收集、儲存、查詢、展示。
開源社群正好有相對應的開源專案： logstash（收集） + elasticsearch（儲存+搜尋） + kibana（展示）
我們將這三個組合起來的技術稱之為 ELK Stack，所以說 ELK Stack 指的是 Elasticsearch、Logstash、Kibana 技術棧的結合。
如果收集了日誌資訊，那麼如果部署更新有異常出現，可以立即在 kibana 上看到。
Elk 日誌展示
當然也可以通過Zabbix過濾錯誤日誌來進行告警。
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 的請求， 可用性、正確性、響應時間為三大重效能指標
API監控
三方API監控
響應時間
6.9 效能監控
全面監控網頁效能，DNS 響應時間、HTTP 建立連線時間、頁面效能指數、響應時間、可用率、元素大小等
Zabbix 提供 URL監控：Zabbix Web 監控
Zabbix 站點監控
終端響應時間
第三方監控的監控大盤。各類圖表一目瞭然，全面體現網頁效能健康狀況。
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可以用來定製符合自己企業的監控平臺。
當然我說的還是很簡單，經驗有限、思路也僅能提供這麼多。 以上就是我分享對監控的一些方法和心得。（老鳥勿噴）
文章來自微信公眾號：高效運維