來源：武哥談IT
這篇文章，我將對監控體系的基礎知識、原理和架構做一次系統性整理，同時還會對幾款最常用的開源監控產品做下介紹，以便大家選型時參考。內容包括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、如果非要自研，可以多研究下主流監控系統的架構方案，借鑒它們的優勢。
熱門推薦
