《運維必知必會的監控知識體系全梳理》要點：
本文介紹了運維必知必會的監控知識體系全梳理，希望對您有用。如果有疑問，可以聯系我們。

作者介紹

徐亮偉,江湖人稱標桿徐,曾負責大規模集群架構自動化運維工作.擅長自動化運維,并且在分布式、Python自動化、云計算虛擬化等領域有較深入研究.個人博客：徐亮偉架構師之路.

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

一、監控目標

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

1. 對系統不間斷的實時監控：實際上是對系統不間斷的實時監控(這就是監控)；
2. 實時反饋系統當前狀態：我們監控某個硬件、或者某個系統,都是需要能實時看到當前系統的狀態,是正常、異常、或者故障.
3. 保證服務可靠性安全性：我們監控的目的就是要保證系統、服務、業務正常運行
4. 保證業務持續穩定運行：如果我們的監控做得很完善,即使出現故障,能第一時間接收到故障報警,在第一時間處理解決,從而保證業務持續性的穩定運行.

二、監控方法

1.了解監控對象：我們要監控的對象你是否了解呢?比如CPU到底是如何工作的?

2.性能基準指標：我們要監控這個東西的什么屬性?比如CPU的使用率、負載、用戶態、內核態、上下文切換.?

3.報警閾值定義：怎么樣才算是故障,要報警呢?比如CPU的負載到底多少算高,用戶態、內核態分別跑多少算高??

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可以用來定制符合自己企業的監控平臺.

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

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/1954.html