之前，我寫過幾篇有關「線上問題排查」的文章，文中附帶了一些監控圖，有些讀者對此很感興趣，問我監控系統選型上有沒有好的建議？
目前我所經曆的幾家公司，監控系統都是自研的。其實業界有很多優秀的開源産品可供選擇，能滿足絕大部分的監控需求，如果能從中選擇一款滿足企業當下的訴求，顯然最省時省力。
這篇文章，我将對監控體系的基礎知識、原理和架構做一次系統性整理，同時還會對幾款最常用的開源監控産品做下介紹，以便大家選型時參考。内容包括3部分：
- 必知必會的監控基礎知識
- 主流監控系統介紹
- 監控系統的選型建議
一、必知必會的監控基礎知識
監控系統俗稱「第三隻眼」，幾乎是我們每天都會打交道的系統，下面 4 項基礎知識我認為是必須要了解的。
1. 監控系統的7大作用
正所謂「無監控，不運維」，監控系統的地位不言而喻。不管你是監控系統的開發者還是使用者，首先肯定要清楚：監控系統的目标是什麼？它能發揮什麼作用？
- 實時采集監控資料：包括硬體、作業系統、中間件、應用程式等各個次元的資料。
- 實時回報監控狀态：通過對采集的資料進行多元度統計和可視化展示，能實時展現監控對象的狀态是正常還是異常。
- 預知故障和告警：能夠提前預知故障風險，并及時發出告警資訊。
- 輔助定位故障：提供故障發生時的各項名額資料，輔助故障分析和定位。
- 輔助性能調優：為性能調優提供資料支援，比如慢SQL，接口響應時間等。
- 輔助容量規劃：為伺服器、中間件以及應用叢集的容量規劃提供資料支撐。
- 輔助自動化運維：為自動擴容或者根據配置的SLA進行服務降級等智能運維提供資料支撐。
2. 使用監控系統的正确姿勢
“
出任何線上事故，先不說其他地方有問題，監控部分一定是有問題的。
聽着很甩鍋的一句話，仔細思考好像有一定道理。我們在事故複盤時，通常會思考這3個和監控有關的問題：有沒有做監控？監控是否及時？監控資訊是否有助于快速定位問題？
可見光有一套好的監控系統還不夠，還必須知道「如何用好它」。一個成熟的研發團隊通常會定一個監控規範，用來統一監控系統的使用方法。
- 了解監控對象的工作原理：要做到對監控對象有基本的了解，清楚它的工作原理。比如想對JVM進行監控，你必須清楚JVM的堆記憶體結構和垃圾回收機制。
- 确定監控對象的名額：清楚使用哪些名額來刻畫監控對象的狀态？比如想對某個接口進行監控，可以采用請求量、耗時、逾時量、異常量等名額來衡量。
- 定義合理的報警門檻值和等級：達到什麼門檻值需要告警？對應的故障等級是多少？不需要處理的告警不是好告警，可見定義合理的門檻值有多重要，否則隻會降低運維效率或者讓監控系統失去它的作用。
- 建立完善的故障處理流程：收到故障告警後，一定要有相應的處理流程和oncall機制，讓故障及時被跟進處理。
3. 監控的對象和名額都有哪些？
監控已然成為了整個産品生命周期非常重要的一環，運維關注硬體和基礎監控，研發關注各類中間件和應用層的監控，産品關注核心業務名額的監控。可見，監控的對象已經越來越立體化。
這裡，我對常用的監控對象以及監控名額做了分類整理，供大家參考。
3.1 硬體監控
包括：電源狀态、CPU狀态、機器溫度、風扇狀态、實體磁盤、raid狀态、記憶體狀态、網卡狀态
3.2 伺服器基礎監控
- CPU：單個CPU以及整體的使用情況
- 記憶體：已用記憶體、可用記憶體
- 磁盤：磁盤使用率、磁盤讀寫的吞吐量
- 網絡：出口流量、入口流量、TCP連接配接狀态
3.3 資料庫監控
包括：資料庫連接配接數、QPS、TPS、并行處理的會話數、緩存命中率、主從延時、鎖狀态、慢查詢
3.4 中間件監控
- Nginx：活躍連接配接數、等待連接配接數、丢棄連接配接數、請求量、耗時、5XX錯誤率
- Tomcat：最大線程數、目前線程數、請求量、耗時、錯誤量、堆記憶體使用情況、GC次數和耗時
- 緩存 ：成功連接配接數、阻塞連接配接數、已使用記憶體、記憶體碎片率、請求量、耗時、緩存命中率
- 消息隊列：連接配接數、隊列數、生産速率、消費速率、消息堆積量
3.5 應用監控
- HTTP接口：URL存活、請求量、耗時、異常量
- RPC接口：請求量、耗時、逾時量、拒絕量
- JVM ：GC次數、GC耗時、各個記憶體區域的大小、目前線程數、死鎖線程數
- 線程池：活躍線程數、任務隊列大小、任務執行耗時、拒絕任務數
- 連接配接池：總連接配接數、活躍連接配接數
- 日志監控：通路日志、錯誤日志
- 業務名額：視業務來定，比如PV、訂單量等
4. 監控系統的基本流程
無論是開源的監控系統還是自研的監控系統，監控的整個流程大同小異，一般都包括以下子產品：
- 資料采集：采集的方式有很多種，包括日志埋點進行采集（通過Logstash、Filebeat等進行上報和解析），JMX标準接口輸出監控名額，被監控對象提供REST API進行資料采集（如Hadoop、ES），系統指令行，統一的SDK進行侵入式的埋點和上報等。
- 資料傳輸：将采集的資料以TCP、UDP或者HTTP協定的形式上報給監控系統，有主動Push模式，也有被動Pull模式。
- 資料存儲：有使用MySQL、Oracle等RDBMS存儲的，也有使用時序資料庫RRDTool、OpentTSDB、InfluxDB存儲的，還有使用HBase存儲的。
- 資料展示：資料名額的圖形化展示。
- 監控告警：靈活的告警設定，以及支援郵件、短信、IM等多種通知通道。
二、主流監控系統介紹
下面再來認識下主流的開源監控系統，由于篇幅有限，我挑選了3款使用最廣泛的監控系統：Zabbix、Open-Falcon、Prometheus，會對它們的架構進行介紹，同時總結下各自的優劣勢。
1. Zabbix（老牌監控的優秀代表）
Zabbix 1998年誕生，核心元件采用C語言開發，Web端采用PHP開發。它屬于老牌監控系統中的優秀代表，監控功能很全面，使用也很廣泛，差不多有70%左右的網際網路公司都曾使用過 Zabbix 作為監控解決方案。
先來了解下Zabbix的架構設計：
Zabbix架構圖
- Zabbix Server：核心元件，C語言編寫，負責接收Agent、Proxy發送的監控資料，也支援JMX、SNMP等多種協定直接采集資料。同時，它還負責資料的彙總存儲以及告警觸發等。
- Zabbix Proxy：可選元件，對于被監控機器較多的情況下，可使用Proxy進行分布式監控，它能代理Server收集部分監控資料，以減輕Server的壓力。
- Zabbix Agentd：部署在被監控主機上，用于采集本機的資料并發送給Proxy或者Server，它的插件機制支援使用者自定義資料采集腳本。Agent可在Server端手動配置，也可以通過自動發現機制被識别。資料收集方式同時支援主動Push和被動Pull 兩種模式。
- Database：用于存儲配置資訊以及采集到的資料，支援MySQL、Oracle等關系型資料庫。同時，最新版本的Zabbix已經開始支援時序資料庫，不過成熟度還不高。
- Web Server：Zabbix的GUI元件，PHP編寫，提供監控資料的展現和告警配置。
下面是 Zabbix 的優勢：
- 産品成熟：由于誕生時間長且使用廣泛，擁有豐富的文檔資料以及各種開源的資料采集插件，能覆寫絕大部分監控場景。
- 采集方式豐富：支援Agent、SNMP、JMX、SSH等多種采集方式，以及主動和被動的資料傳輸方式。
- 較強的擴充性：支援Proxy分布式監控，有agent自動發現功能，插件式架構支援使用者自定義資料采集腳本。
- 配置管理友善：能通過Web界面進行監控和告警配置，操作友善，上手簡單。
下面是 Zabbix 的劣勢：
- 性能瓶頸：機器量或者業務量大了後，關系型資料庫的寫入一定是瓶頸，官方給出的單機上限是5000台，個人感覺達不到，尤其現在應用層的名額越來越多。雖然最新版已經開始支援時序資料庫，不過成熟度還不高。
- 應用層監控支援有限：如果想對應用程式做侵入式的埋點和采集（比如監控線程池或者接口性能），zabbix沒有提供對應的sdk，通過插件式的腳本也能曲線實作此功能，個人感覺zabbix就不是做這個事的。
- 資料模型不強大：不支援tag，是以沒法按多元度進行聚合統計和告警配置，使用起來不靈活。
- 友善二次開發難度大：Zabbix采用的是C語言，二次開發往往需要熟悉它的資料表結構，基于它提供的API更多隻能做展示層的定制。
2. Open-Falcon（小米出品，國内流行）
Open-falcon 是小米2015年開源的企業級監控工具，采用Go和Python語言開發，這是一款靈活、高性能且易擴充的新一代監控方案，目前小米、美團、滴滴等超過200家公司在使用它。
小米初期也使用的Zabbix進行監控，但是機器量和業務量上來後，Zabbix就有些力不從心了。是以，後來自主研發了Open-Falcon，在架構設計上吸取了Zabbix的經驗，同時很好地解決了Zabbix的諸多痛點。
先來了解下Open-Falcon的架構設計：
Open-Falcon架構圖，來自網絡
- Falcon-agent：資料采集器和收集器，Go開發，部署在被監控的機器上，支援3種資料采集方式。首先它能自動采集單機200多個基礎監控名額，無需做任何配置；同時支援使用者自定義的plugin擷取監控資料；此外，使用者可通過http接口，自主push資料到本機的proxy-gateway，由gateway轉發到server.
- Transfer：資料分發元件，接收用戶端發送的資料，分别發送給資料存儲元件Graph和告警判定元件Judge，Graph和Judge均采用一緻性hash做資料分片，以提高橫向擴充能力。同時Transfer還支援将資料分發到OpenTSDB，用于曆史歸檔。
- Graph：資料存儲元件，底層使用RRDTool（時序資料庫）做單個名額的存儲，并通過緩存、分批寫入磁盤等方式進行了優化。據說一個graph執行個體能夠處理8W+每秒的寫入速率。
- Judge和Alarm：告警元件，Judge對Transfer元件上報的資料進行實時計算，判斷是否要産生告警事件，Alarm元件對告警事件進行收斂處理後，将告警消息推送給各個消息通道。
- API：面向終端使用者，收到查詢請求後會去Graph中查詢名額資料，彙總結果後統一傳回給使用者，屏蔽了存儲叢集的分片細節。
下面是Open-Falcon的優勢：
- 自動采集能力：Falcon-agent 能自動采集伺服器的200多個基礎名額（比如CPU、記憶體等），無需在server上做任何配置，這一點可以秒殺Zabbix.
- 強大的存儲能力：底層采用RRDTool，并且通過一緻性hash進行資料分片，建構了一個分布式的時序資料存儲系統，可擴充性強。
- 靈活的資料模型：借鑒OpenTSDB，資料模型中引入了tag，這樣能支援多元度的聚合統計以及告警規則設定，大大提高了使用效率。
- 插件統一管理：Open-Falcon的插件機制實作了對使用者自定義腳本的統一化管理，可通過HeartBeat Server分發給agent，減輕了使用者自主維護腳本的成本。
- 個性化監控支援：基于Proxy-gateway，很容易通過自主埋點實作應用層的監控（比如監控接口的通路量和耗時）和其他個性化監控需求，內建友善。
下面是Open-Falcon的劣勢：
- 整體發展一般：社群活躍度不算高，同時版本更新慢，有些大廠是基于它的穩定版本直接做二次開發的，關于以後的前景其實有點擔憂。
- UI不夠友好：對于業務線的研發來說，可能隻想便捷地完成告警配置和業務監控，但是它把機器分組、政策模闆、模闆繼承等概念全部暴露在UI上，感覺在圍繞這幾個概念設計UI，了解有點費勁。
- 安裝比較複雜：個人的親身感受，由于它是從小米内部衍生出來的，雖然去掉了對小米内部系統的依賴，但是元件還是比較多，如果對整個架構不熟悉，安裝很難一蹴而就。
3. Prometheus（号稱下一代監控系統）
Prometheus（普羅米修斯）是由前google員工2015年正式釋出的開源監控系統，采用Go語言開發。它不僅有一個很酷的名字，同時它有Google與k8s的強力支援，開源社群異常火爆。
Prometheus 2016年加入雲原生基金會，是繼k8s後托管的第二個項目，未來前景被相當看好。它和Open-Falcon最大不同在于：資料采集是基于Pull模式的，而不是Push模式，并且架構非常簡單。
先來了解下Prometheus的架構設計：
Prometheus架構圖，來自網絡
- Prometheus Server：核心元件，用于收集、存儲監控資料。它同時支援靜态配置和通過Service Discovery動态發現來管理監控目标，并從監控目标中擷取資料。此外，Prometheus Server 也是一個時序資料庫，它将監控資料儲存在本地磁盤中，并對外提供自定義的 PromQL 語言實作對資料的查詢和分析。
- Exporter：用來采集資料，作用類似于agent，差別在于Prometheus是基于Pull方式拉取采集資料的，是以，Exporter通過HTTP服務的形式将監控資料按照标準格式暴露給Prometheus Server，社群中已經有大量現成的Exporter可以直接使用，使用者也可以使用各種語言的client library自定義實作。
- Push gateway：主要用于瞬時任務的場景，防止Prometheus Server來pull資料之前此類Short-lived jobs就已經執行完畢了，是以job可以采用push的方式将監控資料主動彙報給Push gateway緩存起來進行中轉。
- Alert Manager：當告警産生時，Prometheus Server将告警資訊推送給Alert Manager，由它發送告警資訊給接收方。
- Web UI：Prometheus内置了一個簡單的web控制台，可以查詢配置資訊和名額等，而實際應用中我們通常會将Prometheus作為Grafana的資料源，建立儀表盤以及檢視名額。
下面是Prometheus的優勢：
- 輕量管理：架構簡單，不依賴外部存儲，單個伺服器節點可直接工作，二進制檔案啟動即可，屬于輕量級的Server，便于遷移和維護。
- 較強的處理能力：監控資料直接存儲在Prometheus Server本地的時序資料庫中，單個執行個體可以處理數百萬的metrics。
- 靈活的資料模型：同Open-Falcon，引入了tag，屬于多元資料模型，聚合統計更友善。
- 強大的查詢語句：PromQL允許在同一個查詢語句中，對多個metrics進行加法、連接配接和取分位值等操作。
- 很好地支援雲環境：能自動發現容器，同時k8s和etcd等項目都提供了對Prometheus的原生支援，是目前容器監控最流行的方案。
下面是Prometheus的劣勢：
- 功能不夠完善：Prometheus從一開始的架構設計就是要做到簡單，不提供叢集化方案，長期的持久化存儲和使用者管理，而這些是企業變大後所必須的特性，目前要做到這些隻能在Prometheus之上進行擴充。
- 網絡規劃變複雜：由于Prometheus采用的是Pull模型拉取資料，意味着所有被監控的endpoint必須是可達的，需要合理規劃網絡的安全配置。
三、監控系統的選型建議
通過上面的介紹，大家對主流的監控系統應該有了一定的認識。面對選型問題，我的建議是：
1、先明确清楚你的監控需求：要監控的對象有哪些？機器數量和監控名額有多少？需要具備什麼樣的告警功能？
2、監控是一項長期建設的事情，一開始就想做一個 All In One 的監控解決方案，我覺得沒有必要。從成本角度考慮，在初期直接使用開源的監控方案即可，先解決有無問題。
3、從系統成熟度上看，Zabbix屬于老牌的監控系統，資料多，功能全面且穩定，如果機器數量在幾百台以内，不用太擔心性能問題，另外，采用資料庫分區、SSD硬碟、Proxy架構、Push采集模式都可以提高監控性能。
4、Zabbix在伺服器監控方面占絕對優勢，可以滿足90%以上的監控場景，但是應用層的監控似乎并不擅長，比如要監控線程池的狀态、某個内部接口的執行時間等，這種通常都要做侵入式埋點。相反，新一代的監控系統Open-Falcon和Prometheus在這一點做得很好。
5、從整體表現上來看，新一代監控系統也有明顯的優勢，比如：靈活的資料模型、更成熟的時序資料庫、強大的告警功能，如果之前對zabbix這種傳統監控沒有技術積累，建議使用Open-Falcon或者Prometheus.
6、Open-Falcon的核心優勢在于資料分片功能，能支撐更多的機器和監控項；Prometheus則是容器監控方面的标配，有Google和k8s加持。
7、Zabbix、Open-Falcon和Prometheus都支援和Grafana做快速內建，想要美觀且強大的可視化體驗，可以和Grafana進行組合。
8、用合适的監控系統解決相應的問題即可，可以多套監控同時使用，這種在企業初期很常見。
9、到中後期，随着機器資料增加和個性化需求增多（比如希望統一監控平台、打通公司的CMDB群組織架構關系），往往需要二次開發或者通過監控系統提供的API做內建，從這點來看，Open-Falcon或者Prometheus更合适。
10、如果非要自研，可以多研究下主流監控系統的架構方案，借鑒它們的優勢。
最後的話
本文對監控體系的基礎知識、原理和主流架構做了詳細梳理，希望有助于大家對監控系統的認識，以及在技術選型時做出更合适的選擇。
由于篇幅問題，本文的内容并未涉及到全鍊路監控、日志監控、以及Web前端和用戶端的監控，可見監控真的是一個龐大且複雜的體系，如果想了解透徹，必須理論結合實踐再做深入。
對于運維監控體系，如果你們也有自己的經驗和體會，歡迎留言讨論。
文章來源：https://mp.weixin.qq.com/s?__biz=MzI3MzEzMDI1OQ==&mid=2651823979&idx=2&sn=323ea30f729846a1b25516567fd60097&chksm=f0dcc917c7ab4001bbd5a7eebe0db56a5118a6392a5c95b07643ea80ca8522fb580618ae48c4&scene=21#wechat_redirect