一篇文章全面瞭解監控知識體系

一篇文章全面瞭解監控知識體系

標籤（空格分隔）： 監控 zabbix

前言介紹

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

ps:本文內容較多，文章篇幅很長，可以先收藏，後續慢慢閱讀。

作者介紹

徐亮偉，江湖人稱標杆徐，曾負責大規模集羣架構自動化運維工作。擅長自動化運維，並且在分佈式、Python自動化、雲計算虛擬化等領域有較深入研究。個人博客：徐亮偉架構師之路
筆者Q:552408925、572891887
架構師羣:471443208**

感謝我的老師趙班長的中小企業監控體系構建實戰纔有了此篇文章的誕生。
感謝爲本供圖小夥伴：周玉強、顧雲、陳榮華。
感謝爲本文校對指正的小夥伴：萬永振、周玉強、陳榮華。

[TOC]

0 監控目標

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

監控目標

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

1 監控方法

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

監控方法

1.瞭解監控對象:我們要監控的對象你是否瞭解呢？比如CPU到底是如何工作的？
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對硬件詳細情況進行監控，並對CPU、內存、磁盤、溫度、風扇、電壓等設置報警設置報警閾值(自行對監控報警內容編寫合理的報警範圍)
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

磁盤使用率

磁盤讀/寫吞吐

磁盤讀/寫次數

網卡進出口流量
TCP監控：在很多情況下有必要監控TCP的狀態，可以使用netstat或者ss來獲取所有的TCP連接，來展現11種不同的TCP連接狀態的數量，可以在大併發中及時發現TCP的相關故障。

TCP11種狀態信息

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

其他相關監控

5.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

5.4 網絡監控

作爲一個針對全國用戶的電商網站，時刻掌握各地到機房的網絡狀態也是必須的。
網絡監控是我們構建監控平臺是必須要考慮的，尤其是針對有多個機房的場景，各個機房之間的網絡狀態，機房和全國各地的網絡狀態都是我們需要重點關注的對象，那麼如何掌握這些狀態信息呢？我們需要藉助於網絡監控工具Smokeping。

Smokeping 是rrdtool的作者Tobi Oetiker的作品，是用Perl寫的，主要是監視網絡性能，www 服務器性能，dns查詢性能等，使用rrdtool繪圖，而且支持分佈式，直接從多個agent進行數據的彙總。

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

smokeping


監控寶

5.5 流量分析

網站流量分析對於運維人員來說，更是一門必須掌握的知識了。比如對於一家電商公司來說：
通過對訂單來源的統計和分析，可以瞭解我們在某個網站上的廣告投入有沒有收到預期的效果。
可以區分不同地區的訪問人數、甚至商品交易額等。

百度統計、google分析、站長工具等等，只需要在頁面嵌入一個js即可。
但是，數據始終是在對方手中，個性化定製不方便，於是google出一個叫piwik的開源分析工具

piwik

百度統計

5.6 日誌監控

通常情況下，隨着系統的運行，操作系統會產生系統日誌，應用程序會產生應用程序的訪問日誌、錯誤日誌，運行日誌，網絡日誌，我們可以使用ELK來進行日誌監控。

對於日誌監控來說，最見的需求就是收集、存儲、查詢、展示，開源社區正好有相對應的開源項目：
logstash（收集） + elasticsearch（存儲+搜索） + kibana（展示）
我們將這三個組合起來的技術稱之爲ELK Stack，所以說ELK Stack指的是Elasticsearch、Logstash、Kibana技術棧的結合。

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

Elk日誌展示

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

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的請求
可用性、正確性、響應時間爲三大重性能指標

API監控

三方API監控

響應時間

5.9 性能監控

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

Zabbix站點監控

終端響應時間

第三方監控監控大盤。各類圖表一目瞭然，全面體現網頁性能健康狀況。

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

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

如果覺得本文不錯，可以轉發或讚賞筆者。