一篇吃透監控系統：主流工具選型及落地場景參考

這篇文章，我將對監控體系的基礎知識、原理和架構做一次系統性整理，同時還會對幾款最常用的開源監控產品做下介紹，以便大家選型時參考。內容包括3部分：

• 必知必會的監控基礎知識

• 主流監控系統介紹

• 監控系統的選型建議

1）幫助定位故障

在發生故障時，我們可以通過檢視監控系統的各項指標資料，輔助故障分析和定位。

2）預警減少故障率

對於即將可能產生的故障能夠及時發出預警資訊，做好提前預防處理。

4）輔助效能調優

JVM垃圾回收次數、介面響應時間、慢SQL等等都可以監控優化。

1）伺服器監控

CPU使用率、記憶體使用率、磁碟使用率、磁碟讀寫的吞吐量、網路出入流量等等。

2）MySQL監控

TPS、QPS、資料庫連線數、慢SQL、InnoDB緩衝池命中率等等。

3）Redis監控

記憶體使用率、快取命中率、key值總數、Redis響應請求時間、客戶端連線數、永續性指標等等。

4）MQ監控

連線數、佇列數、生產速率、消費速率、訊息堆積量等等。

5）應用監控

• HTTP介面：URL存活、請求量、耗時、異常量。

• JVM ：GC次數、GC耗時、各個記憶體區域的大小、當前執行緒數、死鎖執行緒數。

• 執行緒池：活躍執行緒數、任務佇列大小、任務執行耗時、拒絕任務數。

1）資料採集

採集的方式有很多種，包括日誌埋點進行採集，JMX標準介面輸出監控指標，被監控物件提供REST API進行資料採集（如Hadoop、ES），系統命令列，統一的SDK進行侵入式的埋點和上報等。

2）資料傳輸

將採集的資料以TCP、UDP或者HTTP協議的形式上報給監控系統，有主動Push模式，也有被動Pull模式。

3）資料儲存

有使用MySQL、Oracle等關係資料庫儲存的，也有使用時序資料庫RRDTool、OpentTSDB、InfluxDB儲存的，還有使用HBase儲存的。

4）資料展示

資料指標的圖形化展示。

5）監控告警

靈活的告警設定，以及支援郵件、簡訊、IM等多種通知通道。

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編寫，提供監控資料的展現和告警配置。

1）Zabbix的優勢

• 產品成熟

由於誕生時間長且使用廣泛，擁有豐富的文件資料以及各種開源的資料採集外掛，能覆蓋絕大部分監控場景。

• 採集方式豐富

支援Agent、SNMP、JMX、SSH等多種採集方式，以及主動和被動的資料傳輸方式。

2）Zabbix的劣勢

需要在被監控主機上安裝Agent，所有的資料都存在資料庫裡，產生的資料很大，瓶頸主要在資料庫。

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中查詢指標資料，彙總結果後統一返回給使用者，遮蔽了儲存叢集的分片細節。

1）Open-Falcon優勢

2）Open-Falcon缺點

• 監控型別較少

不支援常用應用伺服器如tomcat、apache、jetty等的監控。

• 整體發展一般，社群活躍度低

沒有專門的運維支援，程式碼更新較少，沒有一個較大的社群來維護，後續想要有什麼新的能力基本只能指望自己擴充套件。

我們知道 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的資料來源，建立儀表盤以及檢視指標。

1）Prometheus優點

• 社群活躍度高

github start超過40k，且一直在維護。

2）Prometheus缺點

• Prometheus 是基於 Metric 的監控，不適用於日誌（Logs）、事件(Event)、呼叫鏈(Tracing)。

• 由於Prometheus採用的是Pull模型拉取資料，意味著所有被監控的endpoint必須是可達的，需要合理規劃網路的安全配置。

• 指標眾多，需進行適當裁剪。