監控系統選型，一文輕鬆搞定！
這篇文章，我將對監控體系的基礎知識、原理和架構做一次系統性整理，同時還會對幾款最常用的開源監控產品做下介紹，以便大家選型時參考。內容包括 3 部分：
-
必知必會的監控基礎知識
-
主流監控系統介紹
-
監控系統的選型建議
必知必會的監控基礎知識
我們可以理解監控系統就像我們古代打戰的哨兵一樣，哨兵的角色非常重要，敵人來了，哨兵會第一時間發出預警 (吹笛、打鼓、放煙)，讓守城的戰士能夠最快的時間處理，應對。
那對於我們應用系統而言，監控系統就像我們第三隻眼，如果有應用系統出現問題，我們可以通過監控系統看是哪裏出現問題，是 redis 掛了，還是說服務器內存滿了，有監控系統我們可以很輕鬆、快速的定位問題。
甚至我們可以設置預警，對一些將要出現的問題進行提前預防處理，及時避免問題的發生。
1、監控系統的作用
-
「幫助定位故障」: 在發生故障時，我們可以通過查看監控系統的各項指標數據，輔助故障分析和定位。
-
「預警減少故障率」: 對於即將可能產生的故障能夠及時發出預警信息，做好提前預防處理。
-
「輔助容量規劃」: 爲服務器、中間件以及應用集羣的容量規劃提供數據支撐。
-
「輔助性能調優」: JVM 垃圾回收次數、接口響應時間、慢 SQL 等等都可以監控優化。
2、常見的監控對象和指標都有哪些？
-
「服務器監控」: CPU 使用率、內存使用率、磁盤使用率、磁盤讀寫的吞吐量、網絡出入流量等等。
-
「MySQL 監控」: TPS、QPS、數據庫連接數、慢 SQL、InnoDB 緩衝池命中率等等。
-
「Redis 監控」: 內存使用率、緩存命中率、key 值總數、Redis 響應請求時間、客戶端連接數、持久性指標等等。
-
「MQ 監控」: 連接數、隊列數、生產速率、消費速率、消息堆積量等等。
-
「應用監控」:
-
HTTP 接口：URL 存活、請求量、耗時、異常量
-
JVM：GC 次數、GC 耗時、各個內存區域的大小、當前線程數、死鎖線程數
-
線程池：活躍線程數、任務隊列大小、任務執行耗時、拒絕任務數
3、監控系統的基本流程
-
「數據採集」：採集的方式有很多種，包括日誌埋點進行採集，JMX 標準接口輸出監控指標，被監控對象提供 REST API 進行數據採集（如 Hadoop、ES），系統命令行，統一的 SDK 進行侵入式的埋點和上報等。
-
「數據傳輸」：將採集的數據以 TCP、UDP 或者 HTTP 協議的形式上報給監控系統，有主動 Push 模式，也有被動 Pull 模式。
-
「數據存儲」：有使用 MySQL、Oracle 等關係數據庫存儲的，也有使用時序數據庫 RRDTool、OpentTSDB、InfluxDB 存儲的，還有使用 HBase 存儲的。
-
「數據展示」：數據指標的圖形化展示。
-
「監控告警」：靈活的告警設置，以及支持郵件、短信、IM 等多種通知通道。
市面上的一些常見監控系統比較
下面再來認識下主流的開源監控系統，由於篇幅有限，我挑選了 3 款使用最廣泛的監控系統：「Zabbix」、「Open-Falcon」、「Prometheus」，會對它們的架構進行介紹，同時總結下各自的優劣勢。
1、Zabbix 介紹
Zabbix 1998 年誕生，核心組件採用 C 語言開發，Web 端採用 PHP 開發。它屬於老牌監控系統中的優秀代表，監控功能很全面，使用也很廣泛，差不多有 70% 左右的互聯網公司都曾使用過 Zabbix 作爲監控解決方案。
先來了解下 Zabbix 的架構設計：
-
「Zabbix Server」：核心組件，C 語言編寫，負責接收 Agent、Proxy 發送的監控數據。同時，它還負責數據的彙總存儲以及告警觸發等。
-
「Zabbix Proxy」：可選組件，對於被監控機器較多的情況下，可使用 Proxy 進行分佈式監控，它能代理 Server 收集部分監控數據，以減輕 Server 的壓力。
-
「Zabbix Agentd」：部署在被監控主機上，用於採集本機的數據併發送給 Proxy 或者 Server。數據收集方式同時支持主動 Push 和被動 Pull 兩種模式。
-
「Database」：用於存儲配置信息以及採集到的數據，支持 MySQL、Oracle 等關係型數據庫。同時，最新版本的 Zabbix 已經開始支持時序數據庫，不過成熟度還不高。
-
「Web Server」：Zabbix 的 GUI 組件，PHP 編寫，提供監控數據的展現和告警配置。
Zabbix 的優勢：
-
「產品成熟」：由於誕生時間長且使用廣泛，擁有豐富的文檔資料以及各種開源的數據採集插件，能覆蓋絕大部分監控場景。
-
「採集方式豐富」：支持
Agent、SNMP、JMX、SSH等多種採集方式，以及主動和被動的數據傳輸方式。
Zabbix 的劣勢：
需要在被監控主機上安裝 Agent，所有的數據都存在數據庫裏，產生的數據很大，瓶頸主要在數據庫。
2、Open-Falcon（小米出品，國內流行）
Open-falcon 是小米 2015 年開源的企業級監控工具，採用 Go 和 Python 語言開發，這是一款靈活、高性能且易擴展的新一代監控方案，目前小米、美團、滴滴等超過 200 家公司在使用它。
小米初期也使用的 Zabbix 進行監控，但是機器量和業務量上來後，Zabbix 就有些力不從心了。因此，後來自主研發了 Open-Falcon，在架構設計上吸取了 Zabbix 的經驗，同時很好地解決了 Zabbix 的諸多痛點。
架構看去比 Zabbix 複雜多了，其實它也是基於Server---Agent的模式，只不過 Server 又給他劃分了好幾個組件，這個耦合性和擴展性都得到了明顯提高。
-
「Falcon-agent」：數據採集器和收集器，Go 開發，部署在被監控的機器上。就相當於 Agent，用於採集機器負載監控指標數據如：CPU、內存、磁盤、IO、網絡、端口等等大概有 200 多個這些都可以自定是否收集。
-
「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 缺點
-
「監控類型較少」: 不支持常用應用服務器如 tomcat、apache、jetty 等的監控。
-
「整體發展一般，社區活躍度低」: 沒有專門的運維支持，代碼更新較少，沒有一個較大的社區來維護，後續想要有什麼新的能力基本只能指望自己擴展。
3、Prometheus（號稱下一代監控系統）
我們知道 zabbix 在監控界佔有不可撼動的地位，功能強大。但是對容器監控顯得力不從心。爲解決監控容器的問題，引入了 Prometheus 技術。
Prometheus 是一套開源的系統監控報警框架。是由前 google 員工 2015 年正式發佈的開源監控系統，採用 Go 語言開發。它不僅有一個很酷的名字，同時它有 Google 與 k8s 的強力支持，開源社區異常火爆。
先來了解下Prometheus的架構設計：
-
「Exporter」：主要用來採集數據，並通過 HTTP 服務的形式暴露給
Prometheus Server，Prometheus Server通過訪問該Exporter提供的接口，即可獲取到需要採集的監控數據。常見的 Exporter 有很多，例如node_exporter、mysqld_exporter、redis_exporter等 -
「Prometheus Server」：核心組件，負責實現對監控數據的獲取，存儲以及查詢。
Prometheus Server也是一個時序數據庫，它將監控數據保存在本地磁盤中，並對外提供自定義的 PromQL 語言實現對數據的查詢和分析。 -
「Push gateway」：由於
Prometheus數據採集採用 pull 方式進行設置的， 內置必須保證prometheus server和對應的 exporter 必須通信，當網絡情況無法直接滿足時，可以使用pushgateway來進行中轉，可以通過pushgateway將內部網絡數據主動 push 到 gateway 裏面去，而prometheus採用 pull 方式拉取pushgateway中數據。 -
「Alert Manager」：當支持基於 PromQL 創建告警規則，如果滿足定義的規則，則會產生一條告警信息，進入
AlertManager進行處理。可以集成郵件，微信或者通過webhook自定義報警。 -
「Web UI」：
Prometheus內置了一個簡單的 web 控制檯，可以查詢配置信息和指標等，而實際應用中我們通常會將Prometheus作爲 Grafana 的數據源，創建儀表盤以及查看指標。
Prometheus 優點
-
「社區活躍度高」: github start 超過 40k，且一直在維護。
-
「基於時序數據庫，存儲效率高」:
Prometheus核心部分只有一個單獨的二進制文件，不存在任何的第三方依賴 (數據庫，緩存等等)。唯一需要的就是 本地磁盤，因此不會有潛在級聯故障的風險。 -
「很好地支持容器監控」: 能自動發現容器，同時 k8s 和 etcd 等項目都提供了對
Prometheus的原生支持，是目前容器監控最流行的方案。 -
「基於 Pull 模型的架構」:
Prometheus基於 Pull 模型的架構方式，可以在任何地方（本地電腦，開發環境，測試環境）搭建我們的監控系統。
Prometheus 缺點
-
Prometheus是基於 Metric 的監控，不適用於日誌（Logs）、事件 (Event)、調用鏈 (Tracing)。 -
由於
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、如果非要自研，可以多研究下主流監控系統的架構方案，借鑑它們的優勢。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/x_TosBZU3qELoHaRUKw52w