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

時間 2019-11-16

標籤一篇文章全面瞭解監控知識體系简体版

原文原文鏈接

前言介紹

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

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

做者介紹

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

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

0 監控目標

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

監控目標

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

1 監控方法

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

監控方法

1.瞭解監控對象:咱們要監控的對象你是否瞭解呢？好比CPU究竟是如何工做的？
2.性能基準指標:咱們要監控這個東西的什麼屬性？好比CPU的使用率、負載、用戶態、內核態、上下文切換。
3.報警閾值定義:怎麼樣纔算是故障，要報警呢？好比CPU的負載到底多少算高，用戶態、內核態分別跑多少算高？
4.故障處理流程:收到了故障報警，那麼咱們怎麼處理呢？有什麼更高效的處理流程嗎？git

2 監控核心

咱們瞭解了監控的方法、監控對象、性能指標、報警閾值定義、以及故障處理流程幾步驟，固然咱們更須要知道監控的核心是什麼？
github

監控核心

1.發現問題:當系統發生故障報警，咱們會收到故障報警的信息
2.定位問題:故障郵件通常都會寫某某主機故障、具體故障的內容，咱們須要對報警內容進行分析，好比一臺服務器連不上:咱們就須要考慮是網絡問題、仍是負載過高致使長時間沒法鏈接，又或者某開發觸發了防火牆禁止的相關策略等等，咱們就須要去分析故障具體緣由。
3.解決問題:固然咱們瞭解到故障的緣由後，就須要經過故障解決的優先級去解決該故障。
4.總結問題:當咱們解決完重大故障後，須要對故障緣由以及防範進行總結概括，避免之後重複出現。web

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

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

磁盤使用率

磁盤讀/寫吞吐

磁盤讀/寫次數

網卡進出口流量

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來實現。