公司要上監(jiān)控，Prometheus 是最熱門(mén)的監(jiān)控解決方案，作為喜新厭舊的程序員，我當(dāng)然是選擇跟風(fēng)了，但上級(jí)更傾向于 Zabbix，那沒(méi)辦法，只能好好對(duì)比一番，給出幾個(gè)靠譜的理由了。
但稍稍深入一點(diǎn)，我就體會(huì)到，我之前其實(shí)并沒(méi)有真的理解口口相傳的 Prometheus 的優(yōu)點(diǎn)，這次對(duì)比雖然是始于無(wú)奈，但還是蠻有意義的，正好總結(jié)一下自己粗淺的體會(huì)。
1. 對(duì)比
先對(duì)兩者的各自特點(diǎn)進(jìn)行一下對(duì)比：
| Zabbix | Prometheus |
|---|---|
| 后端用 C 開(kāi)發(fā)，界面用 PHP 開(kāi)發(fā)，定制化難度很高。 | 后端用 golang 開(kāi)發(fā)，前端是 Grafana，JSON 編輯即可解決。定制化難度較低。 |
| 集群規(guī)模上限為 10000 個(gè)節(jié)點(diǎn)。 | 支持更大的集群規(guī)模，速度也更快。 |
| 更適合監(jiān)控物理機(jī)環(huán)境。 | 更適合云環(huán)境的監(jiān)控，對(duì) OpenStack，Kubernetes 有更好的集成。 |
| 監(jiān)控?cái)?shù)據(jù)存儲(chǔ)在關(guān)系型數(shù)據(jù)庫(kù)內(nèi)，如 MySQL，很難從現(xiàn)有數(shù)據(jù)中擴(kuò)展維度。 | 監(jiān)控?cái)?shù)據(jù)存儲(chǔ)在基于時(shí)間序列的數(shù)據(jù)庫(kù)內(nèi)，便于對(duì)已有數(shù)據(jù)進(jìn)行新的聚合。 |
| 安裝簡(jiǎn)單，zabbix-server 一個(gè)軟件包中包括了所有的服務(wù)端功能。 | 安裝相對(duì)復(fù)雜，監(jiān)控、告警和界面都分屬于不同的組件。 |
| 圖形化界面比較成熟，界面上基本上能完成全部的配置操作。 | 界面相對(duì)較弱，很多配置需要修改配置文件。 |
| 發(fā)展時(shí)間更長(zhǎng)，對(duì)于很多監(jiān)控場(chǎng)景，都有現(xiàn)成的解決方案。 | 2015 年后開(kāi)始快速發(fā)展，但發(fā)展時(shí)間較短，成熟度不及 Zabbix。 |
2. 解析
更進(jìn)一步的分析兩者的主要差異：
2.1 圖形化還是配置文件
Zabbix 的圖形化配置毫無(wú)疑問(wèn)是完爆 Prometheus 的，但這真的是個(gè)優(yōu)勢(shì)嗎？
細(xì)想起來(lái)還真未必。圖形化確實(shí)省去了手動(dòng)改配置文件和命令行的繁瑣，但這種努力毫無(wú)疑問(wèn)是已經(jīng)做出了需要人工介入的假設(shè)。但 Prometheus 是為云原生環(huán)境而生的，這種情況下，環(huán)境是動(dòng)態(tài)變化的，服務(wù)器會(huì)隨時(shí)增減，人工介入不太現(xiàn)實(shí)，那么圖形化在這種情況下意義就不大了，畢竟要做自動(dòng)化，那就不必要過(guò)圖形界面這一道了。這么看來(lái) Prometheus 在圖形化方面的簡(jiǎn)約也是有意的取舍。
2.2 時(shí)序數(shù)據(jù)庫(kù)還是關(guān)系型數(shù)據(jù)
近幾年興起的監(jiān)控系統(tǒng)大部分都選擇了將數(shù)據(jù)存儲(chǔ)在時(shí)序型數(shù)據(jù)庫(kù)中，Prometheus 用的就是自研的 TSDB，Zabbix 則用的是 MySQL 或 PostgreSQL。對(duì)于時(shí)序型數(shù)據(jù)庫(kù)我了解不多，粗淺的來(lái)看，Prometheus 的時(shí)序型數(shù)據(jù)庫(kù)在高并發(fā)的情況下，讀寫(xiě)性能是遠(yuǎn)高過(guò)傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)的，另外還提供了很多內(nèi)置的基于時(shí)間的處理函數(shù)，簡(jiǎn)化數(shù)據(jù)聚合的難度。也許這不能簡(jiǎn)單的理解為兩種數(shù)據(jù)庫(kù)的特性造成的結(jié)果，但至少說(shuō)明，對(duì)專門(mén)監(jiān)控場(chǎng)景進(jìn)行存儲(chǔ)優(yōu)化，是十分必要的。
2.3 服務(wù)發(fā)現(xiàn)
大家都知道 Prometheus 在收集數(shù)據(jù)時(shí)，采用的 Pull 模型（服務(wù)端主動(dòng)去客戶端拉取數(shù)據(jù)），而以 Zabbix 為代表的傳統(tǒng)監(jiān)控采用的 Push 模型（客戶端發(fā)送數(shù)據(jù)給服務(wù)端）。Pull 模型在云原生環(huán)境中有比較大的優(yōu)勢(shì)，原因是分布式系統(tǒng)中，一定是有中心節(jié)點(diǎn)知道整個(gè)集群信息的，那么通過(guò)中心節(jié)點(diǎn)就可以完成所有要監(jiān)控節(jié)點(diǎn)的服務(wù)發(fā)現(xiàn)，去拉取數(shù)據(jù)就好了；Push 模型倒是省去了服務(wù)發(fā)現(xiàn)的步驟，但每個(gè)被監(jiān)控的服務(wù)都需要內(nèi)置客戶端，還需要配置監(jiān)控服務(wù)端的信息，這加大了部署的難度，Push 模型在 OpenStack 和 Kubernetes 等環(huán)境中用的不多。
2.4 開(kāi)發(fā)語(yǔ)言
Golang 和 C 語(yǔ)言的開(kāi)發(fā)對(duì)比，這就不用多解釋了，不是一個(gè)時(shí)代的語(yǔ)言，Golang 占絕對(duì)優(yōu)勢(shì)。PHP 寫(xiě)界面倒是很常規(guī)的選擇，但無(wú)奈 Grafana 寫(xiě)界面都不用編程語(yǔ)言，JSON 和 YAML 就可以搞定。所以真的要做定制開(kāi)發(fā)，Prometheus 的難度要小很多。
3. 總結(jié)
Zabbix 的成熟度更高，上手更快，但更好的集成導(dǎo)致靈活性較差，問(wèn)題更大是，監(jiān)控?cái)?shù)據(jù)的復(fù)雜度增加后，Zabbix 做進(jìn)一步定制難度很高，即使做好了定制，也沒(méi)法利用之前收集到的數(shù)據(jù)了（關(guān)系型數(shù)據(jù)庫(kù)造成的問(wèn)題）。
Prometheus 基本上是正相反，上手難度大一些，但由于定制靈活度高，數(shù)據(jù)也有更多的聚合可能，起步后的使用難度遠(yuǎn)小于 Zabbix。
比較一番下來(lái)，我的建議是，如果是剛剛要上監(jiān)控系統(tǒng)的話，不用猶豫了，Prometheus 準(zhǔn)沒(méi)錯(cuò)。
但如果已經(jīng)對(duì)傳統(tǒng)監(jiān)控系統(tǒng)有技術(shù)積累的話，還是要謹(jǐn)慎考慮：如果監(jiān)控的是物理機(jī)，用 Zabbix 沒(méi)毛病，或者是環(huán)境變動(dòng)不會(huì)很頻繁的情況下，Zabbix 也會(huì)比 Prometheus 好使；但如果是云環(huán)境的話，除非是 Zabbix 玩的非常溜，可以做各種定制，那還是 Prometheus 吧，畢竟人家就是干這個(gè)的。
