一篇文章全面瞭解監控知識體系
一篇文章全面瞭解監控知識體系
5 人贊了文章
前言介紹
監控是整個運維乃至整個產品生命週期中最重要的一環，事前及時預警發現故障，事後提供詳實的數據用於追查定位問題。
目前業界有很多不錯的開源產品可供選擇。選擇一款開源的監控系統，是一個省時省力，效率最高的方案。當然對監控不是很明白的朋友們，看了以下文章可能會對監控整個體繫有比較深刻的認識。
ps:本文內容較多，文章篇幅很長，可以先收藏，後續慢慢閱讀。
作者介紹
徐亮偉，江湖人稱標杆徐，曾負責大規模集羣架構自動化運維工作。擅長自動化運維，並且在分散式、Python自動化、雲計算虛擬化等領域有較深入研究。個人博客：徐亮偉架構師之路
筆者Q:552408925、572891887 架構師羣:471443208
0 監控目標
我們先來瞭解什麼是監控，監控的重要性以及監控的目標，當然每個人所在的行業不同、公司不同、業務不同、崗位不同、對監控的理解也不同，但是我們需要注意，監控是需要站在公司的業務角度去考慮，而不是針對某個監控技術的使用。
2.實時反饋系統當前狀態:我們監控某個硬體、或者某個系統，都是需要能實時看到當前系統的狀態，是正常、異常、或者故障
3.保證服務可靠性安全性:我們監控的目的就是要保證系統、服務、業務正常運行
4.保證業務持續穩定運行:如果我們的監控做得很完善，即使出現故障，能第一時間接收到故障報警，在第一時間處理解決，從而保證業務持續性的穩定運行。
1 監控方法
既然我們瞭解到了監控的重要性、以及監控的目的，那麼下面我們需要了解下監控有哪些方法。
2.性能基準指標:我們要監控這個東西的什麼屬性？比如CPU的使用率、負載、用戶態、內核態、上下文切換。
3.報警閾值定義:怎麼樣纔算是故障，要報警呢？比如CPU的負載到底多少算高，用戶態、內核態分別跑多少算高？
4.故障處理流程:收到了故障報警，那麼我們怎麼處理呢？有什麼更高效的處理流程嗎？
2 監控核心
我們瞭解了監控的方法、監控對象、性能指標、報警閾值定義、以及故障處理流程幾步驟，當然我們更需要知道監控的核心是什麼？
1.發現問題:當系統發生故障報警，我們會收到故障報警的信息
2.定位問題:故障郵件一般都會寫某某主機故障、具體故障的內容，我們需要對報警內容進行分析，比如一臺伺服器連不上:我們就需要考慮是網路問題、還是負載太高導致長時間無法連接，又或者某開發觸發了防火牆禁止的相關策略等等，我們就需要去分析故障具體原因。
3.解決問題:當然我們瞭解到故障的原因後，就需要通過故障解決的優先順序去解決該故障。
4.總結問題:當我們解決完重大故障後，需要對故障原因以及防範進行總結歸納，避免以後重複出現。
3 監控工具
下面我們需要選擇一款合適公司業務的監控工具進行監控,這裡我對監控工具進行了簡單的分類
老牌監控:
MRTG（Multi Route Trffic Grapher）是一套可用來繪製網路流量圖的軟體，由瑞士奧爾滕的Tobias Oetiker與Dave Rand所開發，以GPL授權。
MRTG最好的版本是1995年推出的，用perl語言寫成，可跨平臺使用，數據採集用SNMP協議，MRTG將手機到的數據通過Web頁面以GIF或者PNG格式繪製出圖像。
Grnglia是一個跨平臺的、可擴展的、高性能的分散式監控系統，如集羣和網格。它基於分層設計，使用廣泛的技術，用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的目標是做最開放、最好用的互聯網企業級監控產品。
OWL是TalkingData公司推出的一款開源分散式監控系統OWLgithub地址
三方監控:
現在市場上有很多不錯的第三方監控，比如：監控寶、監控易、聽雲、還有很多雲廠商自帶監控，但是在這裡我們不打算著重介紹，如果想了解三方監控可自行上官網諮詢。（避免說廣告植入）
4 監控流程
上面介紹了這麼多，那麼到底選擇什麼監控工具最合適呢，我這裡推薦幾款開源監控工具: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.報警處理:當接收到報警，我們需要根據故障的級別進行處理，比如:重要緊急、重要不緊急，等。根據故障的級別，配合相關的人員進行快速處理。
5 監控指標
我們上面瞭解了監控方法、目標、流程、也瞭解了監控有哪些工具，可能有人會疑惑，我們具體要監控寫什麼東西，那麼我在這裡進行了分類整理:
硬體監控
系統監控
應用監控
網路監控
流量分析
日誌監控
安全監控
API監控
性能監控
業務監控
5.1 硬體監控
早期我們通過機房巡檢的方式，查看硬體設備燈光閃爍情況判斷是否故障，這樣非常浪費人力，並且是重複性無技術含量的工作，大家懂得。
IPMI監控硬體服務參考資料
IPMI工具無法獲取到硬體的狀態，可以藉助MegaCli工具探測Raid磁碟隊列狀態
zabbix提供IPMI監控模板：Zabbix IPMI Interface
系統自帶的IPMI模板只能監控，風扇，電源，和部分溫度
5.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
其它的系統監控還有運行的進程埠、進程數、登陸用戶、Open File等（詳細查看zabbix自帶OS Linux模板）
5.3 應用監控
把硬體監控和系統監控研究明白後，我們進一步操作是需要登陸到伺服器上查看伺服器運行了哪些服務，都需要監控起來。
應用服務監控也是監控體系中比較重要的內容，例如：
LVS、Haproxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、Rabbitmq等等，相關的服務都需要使用zabbix監控起來。
筆者之前寫過服務監控詳細的操作過程，這裡就不一一展示，詳情訪問：zabbix監控各種應用服務
zabbix提供應用服務監控：Zabbix Agent UserParameter
zabbix提供的Java監控：Zabbix JMX Interface
percona提供MySQL資料庫監控：percona-monitoring-plulgins
5.4 網路監控
作為一個針對全國用戶的電商網站，時刻掌握各地到機房的網路狀態也是必須的。
網路監控是我們構建監控平臺是必須要考慮的，尤其是針對有多個機房的場景，各個機房之間的網路狀態，機房和全國各地的網路狀態都是我們需要重點關注的對象，那麼如何掌握這些狀態信息呢？我們需要藉助於網路監控工具Smokeping。
Smokeping 是rrdtool的作者Tobi Oetiker的作品，是用Perl寫的，主要是監視網路性能，www 伺服器性能，dns查詢性能等，使用rrdtool繪圖，而且支持分散式，直接從多個agent進行數據的匯總。
同時，由於自己監控點比較少，還可以藉助很多商業的監控工具，比如監控寶、聽雲、基調、博瑞等。同時這些服務提供商還可以幫助你監控CDN的狀態。
5.5 流量分析
網站流量分析對於運維人員來說，更是一門必須掌握的知識了。比如對於一家電商公司來說：
通過對訂單來源的統計和分析，可以瞭解我們在某個網站上的廣告投入有沒有收到預期的效果。
可以區分不同地區的訪問人數、甚至商品交易額等。
百度統計、google分析、站長工具等等，只需要在頁面嵌入一個js即可。
但是，數據始終是在對方手中，個性化定製不方便，於是google出一個叫piwik的開源分析工具
5.6 日誌監控
通常情況下，隨著系統的運行，操作系統會產生系統日誌，應用程序會產生應用程序的訪問日誌、錯誤日誌，運行日誌，網路日誌，我們可以使用ELK來進行日誌監控。
對於日誌監控來說，最見的需求就是收集、存儲、查詢、展示，開源社區正好有相對應的開源項目：
logstash（收集） + elasticsearch（存儲+搜索） + kibana（展示）
我們將這三個組合起來的技術稱之為ELK Stack，所以說ELK Stack指的是Elasticsearch、Logstash、Kibana技術棧的結合。
如果收集了日誌信息，那麼如果部署更新有異常出現，可以立即在kibana上看到。
當然也可以通過Zabbix過濾錯誤日誌來進行告警。
5.7 安全監控
雖然Linux開源的安全產品不少，比如四層iptables，七層WEB防護nginx+lua實現WAF，最後將相關的日誌都收至Elkstack，通過圖形化進行不同的攻擊類型展示。但是始終是一件比較耗費時間，並且個人效果並不是很好。這個時候我們可以選擇接入第三方服務廠商。
三方廠商提供全面的漏洞庫，涵蓋服務、後門、資料庫、配置檢測、CGI、SMTP等多種類型
全面檢測主機、Web應用漏洞自主挖掘和行業共享相結合第一時間更新0day漏洞，杜絕最新安全隱患
5.8 API監控
由於API變得越來越重要，很顯然我們也需要這樣的數據來分辨我們提供的 API是否能夠正常運作。
監控API介面GET、POST、PUT、DELETE、HEAD、OPTIONS的請求
可用性、正確性、響應時間為三大重性能指標
5.9 性能監控
全面監控網頁性能，DNS響應時間、HTTP建立連接時間、頁面性能指數、響應時間、可用率、元素大小等
zabbix提供URL監控：Zabbix Web 監控
第三方監控監控大盤。各類圖表一目瞭然，全面體現網頁性能健康狀況。
5.10 業務監控
沒有業務指標監控的監控平臺，不是一個完善的監控平臺，通常在我們的監控系統中，必須將我們重要的業務指標進行監控，並設置閾值進行告警通知。比如電商行業：
每分鐘產生多少訂單，
每分鐘註冊多少用戶，
每天有多少活躍用戶，
每天有多少推廣活動，
推廣活動引入多少用戶，
推廣活動引入多少流量，
推廣活動引入多少利潤，
今天商品打包出庫多少，
今天退貨商品有多少，
等等 重要指標都可以加入zabbix上，然後通過screen展示。
註：由於業務監控圖表，涉及到隱私的數據太多，就不截圖。
6 監控報警
故障報警通知的方式有很多種，當然我們最常用的還是簡訊，郵件
7 報警處理
一般報警後我們故障如何處理，首先，我們可以通過告警升級機制先自動處理，比如nginx服務down了，可以設置告警升級自動啟動nginx。
但是如果一般業務出現了嚴重故障，我們通常根據故障的級別，故障的業務，來指派不同的運維人員進行處理。
當然不同業務形態、不同架構、不同服務可能採用的方式都不同，這個沒有一個固定的模式套用。
8 面試監控
在運維面試中，常常會被問題監控相關的問題，那麼這個問題到底該如何來回答，我針對本文給大家提供了一個簡單的回答思路。
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來實現。
12.分散式監控
9 監控總結
真正想做到更完整的監控體系，目前的開源軟體，確實無法很好的滿足，有條件的公司都開始自己開發自己的監控系統，比如小米開源的Open-Falcon。
也有比較好的開源的監控框架如Sensu等，再加上influxdb、grafana可以用來定製符合自己企業的監控平臺。
當然我說的還是很簡單，經驗有限、思路也僅能提供這麼多。
以上就是我分享對監控的一些方法和心得。（老鳥勿噴）
如果覺得本文不錯，可以對筆者進行讚賞。（你的讚賞就是我的動力）
致謝
感謝我的老師趙班長的中小企業監控體系構建實戰纔有了此篇文章的誕生。
感謝為本供圖小夥伴：周玉強、顧雲、陳榮華。
感謝為本文校對指正的小夥伴：萬永振、周玉強、陳榮華。
推薦閱讀：
