《一篇文章全面了解監控知識體系》要點：
本文介紹了一篇文章全面了解監控知識體系，希望對您有用。如果有疑問，可以聯系我們。

作者簡介

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

前言

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

1、監控目標

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

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

2、監控方法

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

1. 了解監控對象：我們要監控的對象你是否了解呢?比如 CPU 到底是如何工作的?
2. 性能基準指標：我們要監控這個東西的什么屬性?比如 CPU 的使用率、負載、用戶態、內核態、上下文切換.
3. 報警閾值定義：怎么樣才算是故障,要報警呢?比如 CPU 的負載到底多少算高,用戶態、內核態分別跑多少算高?
4. 故障處理流程：收到了故障報警,我們怎么處理呢?有什么更高效的處理流程嗎?

3、監控核心

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

1. 發現問題：當系統發生故障報警,我們會收到故障報警的信息 ；
2. 定位問題：故障郵件一般都會寫某某主機故障、具體故障的內容,我們需要對報警內容進行分析,比如一臺服務器連不上：我們就需要考慮是網絡問題、還是負載太高導致長時間無法連接,又或者某開發觸發了防火墻禁止的相關策略等等,我們就需要去分析故障具體原因；
3. 解決問題：當然我們了解到故障的原因后,就需要通過故障解決的優先級去解決該故障；
4. 總結問題：當我們解決完重大故障后,需要對故障原因以及防范進行總結歸納,避免以后重復出現；

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 的整個流程：

1. 數據采集：Zabbix 通過 SNMP、Agent、ICMP、SSH、IPMI 等對系統進行數據采集；
2. 數據存儲：Zabbix 存儲在 MySQL 上,也可以存儲在其他數據庫服務；
3. 數據分析：當我們事后需要復盤分析故障時,Zabbix 能給我們提供圖形以及時間等相關信息,方面我們確定故障所在；
4. 數據展示：web 界面展示、(移動 APP、java_php 開發一個 web 界面也可以) ；
5. 監控報警：電話報警、郵件報警、微信報警、短信報警、報警升級機制等(無論什么報警都可以)；
6. 報警處理：當接收到報警,我們需要根據故障的級別進行處理,比如:重要緊急、重要不緊急等.根據故障的級別,配合相關的人員進行快速處理；

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、面試監控

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

1. 硬件監控.?通過 SNMP 來進行路由器交換機的監控(這些可以跟一些廠商溝通來了解如何做)、服務器的溫度以及其他,可以通過IPMI來實現.當然如果沒有硬件全都是云,直接跳過這一步驟.
2. 系統監控.?如 CPU 的負載,上下文切換、內存使用率、磁盤讀寫、磁盤使用率、磁盤 inode 使用率.當然這些都是需要配置觸發器,因為默認太低會頻繁報警.
3. 服務監控.?比如公司用的 LAMP 架構,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.fzlkiss.com/jiaocheng/4266.html