公司要上監控，Prometheus 是最熱門的監控解決方案，作爲喜新厭舊的程序員，我當然是選擇跟風了，但上級更傾向於 Zabbix，那沒辦法，只能好好對比一番，給出幾個靠譜的理由了。
Monitoring system
但稍稍深入一點，我就體會到，我之前其實並沒有真的理解口口相傳的 Prometheus 的優點，這次對比雖然是始於無奈，但還是蠻有意義的，正好總結一下自己粗淺的體會。
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 吧，畢竟人家就是幹這個的。