點擊上方藍色字體，選擇“設爲星標”
回覆”資源“獲取更多資源
監控目標
我們先來了解什麼是監控，監控的重要性以及監控的目標，當然每個人所在的行業不同、公司不同、業務不同、崗位不同、對監控的理解也不同，但是我們需要注意，監控是需要站在公司的業務角度去考慮，而不是針對某個監控技術的使用。
對系統不間斷實時監控:實際上是對系統不間斷的實時監控(這就是監控)
實時反饋系統當前狀態:我們監控某個硬件、或者某個系統，都是需要能實時看到當前系統的狀態，是正常、異常、或者故障
保證服務可靠性安全性:我們監控的目的就是要保證系統、服務、業務正常運行
保證業務持續穩定運行:如果我們的監控做得很完善，即使出現故障，能第一時間接收到故障報警，在第一時間處理解決，從而保證業務持續性的穩定運行。
監控方法
既然我們瞭解到了監控的重要性、以及監控的目的，那麼下面我們需要了解下監控有哪些方法。
瞭解監控對象:我們要監控的對象你是否瞭解呢？比如CPU到底是如何工作的？
性能基準指標:我們要監控這個東西的什麼屬性？比如CPU的使用率、負載、用戶態、內核態、上下文切換。
報警閾值定義:怎麼樣纔算是故障，要報警呢？比如CPU的負載到底多少算高，用戶態、內核態分別跑多少算高？
故障處理流程:收到了故障報警，那麼我們怎麼處理呢？有什麼更高效的處理流程嗎？
監控核心
我們瞭解了監控的方法、監控對象、性能指標、報警閾值定義、以及故障處理流程幾步驟，當然我們更需要知道監控的核心是什麼？
發現問題:當系統發生故障報警，我們會收到故障報警的信息
定位問題:故障郵件一般都會寫某某主機故障、具體故障的內容，我們需要對報警內容進行分析，比如一臺服務器連不上:我們就需要考慮是網絡問題、還是負載太高導致長時間無法連接，又或者某開發觸發了防火牆禁止的相關策略等等，我們就需要去分析故障具體原因。
解決問題:當然我們瞭解到故障的原因後，就需要通過故障解決的優先級去解決該故障。
總結問題:當我們解決完重大故障後，需要對故障原因以及防範進行總結歸納，避免以後重複出現。
監控工具
下面我們需要選擇一款合適公司業務的監控工具進行監控,這裏我對監控工具進行了簡單的分類。
老牌監控
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都是具有優勢的，其豐富的功能、可擴展的能力、二次開發的能力和簡單易用的特點，讀者只要稍加學習，即可構建自己的監控系統。
Prometheus 是一套開源的系統監控報警框架。它啓發於 Google 的 borgmon 監控系統，由工作在 SoundCloud 的 google 前員工在 2012 年創建，作爲社區開源項目進行開發，並於 2015 年正式發佈。Prometheus是最近幾年開始流行的一個新興監控告警工具，特別是kubernetes的流行帶動了prometheus的應用。
小米的監控系統：open-falcon。open-falcon的目標是做最開放、最好用的互聯網企業級監控產品。
三方監控
現在市場上有很多不錯的第三方監控，比如：監控寶、監控易、還有很多雲廠商自帶監控，但是在這裏我們不打算着重介紹，如果想了解三方監控可自行上官網諮詢。
監控指標
我們上面瞭解了監控方法、目標、流程、也瞭解了監控有哪些工具，可能有人會疑惑，我們具體要監控寫什麼東西，那麼我在這裏進行了分類整理:
硬件監控
早期我們通過機房巡檢的方式，查看硬件設備燈光閃爍情況判斷是否故障，這樣非常浪費人力，並且是重複性無技術含量的工作，大家懂得。
當然我們現在可以通過IPMI對硬件詳細情況進行監控，並對CPU、內存、磁盤、溫度、風扇、電壓等設置報警設置報警閾值(自行對監控報警內容編寫合理的報警範圍)
系統監控
中小型企業基本全是Linux服務器，那麼我們肯定是要監控起系統資源的使用情況，系統監控是監控體系的基礎。
CPU CPU有幾個重要的概念:上下文切換、運行隊列和使用率。
這也是我們CPU監控的幾個重點指標。通常情況，每個處理器的運行隊列不要高於3，CPU 利用率中用“戶態/內核態”比例維持在70/30，空閒狀態維持在50%，上下文切換要根據系統繁忙程度來綜合考量。
針對CPU常用的工具有:htop、top、vmstat、mpstat、dstat、glances
內存 通常我們需要監控內存的使用率、SWAP使用率、同時可以通過zabbix描繪內存使用率的曲線圖形發現某服務內存溢出等。針對內存常用的工具有: free、top、vmstat、glances
IO IO分爲磁盤IO和網絡IO。除了在做性能調優我們要監控更詳細的數據外，那麼日常監控，只關注磁盤使用率、磁盤吞吐量、磁盤寫入繁忙程度，網絡也是監控網卡流量即可。
常用工具有：iostat、iotop、df、iftop、sar、glances
應用監控
把硬件監控和系統監控研究明白後，我們進一步操作是需要登陸到服務器上查看服務器運行了哪些服務，都需要監控起來。應用服務監控也是監控體系中比較重要的內容，例如：LVS、Haproxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、Rabbitmq等等，相關的服務都需要使用zabbix監控起來。
網絡監控
網絡監控是我們構建監控平臺是必須要考慮的，尤其是針對有多個機房的場景，各個機房之間的網絡狀態，機房和全國各地的網絡狀態都是我們需要重點關注的對象，那麼如何掌握這些狀態信息呢？我們需要藉助於網絡監控工具Smokeping。
Smokeping 是rrdtool的作者Tobi Oetiker的作品，是用Perl寫的，主要是監視網絡性能，www 服務器性能，dns查詢性能等，使用rrdtool繪圖，而且支持分佈式，直接從多個agent進行數據的彙總。
同時，由於自己監控點比較少，還可以藉助很多商業的監控工具，比如監控寶、聽雲、基調、博瑞等。同時這些服務提供商還可以幫助你監控CDN的狀態。
流量分析
網站流量分析對於運維人員來說，更是一門必須掌握的知識了。比如對於一家電商公司來說：通過對訂單來源的統計和分析，可以瞭解我們在某個網站上的廣告投入有沒有收到預期的效果。可以區分不同地區的訪問人數、甚至商品交易額等。
百度統計、google分析、站長工具等等，只需要在頁面嵌入一個js即可。但是，數據始終是在對方手中，個性化定製不方便，於是google出一個叫piwik的開源分析工具。
日誌監控
通常情況下，隨着系統的運行，操作系統會產生系統日誌，應用程序會產生應用程序的訪問日誌、錯誤日誌，運行日誌，網絡日誌，我們可以使用ELK來進行日誌監控。
對於日誌監控來說，最見的需求就是收集、存儲、查詢、展示，開源社區正好有相對應的開源項目：logstash（收集） + elasticsearch（存儲+搜索） + kibana（展示） 我們將這三個組合起來的技術稱之爲ELK Stack，所以說ELK Stack指的是Elasticsearch、Logstash、Kibana技術棧的結合。
如果收集了日誌信息，那麼如果部署更新有異常出現，可以立即在kibana上看到。
安全監控
雖然Linux開源的安全產品不少，比如四層iptables，七層WEB防護nginx+lua實現WAF，最後將相關的日誌都收至Elkstack，通過圖形化進行不同的攻擊類型展示。但是始終是一件比較耗費時間，並且個人效果並不是很好。這個時候我們可以選擇接入第三方服務廠商。
三方廠商提供全面的漏洞庫，涵蓋服務、後門、數據庫、配置檢測、CGI、SMTP等多種類型全面檢測主機、Web應用漏洞自主挖掘和行業共享相結合第一時間更新0day漏洞，杜絕最新安全隱患。
API監控
由於API變得越來越重要，很顯然我們也需要這樣的數據來分辨我們提供的 API是否能夠正常運作。監控API接口GET、POST、PUT、DELETE、HEAD、OPTIONS的請求 可用性、正確性、響應時間爲三大重性能指標
性能監控
全面監控網頁性能，DNS響應時間、HTTP建立連接時間、頁面性能指數、響應時間、可用率、元素大小等
業務監控
沒有業務指標監控的監控平臺，不是一個完善的監控平臺，通常在我們的監控系統中，必須將我們重要的業務指標進行監控，並設置閾值進行告警通知。比如電商行業：
每分鐘產生多少訂單， 每分鐘註冊多少用戶， 每天有多少活躍用戶， 每天有多少推廣活動， 推廣活動引入多少用戶， 推廣活動引入多少流量， 推廣活動引入多少利潤， 等等 重要指標都可以加入zabbix上，然後通過screen展示。
監控報警
故障報警通知的方式有很多種，當然我們最常用的還是短信，郵件
報警處理
一般報警後我們故障如何處理，首先，我們可以通過告警升級機制先自動處理，比如nginx服務down了，可以設置告警升級自動啓動nginx。但是如果一般業務出現了嚴重故障，我們通常根據故障的級別，故障的業務，來指派不同的運維人員進行處理。當然不同業務形態、不同架構、不同服務可能採用的方式都不同，這個沒有一個固定的模式套用。
面試監控
在運維面試中，常常會被問題監控相關的問題，那麼這個問題到底該如何來回答，我針對本文給大家提供了一個簡單的回答思路。
硬件監控。通過SNMP來進行路由器交換機的監控(這些可以跟一些廠商溝通來了解如何做)、服務器的溫度以及其他，可以通過IPMI來實現。當然如果沒有硬件全都是雲，直接跳過這一步驟。
系統監控。如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響應時間、下載時間、等等。這裏我推薦使用專業的商業軟件,監控寶或聽雲來實現。畢竟人家全國各地都有機房。（如果本身是多機房那就另說了）
如果是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來實現。
監控如何精準實時的覆蓋
監控建設需要解決的兩個核心問題就是：優先用戶發現問題和快速定位解決問題。
如何優先用戶發現問題：需要具備監控的眼睛足夠多，針對運維對象從物理設備、系統組件以及應用層對象能夠全面覆蓋，以及針對不斷增長的運維對象能夠持續擴展。
如何快速定位解決問題：不僅需要針對告警信息的多維關聯分析，同時還需具備針對告警事件的閉環處理以及故障自愈管理，支撐運維人員快速解決故障。
平臺化監控設計
基於傳統建設監控系統的方式，你會發現如果想要覆蓋全面的運維對象，所需建設各種場景監控系統就會越來越多，海量無效的告警事件接踵而來，同時圍繞同一故障的告警信息都分佈在各個監控系統中，這麼一來就很難實現快速的告警定位分析。
爲了滿足不斷變化的監控需求，我們得換一種建設思路，通過平臺+場景的建設思路，不僅能夠滿足監控覆蓋全面性的要求，還能夠持續擴展監控場景以滿足變化的需求。
監控平臺
聚焦監控數據鏈路能力，從數據採集 → 數據存儲 → 數據加工 → 數據監測 → 告警管理 → 故障閉環 → 監控可視化能力。
數據採集：監控數據採集類型包括指標（Metrics）、日誌（Logs）、跟蹤（Trace），針對不同的數據採用的數據採集方式也不同，如：Agent代理採集、腳本插件採集、日誌採集、協議採集、進程採集、Web撥測、APM探針以及API接口等。
因此在考慮監控平臺採集能力設計的時候，需要具備靈活擴展的採集器擴展能力，能夠支持適配當下主流監控系統的不同採集器的方法。
數據存儲：
數據分析：針對監控數據分析能力，包括數據清洗、數據豐富、數據計算以及數據檢測能力，如數據豐富過程中的CMDB字段豐富，數據計算支持各種運算規則（AVG\SUM\MAX\MIN\COUNT），數據檢測支持靜態閾值、同比、環比以及機器學習擴展。
告警管理：
提供告警事件的統一管理，包括告警收斂、告警聚合、告警屏蔽以及告警通知等功能：告警聚合：支持按對象進行聚合、按應用進行聚合、按時間進行聚合、基於CMDB拓撲關係進行聚合、以及按負責人進行聚合。告警屏蔽：支持變更維護期內告警屏蔽，屏蔽維度支持時間、對象、策略等。告警通知：支持微信、短信、語言、郵件告警通知，以及API或自定義渠道通知。
故障閉環：實現告警事件的快速跟進和閉環管理，如對接工單系統自動生成事件工單，對接自動化系統實現故障自愈。
監控可視化：基於監控視圖的可視化展示，實時展現監控對象的狀態信息以及告警事件的信息。
監控場景
基於監控指標數據採集能力，以及監控後臺的數據存儲和監測分析能力，構建各種運維對象的監控場景，如硬件監控、雲監控、系統監控、組件監控、日誌監控，以及應用服務和性能監控等。
硬件設備監控：監控對象：網絡設備、存儲設備、物理機；採集方式：基於通用協議採集SNMP、IPMI。
雲監控：監控對象：虛擬化、私有云公有云平臺健康性，以雲產品的容量、性能監控；採集方式：基於雲平臺API採集插件。
系統組件監控：採集方式：基於Agent、腳本、插件採集，支持持續擴展。監控對象：應用網站服務、應用協議服務以及C\S應用可用性；採集方式：基於Selenium、RPA技術，持續擴展腳本、協議以及模擬採集。
日誌監控：監控對象：文本日誌、系統日誌，關鍵字的監控；採集方式：基於系統層日誌採集。
應用性能監控：監控對象：應用性能、調用鏈分析、接口調用分析等；採集方式：APM探針或應用SDK。
智能監控有效延展
運維監控的建設，從系統化 → 平臺化 → 智能化的演進過程， 基於平臺化的集中監控數據管理，賦予運維大數據平臺的數據分析、數據開發、數據建模的能力，實現體系化智能監控場景，如動態閾值、異常檢測、根因定位以及容量預測等。
企業統一監控建設階段
第一階段：統一告警事件管理
基於企業現有運維體系的建設現狀，多多少少都已經有了各種監控工具系統的建設，有些是採用傳統商用監控系統，如IBM_Tivovi、HP_OVO、SCOM、SolarWinds、聽雲、Dynatrace等，也有些是採用開源監控系統，如Zabbix、Prometheus、Pinpoint等。
基於已建設監控系統現狀，監控系統覆蓋已經達到一定程度，但運維人員面臨的痛點問題更多是海量告警、無效告警等，因此可以優先考慮告警事件的統一管理，實現告警事件的閉環管理。
告警源接入，支持各種常用監控系統集成，以及標準告警事件API接口：
告警事件，集成企業ITSM系統，自動創建事件工單：
實現整體告警事件的端到端閉環管理：
第二階段：集中監控數據處理
基於企業級監控平臺的設計，通過可擴展的統一監控採集插件能力，持續建設監控覆蓋面，同時基於平臺層的數據鏈路服務能力，建設集中多維度數據分析服務以及監控數據倉庫，從而支撐企業上層運維端、用戶端的個性化監控場景。
自有監控平臺化數據鏈路能力：
監控系統數據集成，構建集中數據倉庫，實現數據智能分析和建模能力賦能：
基於後臺監控數據服務能力，構架個性化場景監控工具系統：
第三階段：一體化運維監控平臺
基於企業ITOM運維管理一體化建設中，監控平臺與周邊運維繫統，如配置管理、雲資源管理、運維流程管理以及自動化管理，彼此相互依賴及融合。
Zabbix與Prometheus對比
這部分來自 dbaplus 社羣特別邀請到美圖SRE負責人-石鵬(東方德勝) 作爲主持人、 招商銀行技術經理-蔡翔華 作爲 Zabbix 使用方、 甜橙金融基礎技術架構師-劉宇 作爲 Prometheus 使用方，針對 Zabbix 和 Prometheus 展開實用選型探討。
Q1：Zabbix和Prometheus分別適用於多大規模的監控場景？超過5000以上監控節點時怎麼辦？高可用怎麼解決？
蔡翔華：我們和Zabbix官方其實有溝通過，業內他們有一些監控到了40萬以上的節點數，當然這個節點數也要根據你每個節點上監控多少東西。Zabbix其實有一個指標叫做NVPS（New Value Per Second），也就是每秒新增的值的指標，來判斷你的監控規模是不是合適的。
那麼對於5000個節點以上的場景來說，其實Zabbix還是OK的，你可以通過多佈署一些Proxy，去對後臺數據庫做一些性能調優等等，以這些方式去提高整個監控平臺的可承受、負載的性能。
另外關於高可用，我們的數據庫端是會有Mycat或者HAProxy高可用，但服務器端本身它其實沒有高可用，那麼我們可以依賴於虛擬化平臺，或者是比如像我們有Vmotion等熱遷移這些技術。另外，在未來的5.x版本或者6版本以上的話，官方已經將原生的高可用納入到Zabbix的Roadmap裏面了，大家可以期待一下。
石鵬：好的，蔡老師的核心觀點其實就是我們需要關注核心的指標，也就是NVPS，這個值是比較關鍵的。然後蔡老師之前您在實際的應用中，見過這個系統的峯值可以達到多少嗎？是否可以給大家做個參考？
蔡翔華：在我們自己的環境裏面，NVPS峯值達到過6000以上，但我們後面其實也做了一些優化，把它調整到3000左右。主要目的是，因爲一開始我們做的時候是希望做到大而全，什麼都監控，但最後發現其實大而全不一定有用，因爲很多監控即使它是問題，你也不會care它。
劉宇：是的，蔡老師已經講得比較詳細了，其實以多大的規模是取決於你的監控目標，還有就是採集的間隔，比如說5秒採集一次和1分鐘採集一次，這個規模都是支持着不一樣的目標，所以還是要根據你的需求。
一般來說，我們會配置成30秒或者是一分鐘；如果是對於高頻的，會15秒。因爲單個Prometheus性能已經比較強了，一般來說，它每秒百萬個指標都是沒什麼問題的。Prometheus會根據你的指標來計算，就是看你一個監控點上有多少個指標，這樣來換算。
如果你單個Prometheus的性能達不到它的要求時，也可以去做一些拆分，比如說我們把Prometheus根據它的功能來做區分，這個去監控node exporter，那個去監控Redis，這樣來做區分。
當然，如果你單個的性能還是不夠的話，可以用分區，即用hash mod去多分幾個Prometheus來做監控。
然後關於高可用這塊，其實社區Prometheus這部分做得也不是特別好，會用兩個Prometheus來同時監控同樣的一個目標，這樣來做到一個高可用。當然，在容器環境，你也可以去通過K8S的deployment這種方式，來把高可用維護起來。
Q2：Zabbix和Prometheus怎麼解決存儲問題？對於監控信息是否有歷史存儲和分析，能從歷史信息中挖掘到哪些有價值的信息？
蔡翔華：的確，存儲這個問題因爲監控寫的東西最多就是寫到存儲裏面去，Zabbix以前被吐槽最多的就是它不支持時序數據庫TSDB。其實在4.2以後，它就已經開始支持TSDB了，當然可能還沒有Prometheus那麼成熟，它主要的數據庫還是MySQL爲主。
如果就存儲問題的話，一方面你可以去嘗試TSDB的這種方式；另外一方面的話，你可以去通過增加SSD，或者說數據庫層面的一些性能提升，去解決它的問題。包括數據庫本身可以去分庫分表，去拆分一下，然後對歷史數據做一個歸檔……就是通過數據庫層面的優化，來解決這個問題。
那麼對於歷史存儲和分析這些信息，Zabbix提供了兩個維度，一個叫history，一個叫trend，也就是一個歷史數據和趨勢數據。它具體數值是可以自己設定的，它的邏輯是說，如果超過history的保留期限，比如說30天，它自動會把數據歸檔成trend的數據，trend的數據就會只會保留最大值、最小值和平均值這三個指標，而並不能像history數據可以看到每一秒鐘，甚至說每一個輪巡週期的指標。
我們實際場景應用的話，主要是用於我們的性能分析，因爲我們有很多互聯網應用，會看一下這個業務增長對我平臺的要求，會不會CPU比較緊張、內存比較緊張等等。另外，我們會根據這些數據做一個分析，爲我們後期的擴容、決策提供一些參考性的依據。比方說我現在看到今年整體的使用率在多少，我們每年的增長量是在20%還是30%，這樣我們後續做一些決策的時候，是需要多少的資源、多少的預算，就比較能有參考價值。
劉宇：Prometheus本身存儲如果存在本地的話，大概只能存15天，最多你也只能放到30天這樣子。官方其實也不建議你把所有的監控數據都存在Prometheus的一個本地的數據庫裏。
我們是存在InfluxDB的，也有一些是可以存在比如說ES，通過remote_write的功能去存到ES或者是其它時序數據庫中，或者是比如說HBase這種大數據的也可以存。
石鵬：好的瞭解，其實關於存儲這個問題，我們還是更多應該從需求出發。整體來看有一些比較通用的思路，最典型的就是這兩種：
第一種是數據的轉儲。比如像Prometheus，我們在本地只存2周或者4周的數據，然後更多的話，就把它寫到遠端。
第二種思路是做數據採樣。其實在很多監控系統裏面，是一個比較常規的思路，就像在Zabbix裏的history、trend，開始可能是每30秒一個點，然後數據採樣之後，可能是每5分鐘一個點。就用這樣的方式，把這個數據量級減小，然後以此來做存儲問題的優化。
Q3：Zabbix和Prometheus怎麼應對告警風暴和誤報？
蔡翔華：首先誤報這個事情，其實在我理解裏是不存在的。也就是說，之所以我們會覺得很多有誤報的東西存在，是因爲我們對於規則，比方說我監控東西或者是我配置觸發器，本身是有問題的。
我碰到很多人說，打算監控它的CPU使用率，很多人會直接記錄usage，它的使用率，也有很多人會監控它的free的這個space。但有時候會由於配置錯誤，導致原本監控cpu usage的使用了cpu free的指標。所以說，其實很多時候報警之所以會產生誤報，是因爲配置本身不是很正確。
Zabbix的工作機制很簡單：我去收集數據，去根據這個處罰規則去做比較，然後去發報警。當中所有的邏輯其實本身是不會出任何問題，除非說收集數據配錯了、觸發規則配錯了、報警機制配錯了……這些其實更多是人爲的因素在裏面。
所以說，更多的是要通過這種檢查來判斷一下你是否有配錯。
另外一個減少誤報的方式是通過模板化。因爲我們只要配置一次模板，那我把所有的Linux機型的監控模板都統一起來，對於所有監控Linux都套用同一個模板，那麼就可以在一定程度上降低誤報。關鍵還是在於人的問題。
關於告警風暴，其實Zabbix裏有一個特性叫做依賴項目。就比方說我現在有一臺機器宕機，那麼它可能裏面的端口都會不通，然後ping也ping不通，CPU可能也拿不到，可能會有一堆的報警。那麼我們可以把所有的這種依賴項關聯到ping上，一旦ping的機器都死了，上面肯定東西都是宕掉了，這樣子的話，它只會報ping的這一個問題，而不會把這堆機器上所有的東西都給報出來。就好比一個人如果死了，你跟他說這裏有問題那裏有問題，其實沒有任何意義。它就只會把你最終的Root Cause（根因）給報出來，去防範這種告警風暴。
劉宇：是的，誤報我其實跟蔡老師的觀點是很像的，就是告警中其實是存在一個誤報率的，如果你的誤報率很高的話，運維人員就很疲勞了，可能大家都會覺得狼來了，沒有辦法信任你的那種告警，反而你真正發生故障的告警就會被忽略掉。所以制定告警的規則就非常重要，需要想辦法把誤報率給它降低。
那這種規則的制定其實就比較不是那麼具體，會比較抽象，可能比如說把必須要人工介入處理的這種，才把它定爲告警；然後如果系統可以自己處理掉，就不要把它告出來，或者只是在後面做一個每天發一次的報告也就行了。這是我對誤報的一個看法。
關於告警風暴，在Prometheus中，對告警風暴的處理方式是這樣：可以通過靜默告警解決，或者是可以加入維護組，或者是也可以做一個聚合，也就是把告警給聚集，然後同類的告警合併，這樣來減少告警的條數，主要是這樣來做的。
當然如果你有些機器需要維護，它也是可以支持的，就是可以把一些告警直接靜默掉。當然還有就是測試環境，比如說這種告警，你就可以完全忽略掉，我覺得可以這樣來解決。
石鵬：好的，我總結一下，關於誤報這個問題，兩位老師的意見是比較一致的，我也是比較贊同的。誤報其實最根本的原因就是可能你的使用不合理，不管是你的配置還是說你的各種姿勢可能不合理，纔會導致誤報。
然後針對告警風暴，其實Zabbix和Prometheus也就是alert manager，它們都有提供一些相應的功能、特性。在Zabbix這邊的話，可以像蔡老師說的用依賴項，然後也是可以加維護，也可以規避一些告警；然後Prometheus這邊是alert manager它裏面有silent這個靜默規則，也是可以去做一些規避告警這種東西。
可能在很多公司，他們除了監控平臺本身去做告警風暴的抑制，還會有另外一層。比如說我們公司這邊是這樣：
我們有一個告警平臺，所有的告警都會彙集到這個告警平臺裏，然後這個告警平臺會去做一層合併、收斂和抑制。這樣的話，就可以不用特別依賴監控平臺本身來提供這些特性，而是由一個統一的平臺，在做最後發送動作的時候，再來做一層cover。可能在量級大的場景下，這種是比較推薦的一種思路。
蔡翔華：是的，因爲真正的監控當中，其實還會納入很多比方說ES等其它監控平臺，甚至是一些業務告警。當平臺很多的時候，其實你需要有一層聚合的方式，去把告警做一個聚合收斂，然後通過在聚合平臺裏配置一定規則之後，再去做後續的一些報警。
石鵬：沒錯，並且你有這個平臺之後，就可以把一些告警的規則和策略做得更統一，這樣的話，給用戶的界面和體驗也會更好。
蔡翔華：對，所以說其實看公司規模，因爲這一塊會涉及到一些二次開發，如果公司沒有這個能力，那就可以把Zabbix全套或Prometheus全套都用上；如果後續有能力去做這種聚合的話，其實Zabbix也好，Prometheus也好，更多的角色定位會變成一個收集器的角色。然後後面的邏輯其實都交給事件管理平臺或聚合平臺去做。
劉宇：沒錯，這裏Zabbix其實也可以把它的報警發送到alert manager裏，也可以做一些靜默處理，因爲Zabbix本身它的靜默功能確實不是特別多，還是alert manager會做的更好一點。所以兩個工具其實可以結合起來使用。
Q4：在智能監控和自動治癒方面是否有可借鑑的實踐？基於什麼算法或策略？怎麼進行故障預判和預處理？
蔡翔華：首先我們是有嘗試過智能監控，但是包括我看到的很多書籍裏面，包括Prometheus的一些書籍裏面，也說設這種固定的預知是一個很蠢的方法。
根據我這邊實際的應用，其實你要做到智能監控，肯定要有一些大數據的東西，比方說我有這種規律：
例如，按照我們的實際操作裏有很多互聯網的應用，有些東西它就是會有高併發高搶購，可能每個月固定的時候，比如每個月10號放一個活動，活動時它的量是平時的10倍甚至100倍；但也可能有時候，業務會不停地在不同的時間放，你很難去判斷這個點到底是不是一個故障點。
也就是說，你用戶數從10變成了1萬，這1萬到底是因爲故障了，還是說是因爲業務的一些邏輯導致的，很難判斷。所以目前來說，我們嘗試以後，還是用了一些比較固定的報警預知去做。
那麼回到這個話題，Zabbix本身它提供了一些預測的功能，它會預測現在我的磁盤消耗大約什麼時候會消耗到20%以下，或某個閾值以下，它本身是提供了這個功能的。還有一些內置函數可以去做這個計算。但是目前來說，我個人還是建議使用一個比較固定的閾值，可以方便我們有一個明確判斷，否則你早期會有很多的誤報，甚至可能你都會覺得這東西很正常。
預測的數據也是基於現狀的，如果可以對預測數據進行判斷報警，理論上，也可以針對現有的數據進行判斷報警。
劉宇：這塊我們實踐的案例倒不是特別多，我主要還是對數據庫的監控比較熟，所以就說一下我們在數據庫的自動治癒上是怎麼實現的吧。
比如說告警，它發送出來的同時，也會發送給數據庫的一個自動化平臺，這個平臺會有一個程序根據告警內容來調一些自動治癒的程序來處理這種簡單的故障。但這個其實做的也比較有限，就是說我的這種能夠自愈的程序，都是根據具體場景的，並不是所有的東西都可以做。比如說清理日誌、殺讀庫大查詢，以及需要加一些表空間這些場景，類似這種比較固定的會採用自愈來做，其他的嘗試倒不是太多。
石鵬：嗯嗯，這個問題其實比較前沿，並且涉獵的範圍是比較廣的。像自動治癒，其實Zabbix也有一些相關的功能，它可以去配置action，當發現告警，有問題，我就可以綁定腳本去做一下處理。
但這個東西要做到什麼程度，或者說要用什麼技術來打造這個底座，可能都會有些差別。
蔡翔華：是的，因爲我覺得Prometheus和Zabbix或者說其他平臺，都支持調action、調腳本去做一些重啓，但是我覺得關鍵問題的點是在於你敢不敢做這個事情。
因爲我們知道我們的環境其實是很複雜的。比方說，我發覺數據庫宕了，服務停了，我敢不敢通過這個服務自己切過去。因爲很多時候並不是數據庫本身的問題，是網絡的問題，網絡抖動了，監控數據拿不到了。這個是非常依賴於整個整體環境的，你可能要想到方方面面，這個規則會非常複雜。你可能在做服務自愈的時候，還要去對其他的東西做一個完全的檢查，確保其他東西是沒有問題的。
所以不說服務自愈，哪怕在我們日常的故障處理當中，也很依賴於經驗。就是說這個東西是能做的，但是我們不太敢，因爲要考慮的要素很多，就不太敢去直接做自愈這一塊。
石鵬：沒錯，本身其實它是一個體系化的工程，不僅僅是跟監控相關。我這邊的一個想法是這樣，關於自動治癒這塊，我們可能還是要更多去依靠業務側的能力。就是說，業務側要具備一些這種架構設計上的考量，比如說架構的柔性，可以自己去做限流、降級、做熔斷，這要求業務側有這樣的能力纔可以，而不是說僅僅依靠監控系統去做某些動作觸發。
至於說一些算法和策略的話，之前美圖這邊也是有過一些簡單的嘗試，應用不算非常廣泛。但業界的話，DataOps、AIOps的概念也是比較火熱，這些東西在像BAT這些公司其實也有一些實際的應用已經在落地了。
之前我們做的話，有做這麼幾個小東西，關於故障預測是有這麼幾個算法：有同期的數據比較、同期的振幅比較、有一個移動平均算法、然後再有一個變點監測。然後這幾個的話，可以簡單說一下思路，其實也比較好理解。
同期數據，是我按照週期，比如說今天某個時間點這個數據，我去比較昨天這個點是什麼樣子的，去比較數據；
振幅，其實它就相對更柔性一點，裏面會給你加上一個權重，加上一個比例，比如正態分佈裏邊的3-sigma，作爲振幅係數去比較同期的數據，看在算上振幅之後，你是不是已經超出了，去做一個預測；
變點監測，就是說我整體的數據曲線是什麼樣子的，突然出現了一個離我正常預測曲線偏離非常遠的一個點，這種的話會有一個這樣的算法來做這個事情。
然後這塊相對比較成熟的工具的話，像騰訊之前有開源的運維學件METIS，它裏面集成了非常多的算法模型，這個有興趣的同學可以去做一些瞭解。
Q5：監控大屏是怎麼設計的？
蔡翔華：首先從技術本身來說，5.0版本可以看到Zabbix的UI都很不錯，可以很多的組、主機都往大屏裏面去拖。大屏的話，我們大概會分幾塊：
第一塊是整個系統運行狀態。我可能整個系統有從用戶登錄到用戶支付，包括到購物車等等，有一個鏈路。我對於每個鏈路其實都會有一個監控，它每一個S組 Service的組，那麼Service的組裏麪包括它的應用、數據庫緩存、應用系統甚至硬件服務器，一旦這裏有任何東西出問題之後，直接會在大屏上顯示一個警告，那麼我就會知道現在整個生產環節哪個系統是有問題的。
那麼另外就是一個summary，一個overview的全局的導覽，因爲一旦我知道這個有問題，我就希望更加細化知道這個東西哪裏有問題。那麼在下面就會有一個trigger list的問題列表，就是說有哪些觸發器被觸發了，我會看到比方說，數據庫端口不通了，還是說磁盤空間已經滿了。下面會有trigger list，然後這個trigger list會按照故障等級是disaster還是warning，同時對應的管理員或者運維人員也會收到這個短信，就知道要立即去處理了。
所以我們儘可能就在大屏裏從兩方面來把控，一方面從大的來講，有一個over view看到全局，從小的來講，我要知道我的故障發生在哪裏。基本上保證這兩個要素在大屏裏面就OK了。
劉宇：我們這邊大屏其實主要還是應用的維度以及網絡流量的維度爲主。比如說從公網的一個出口和入口的流量來看會不會有大面積的一個問題。如果發現已經達到外面防火牆或者它流量的一個閾值了，就可以迅速定位問題。
如果是細節的話，我們會在大型活動前夕，梳理活動鏈路上的所有應用，根據應用的維度來設計這樣一個大屏。大屏可以看到鏈路上所有應用、數據庫或者是中間件的情況，一旦哪個應用的QPS高了，或者是其他壓力的情況，就可以第一時間定位到問題出現在哪裏，是這樣一個思路來做。
石鵬：監控大屏做得好，確實可以輔助我們技術同學去更快地定位和排查問題，還有一個比較重要的點，我是這麼想的，就是老闆會關注。有些公司會把大屏設計得非常有科技感，讓老闆看的話，可能老闆也覺得我的技術團隊還挺牛的。當然這是一個題外話。
前面蔡老師和劉老師都給了一些建設上的思路，就是你應該去包含哪些數據，應該怎麼去做。這方面的話，我的一個思考是你可能要去做服務的梳理，然後可以以分塊、分業務或者說按照分層的方式來做。
分塊的話，就是你按照業務線來分。你公司可能有很多塊業務，然後按照不同的業務去提供一個視角。在每個業務裏，你可以去做分層，分層的意思就是說可以把整個鏈路，從客戶端一直到CDN、 DNS鏈路，然後到LB入口層，以及應用這一層是什麼樣的，再關聯到後面的一些後端資源，像數據庫、緩存這些東西，還有一些其他的周邊依賴，按照這樣分層的方式來做。
關於技術實現方面，我簡單贅述兩句。我們公司的監控大屏是用了Grafana來做的，Grafana可能已經成爲了事實上的監控UI、數據可視化的標準了，它可以後面去接各種各樣的數據源，然後你各個監控系統、各種數據原理的數據可以統一來展示。
這裏需要感謝一個社區的插件，叫Flow Charting，這個插件可以非常好地去做監控鏈路的事情，就是你可以用這個插件去把整個鏈路關鍵環節，以這種圖的方式繪製出來，然後給每一個點、每一條線綁定上監控數據，最後生成的圖就動起來了，就可以看到一個全局性的鏈路狀態：從入口一直到後端資源，包括各種依賴，當前它的狀態是什麼樣子的。
當然這個前提是，你整個鏈路的監控數據是要完備的，然後你纔可以藉助這個插件去把它呈現出來，大概是這個樣子的，在這個圖上就一目瞭然了。
Q6：自動化運維管理是Zabbix和Prometheus同時使用還是二選一更合適？
蔡翔華：如果是個純容器化的，就說你環境裏面全是Docker，那麼說實話我也不推薦你去使用Zabbix。
因爲Zabbix對容器的監控，雖然官方已經開始重視了，甚至說現在也支持了Prometheus的很多metrics和exporter這種方式去做監控，就是它也可以原生的去支持Prometheus這些東西，但相對來說，Prometheus在容器化監控這邊還是會更好一些。
如果你的監控需求是又要監控硬件服務器，又要監控中間件，又要監控業務指標，那麼我推薦使用Zabbix，因爲Zabbix覆蓋的面會更廣一些。
的確我覺得任何需求Zabbix和Prometheus都可以去做，但是從實現成本來說，相對於Prometheus，你的服務環境越複雜，Zabbix可能就越適合這種比較複雜的異構的環境。
劉宇：我們目前公司情況是兩個都在用，的確是偏容器的會往Prometheus優先考慮，如果是舊的，比如說是有偏服務化的這種監控，也會慢慢地往Prometheus做一些遷移。
如果你的環境是一種就可以滿足的話，建議還是一種，因爲畢竟只需要維護一種技術棧就可以了。或者是你可以做一些偏重，比如說把一些不變的放在一種上面，經常會變的放在另外一種上面。儘量去減少你維護的技術棧。如果你的環境比較簡單的話，只用一種，當然是最好了。
石鵬：其實還是看場景，美圖跟劉老師這邊比較類似，我們也是多種監控工具在用，不過我們現在沒有在用Zabbix，是用了Open-Falcon、Prometheus、InfluxDB，還有很多基於大數據的一些流式處理的組件，我們都是混合在用。
主要還是看你具體的需求和場景，沒有銀彈，沒有說一個工具可以非常合適去搞定所有事情。當然它有可能有能力，但是它並不一定特別合適。至於具體的選擇上，還是要看具體場景。比較明確的一個思路可能就是要看你的監控對象到底是容器還是非容器，它是這種易變的還是比較穩定態的。這兩個思路的話，也是跟蔡老師和劉老師比較一致的。
Q7：分佈式鏈路的可觀測性和端到端診斷怎麼做？
蔡翔華：分佈式鏈路其實我們沒有用Zabbix，因爲分佈式鏈路要考慮上下游的關係，所以我們會基於APM去做。現在像業內比較流行的CAT，可以參考這些去做。
端到端的偵測的話，其實Zabbix也支持，它支持兩種方式：
一個是它可以在本地跑一些腳本去做，就是說我這個檢測是從Zabbix某個Agen端出發，到另外一臺目標機器，而不是通過Zabbix server去做檢測。所以說這是Zabbix 提供的另外一種方式，Zabbix active的一種方式，它可以去實現這種端到端的偵測。Zabbix active的監控方式也是比較好的一種方式，可以減輕Zabbix server端的壓力，或proxy端的壓力，能提供更豐富的一些監控。
劉宇：這塊因爲Prometheus是一個基於數值的監控，對於這種全鏈路的話，一般不太會用Prometheus來做，基本上會用APM的一些分佈式鏈路追蹤的工具，比如skywalking等來做。
還會通過一些日誌系統來做分佈式的監控，在鏈路上，提前寫入一些標籤，這樣從始至終都可以拿到整個鏈路上的一個關係，就可以做一些分佈式鏈路上的監控的東西。
石鵬：是的，這也就回到我們前面討論的，沒有銀彈，沒有一種技術棧可以解決所有需求的。包括Zabbix和Prometheus，其實更關注的還是在偏服務端，如果是應用端的話，其實還是要依賴一些APM的工具。就像劉老師說的Apache的skywalking，還有像鷹眼、基於open tracing的其他工具。這些東西其實都是一種思路。
還有一些有技術能力的公司，會選擇自研一些APM工具，需要自己去開發各種SDK，然後需要遷到客戶端，去上報數據，是這個樣子的。
其實端到端整體的建設思路應該是分段的，客戶端的是一段，中間鏈路是一段，服務端又是另外一側。所以想做端到端，很難說用一個工具就可以完全覆蓋起來。
現在基於雲原生、微服務這些發展的比較火熱，可能會有一些各個服務之間調用鏈路的服務治理相關的監控需求，可能也不是說通過Prometheus或Zabbix就可以很好地去完成。還是要看需求場景，選擇更合適的工具，並且組合起來使用。
Q8：大規模場景下，Prometheus和Zabbix的性能和成本哪個比較低？
蔡翔華：首先我覺得還是看應用場景，因爲大規模場景下，要看這個場景是容器多還是非容器環境多，這是一個主要依據。
Zabbix性能的話，其實瓶頸主要是在數據庫，只要把數據庫的優化做得足夠好，其實開頭也說了，業內也有做到40萬NVPS的這種案例，已經是比較變態了。那無非就是說，去做數據庫分區分庫拆表、加SSD存儲，通過這種方式。
成本的話，我個人覺得在底層資源滿足的前提下，成本應該都OK。因爲Prometheus是基於exporter，Zabbix是基於Agent，通過Zabbix agent，配合自動發現和低級別發現的這種方式去實現自動化。
配置成本可能Zabbix會低很多，因爲都是基於UI去做，而Prometheus是基於配置文件去做，這個可能Zabbix會更好些。所以我綜合成本，覺得Zabbix稍微會好一些，但還是取決於你的場景裏有多少虛擬化。
劉宇：我覺得如果是性能的話，通過一些分區的手段都能解決。但如果是非常大的規模，通過Zabbix，其實它的數據庫瓶頸還是比較嚴重的，這塊還是需要一些比較好優化手段才能解決。
監控採集的agent的方式而言，我覺得Prometheus的exporter做得非常全面，像我們以前用Zabbix，基本上有很多東西監控都是自己去開發的；而現在用Prometheus，基本上對於這種採集器的開發都沒有了，用社區的就可以全部解決了。所以在採集的層面上，去實現它最底層和服務的一個數據採集，我感覺Prometheus的成本會更低一點。
當然因爲Prometheus相對來說還是一個微服務的架構，它的所有組件都是分開的，在搭建成本、學習成本會稍微高一點。
石鵬：其實還是要針對個性化的場景去做一些選擇。成本的話，如果說你的環境是一個比較純粹的，要麼是全容器，要麼是虛擬化或者物理環境，你就選一種就好了。如果說你是異構的話，可能就不可避免的要選兩種同時維護。這兩種裏如果有所側重的話，成本其實就會有所側重，所以還是看你的具體需求。
歡迎點贊+收藏+轉發朋友圈素質三連
文章不錯？點個【在看】吧！
本文分享自微信公衆號 - 大數據技術與架構（import_bigdata）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。