Prometheus vs Zabbix

轉載地址：https://www.jianshu.com/p/b3a261d1502b

1. 對比
   先對二者的各自特色進行一下對比：

Zabbix
Prometheus

後端用 C 開發，界面用 PHP 開發，定製化難度很高。
後端用 golang 開發，前端是 Grafana，JSON 編輯便可解決。定製化難度較低。

集羣規模上限爲 10000 個節點。
支持更大的集羣規模，速度也更快。

更適合監控物理機環境。
更適合雲環境的監控，對 OpenStack，Kubernetes 有更好的集成。

監控數據存儲在關係型數據庫內，如 MySQL，很難從現有數據中擴展維度。
監控數據存儲在基於時間序列的數據庫內，便於對已有數據進行新的聚合。

安裝簡單，zabbix-server 一個軟件包中包括了全部的服務端功能。
安裝相對複雜，監控、告警和界面都分屬於不一樣的組件。

圖形化界面比較成熟，界面上基本上能完成所有的配置操做。
界面相對較弱，不少配置須要修改配置文件。

發展時間更長，對於不少監控場景，都有現成的解決方案。
2015 年後開始快速發展，但發展時間較短，成熟度不及 Zabbix。

2. 解析
   更進一步的分析二者的主要差別：
   2.1 圖形化仍是配置文件
   Zabbix 的圖形化配置毫無疑問是完爆 Prometheus 的，但這真的是個優點嗎？
   細想起來還真未必。圖形化確實省去了手動改配置文件和命令行的繁瑣，但這種努力毫無疑問是已經作出了須要人工介入的假設。但 Prometheus 是爲雲原生環境而生的，這種狀況下，環境是動態變化的，服務器會隨時增減，人工介入不太現實，那麼圖形化在這種狀況下意義就不大了，畢竟要作自動化，那就沒必要要過圖形界面這一道了。這麼看來 Prometheus 在圖形化方面的簡約也是有意的取捨。
   2.2 時序數據庫仍是關係型數據
   近幾年興起的監控系統大部分都選擇了將數據存儲在時序型數據庫中，Prometheus 用的就是自研的 TSDB，Zabbix 則用的是 MySQL 或 PostgreSQL。對於時序型數據庫我瞭解很少，粗淺的來看，Prometheus 的時序型數據庫在高併發的狀況下，讀寫性能是遠高過傳統的關係型數據庫的，另外還提供了不少內置的基於時間的處理函數，簡化數據聚合的難度。也許這不能簡單的理解爲兩種數據庫的特性形成的結果，但至少說明，對專門監控場景進行存儲優化，是十分必要的。
   2.3 服務發現
   你們都知道 Prometheus 在收集數據時，採用的 Pull 模型（服務端主動去客戶端拉取數據），而以 Zabbix 爲表明的傳統監控採用的 Push 模型（客戶端發送數據給服務端）。Pull 模型在雲原生環境中有比較大的優點，緣由是分佈式系統中，必定是有中心節點知道整個集羣信息的，那麼經過中心節點就能夠完成全部要監控節點的服務發現，去拉取數據就行了；Push 模型卻是省去了服務發現的步驟，但每一個被監控的服務都須要內置客戶端，還須要配置監控服務端的信息，這加大了部署的難度，Push 模型在 OpenStack 和 Kubernetes 等環境中用的很少。
   2.4 開發語言
   Golang 和 C 語言的開發對比，這就不用多解釋了，不是一個時代的語言，Golang 佔絕對優點。PHP 寫界面卻是很常規的選擇，但無奈 Grafana 寫界面都不用編程語言，JSON 和 YAML 就能夠搞定。因此真的要作定製開發，Prometheus 的難度要小不少。
3. 總結Zabbix 的成熟度更高，上手更快，但更好的集成致使靈活性較差，問題更大是，監控數據的複雜度增長後，Zabbix 作進一步定製難度很高，即便作好了定製，也無法利用以前收集到的數據了（關係型數據庫形成的問題）。Prometheus 基本上是正相反，上手難度大一些，但因爲定製靈活度高，數據也有更多的聚合可能，起步後的使用難度遠小於 Zabbix。比較一番下來，個人建議是，若是是剛剛要上監控系統的話，不用猶豫了，Prometheus 準沒錯。但若是已經對傳統監控系統有技術積累的話，仍是要謹慎考慮：若是監控的是物理機，用 Zabbix 沒毛病，或者是環境變更不會很頻繁的狀況下，Zabbix 也會比 Prometheus 好使；但若是是雲環境的話，除非是 Zabbix 玩的很是溜，能夠作各類定製，那仍是 Prometheus 吧，畢竟人家就是幹這個的。