1. zabbix

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

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

2. falcon

• Falcon-agent是用Go語言開發的Daemon程序，運行在每臺Linux服務器上，用于采集主機上的各種指標數據，主要包括CPU、內存、磁盤、文件系統、內核參數、Socket連接等，目前已經支持200多項監控指標。并且，Agent支持用戶自定義的監控腳本。
• Hearthbeat server簡稱HBS心跳服務，每個Agent都會周期性地通過RPC方式將自己的狀態上報給HBS，主要包括主機名、主機IP、Agent版本和插件版本，Agent還會從HBS獲取自己需要執行的采集任務和自定義插件。
• Transfer負責接收Agent發送的監控數據，并對數據進行整理，在過濾后通過一致性Hash算法發送到Judge或者Graph。
• Graph是基于RRD的數據上報、歸檔、存儲組件。Graph在收到數據以后，會以rrdtool的數據歸檔方式來存儲，同時提供RPC方式的監控查詢接口。
• Judge告警模塊，Transfer轉發到Judge的數據會觸發用戶設定的告警規則，如果滿足，則會觸發郵件、微信或者回調接口。這里為了避免重復告警引入了Redis暫存告警，從而完成告警的合并和抑制。
• Dashboard是面向用戶的監控數據查詢和告警配置界面。

3. prometheus

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

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

對比：

• 開發語言 便捷易部署(promehteus)
• 系統成熟度(zabbix)20多年
• 系統擴展性 Zabbix和Open-Falcon都可以自定義各種監控腳本，并且Zabbix不僅可以做到主動推送，還可以做到被動拉取，Prometheus則定義了一套監控數據規范，并通過各種exporter擴展系統采集能力。
• 數據存儲 Zabbix采用關系數據庫保存，這極大限制了Zabbix采集的性能，Nagios和Open-Falcon都采用RDD數據存儲 ，Prometheus自研一套高性能的時序數據庫，在V3版本可以達到每秒千萬級別的數據存儲，通過對接第三方時序數據庫擴展歷史數據的存儲;
• 配置復雜度 Prometheus只有一個核心server組件，其他系統配置相對麻煩，尤其是Open-Falcon。
• 社區活躍度 Prometheus在這方面占據絕對優勢，社區活躍度最高，并且受到CNCF的支持
• 容器支持 Prometheus開始成為主導及容器監控方面的標配

Prometheus功能介紹

(1) prometheus的指標類型

• Counter(計數器)：計數統計，累計多長或者累計多少次等。它的特點是只增不減，譬如HTTP訪問總量;
• Gauge(儀表盤)：數據是一個瞬時值，如果當前內存用量，它隨著時間變化忽高忽低。

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

• Histogram(直方圖)：服務端分位，不同區間內樣本的個數，譬如班級成績，低于60分的9個，低于70分的10個，低于80分的50個。
• Summary(摘要)：客戶端分位，直接在客戶端通過分位情況，還是用班級成績舉例：0.8分位的是，80分，0.9分為85分，0.99分為的是98分

(2) prometheus的client應用方式

• 客戶端集成client，提供metrics接口查詢
• 通過exporter方式

(3) prometheus的存儲方式

Prometheus提供了兩種數據持久化方式：

• 一種是本地存儲，通過Prometheus自帶的tsdb(時序數據庫)，將數據保存到本地磁盤，為了性能考慮，建議使用SSD。但本地存儲的容量畢竟有限，建議不要保存超過一個月的數據。Prometheus本地存儲經過多年改進，自Prometheus 2.0后提供的V3版本tsdb性能已經非常高，可以支持單機每秒1000w個指標的收集。
• 另一種是遠端存儲，適用于大量歷史監控數據的存儲和查詢。通過中間層的適配器的轉化，Prometheus將數據保存到遠端存儲。適配器實現Prometheus存儲的remote write和remote read接口并把數據轉化為遠端存儲支持的數據格式。目前，遠端存儲主要包括OpenTSDB、InfluxDB、Elasticsearch、M3db、Kafka等，其中M3db是目前非常受歡迎的后端存儲。

(4) prometheus的查詢方式

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

(5) 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的集群化。