運維之三大監控對比

zabbix

Zabbix核心組件主要是Agent和Server，其中Agent主要負責採集數據並通過主動或者被動的方式採集數據發送到Server/Proxy，除此之外，為了擴展監控項，Agent還支持執行自定義腳本。Server主要負責接收Agent發送的監控信息，並進行彙總存儲，觸發告警等。

Zabbix由於使用了關係型數據存儲時序數據，所以在監控大規模集群時常常在數據存儲方面捉襟見肘。所以從Zabbix 4.2版本後開始支持TimescaleDB時序數據庫，不過目前成熟度還不高。

falcon

1）Falcon-agent是用Go語言開發的Daemon程序，運行在每臺Linux服務器上，用於採集主機上的各種指標數據，主要包括CPU、內存、磁盤、文件系統、內核參數、Socket連接等，目前已經支持200多項監控指標。並且，Agent支持用戶自定義的監控腳本。

2）Hearthbeat server簡稱HBS心跳服務，每個Agent都會週期性地通過RPC方式將自己的狀態上報給HBS，主要包括主機名、主機IP、Agent版本和插件版本，Agent還會從HBS獲取自己需要執行的採集任務和自定義插件。

3）Transfer負責接收Agent發送的監控數據，並對數據進行整理，在過濾後通過一致性Hash算法發送到Judge或者Graph。

4）Graph是基於RRD的數據上報、歸檔、存儲組件。Graph在收到數據以後，會以rrdtool的數據歸檔方式來存儲，同時提供RPC方式的監控查詢接口。

5）Judge告警模塊，Transfer轉發到Judge的數據會觸發用戶設定的告警規則，如果滿足，則會觸發郵件、微信或者回調接口。這裡為了避免重複告警引入了Redis暫存告警，從而完成告警的合併和抑制。

6）Dashboard是面向用戶的監控數據查詢和告警配置界面。

prometheus

Prometheus Server負責定時在目標上抓取metrics（指標）數據並保存到本地存儲裡面。Prometheus採用了一種Pull（拉）的方式獲取數據，不僅降低客戶端的複雜度，客戶端只需要採集數據，無需瞭解服務端情況，而且服務端可以更加方便的水平擴展。

如果監控數據達到告警閾值Prometheus Server會通過HTTP將告警發送到告警模塊alertmanger，通過告警的抑制後觸發郵件或者webhook。Prometheus支持PromQL提供多維度數據模型和靈活的查詢，通過監控指標關聯多個tag的方式，將監控數據進行任意維度的組合以及聚合。

對比：

1、開發語言 便捷易部署（promehteus）

2、系統成熟度（zabbix）20多年

3、系統擴展性 Zabbix和Open-Falcon都可以自定義各種監控腳本，並且Zabbix不僅可以做到主動推送，還可以做到被動拉取，Prometheus則定義了一套監控數據規範，並通過各種exporter擴展系統採集能力。

4、 數據存儲 Zabbix採用關係數據庫保存，這極大限制了Zabbix採集的性能，Nagios和Open-Falcon都採用RDD數據存儲 ，Prometheus自研一套高性能的時序數據庫，在V3版本可以達到每秒千萬級別的數據存儲，通過對接第三方時序數據庫擴展歷史數據的存儲；

5、配置複雜度 Prometheus只有一個核心server組件，其他系統配置相對麻煩，尤其是Open-Falcon。

6、 社區活躍度 Prometheus在這方面佔據絕對優勢，社區活躍度最高，並且受到CNCF的支持

7、容器支持 Prometheus開始成為主導及容器監控方面的標配

Prometheus功能介紹

prometheus的指標類型

1）Counter（計數器）：計數統計，累計多長或者累計多少次等。它的特點是隻增不減，譬如HTTP訪問總量；

2）Gauge（儀表盤）：數據是一個瞬時值，如果當前內存用量，它隨著時間變化忽高忽低。

如果需要了解某個時間段內請求的響應時間，通常做法是使用平均響應時間，但這樣做無法體現數據的長尾效應。例如，一個HTTP服務器的正常響應時間是30ms，但有很少幾次請求耗時3s，通過平均響應時間很難甄別長尾效應，所以Prometheus引入了Histogram和Summary。

3）Histogram（直方圖）：服務端分位，不同區間內樣本的個數，譬如班級成績，低於60分的9個，低於70分的10個，低於80分的50個。

4）Summary（摘要）：客戶端分位，直接在客戶端通過分位情況，還是用班級成績舉例：0.8分位的是，80分，0.9分為85分，0.99分為的是98分

prometheus的client應用方式

1、客戶端集成client，提供metrics接口查詢

2、通過exporter方式

Prometheus提供了兩種數據持久化方式：一種是本地存儲，通過Prometheus自帶的tsdb（時序數據庫），將數據保存到本地磁盤，為了性能考慮，建議使用SSD。但本地存儲的容量畢竟有限，建議不要保存超過一個月的數據。Prometheus本地存儲經過多年改進，自Prometheus 2.0後提供的V3版本tsdb性能已經非常高，可以支持單機每秒1000w個指標的收集。

另一種是遠端存儲，適用於大量歷史監控數據的存儲和查詢。通過中間層的適配器的轉化，Prometheus將數據保存到遠端存儲。適配器實現Prometheus存儲的remote write和remote read接口並把數據轉化為遠端存儲支持的數據格式。目前，遠端存儲主要包括OpenTSDB、InfluxDB、Elasticsearch、M3db、Kafka等，其中M3db是目前非常受歡迎的後端存儲。

prometheus的查詢方式

和關係型數據庫的SQL類似，Prometheus也內置了數據查詢語言PromQL，它提供對時間序列數據豐富的查詢，聚合以及邏輯運算的能力。一條PromQL主要包括了指標名稱、過濾器以及函數和參數。並且指標可以進行數據運算。

prometheus的監控方式

Prometheus配置監控對象有兩種方式，一種是通過靜態文件配置，另一種是動態發現機制，自動註冊監控對象。

Prometheus動態發現目前已經支持Kubernetes、etcd、Consul等多種服務發現機制，動態發現機制可以減少運維人員手動配置，在容器運行環境中尤為重要，容器集群通常在幾千甚至幾萬的規模，如果每個容器都需要單獨配置監控項不僅需要大量工作量，而且容器經常變動，後續維護更是異常麻煩。針對Kubernetes環境的動態發現，Prometheus通過watch kubernetes api動態獲取當前集群所有服務和容器情況，從而動態調整監控對象

為了擴展單個Prometheus的採集能力和存儲能力，Prometheus引入了“聯邦”的概念。

多個Prometheus節點組成兩層聯邦結構，如圖所示，上面一層是聯邦節點，負責定時從下面的Prometheus節點獲取數據並彙總，部署多個聯邦節點是為了實現高可用

並且聯邦機制可以分為倆種，一種是跨服務聯合，一種是分層聯邦。

跨服務聯合，從不同的源抓取特定的服務的監控數據，然後做聚合處理；

分層聯邦，就向一顆樹，更高級別的prometheus服務從大量次級服務器收集聚合時間序列數據，然後去統一制定告警規則，分發觸發事件。

除此之外，prometheus可以依靠Thanos外掛服務，實現prometheus集群化、以及數據長期存儲的功能，有興趣的可以瞭解下。其實在prometheus2.0自身使用remote-wirte，remote-read接口已經解決了數據長期存儲的問題了。預計3.0會做出更大的提升，尤其是prometheus的集群化。