一、普米與zabbix基本介紹

1、prometheus介紹

Prometheus的基本原理是Prometheus Server通過HTTP周期性抓取被監(jiān)控組件的監(jiān)控數(shù)據(jù)，任意組件只要提供對應的HTTP接口并且符合Prometheus定義的數(shù)據(jù)格式，就可以接入Prometheus監(jiān)控。
工作流程大致分為收集數(shù)據(jù)，存儲數(shù)據(jù)，展示監(jiān)控數(shù)據(jù)，監(jiān)控告警。
核心組件包括：
Exporters：監(jiān)控數(shù)據(jù)采集器
Prometheus Server：負責對監(jiān)控數(shù)據(jù)的獲取，存儲以及查詢
AlertManager：告警流程管理
PushGateway：當網絡需求無法滿足時就可以使用PushGateway作為中轉站。
Prometheus后端數(shù)據(jù)庫用的自帶的時序數(shù)據(jù)庫TSDB，按時間索引性能更高。也支持其他遠端數(shù)據(jù)庫，但效率會有所下降。

普米架構圖

2、Zabbix介紹

Zabbix的基礎原理是Zabbix Server抓取監(jiān)控組件的監(jiān)控數(shù)據(jù)或者接收主動推送監(jiān)控數(shù)據(jù)。支持在每個網絡區(qū)域內部署一個Zabbix Proxy，即 Zabbix 的代理服務器，代理服務器采集當前區(qū)域的監(jiān)控組件的監(jiān)控數(shù)據(jù)。并將采集到的數(shù)據(jù)推送給 Zabbix Server 進行后續(xù)處理，
工作流程大致分為agent發(fā)送數(shù)據(jù)，sever存儲數(shù)據(jù)，展示監(jiān)控數(shù)據(jù)，監(jiān)控告警。
核心組件：
Agent：主要負責采集數(shù)據(jù)并通過主動或者被動的方式采集數(shù)據(jù)發(fā)送到Server/Proxy，除此之外，為了擴展監(jiān)控項，Agent還支持執(zhí)行自定義腳本。
Server：要負責接收Agent/Proxy發(fā)送的監(jiān)控信息，并進行匯總存儲，觸發(fā)告警等。
Zabbix Web ： zabbix的GUI接口，通常與server運行在同一臺機器上
Proxy：可選組件，常用于分布式監(jiān)控環(huán)境中，代理Server收集部分被監(jiān)控數(shù)據(jù)并統(tǒng)一發(fā)往Server端，減輕Sever端負載。
Zabbix Database支持常用的關系型數(shù)據(jù)庫，如MySQL、PostgreSQL、Oracle等，默認是MySQL?，F(xiàn)6.0版本支持TimescaleDB，關系數(shù)據(jù)庫較常用，學習成本低。

zabbix架構圖

二、功能測試對比

1、基礎監(jiān)控指標對比

注：本次監(jiān)控指標測試以主要在用的LINUX、mysql對象為例。

監(jiān)控LINUX主機指標對比：
Zabbix內置指標通過agent進行采集，agent安裝后需要配置文件。
prometheus由官方提供node_exporter采集器進行采集。直接解壓縮運行。

監(jiān)控mysql指標對比：
Zabbix支持agent、agent2兩種客戶端，agent2集成部分數(shù)據(jù)庫、ceph、red采集插件，不需要在客戶端另外配置。
Prometheus由官方提供mysqld_exporter采集器進行采集。

監(jiān)控指標測試結論：
采集指標項上：Prometheus相較zabbix監(jiān)控指標項更細。
采集頻率上：zabbix可根據(jù)指標自定義頻率，prometheus通過統(tǒng)一參數(shù)scrape_interval配置采集頻率。
自定義監(jiān)控指標上：zabbix提供agent+自定義腳本方式采集、配置繁瑣， prometheus需要對源碼進行二次開發(fā)困難。
采集分組情況上：Zabbix可通過agent采集多個業(yè)務組件，管理方便。 Prometheus需要部署多個exporter采集不同的業(yè)務組件，服務端口不固定。

2、云原生k8s監(jiān)控對比

Zabbix 6.0 LTS新增Kubernetes監(jiān)控功能
多個維度采集指標：
Kubernetes節(jié)點和pods的自動發(fā)現(xiàn)和監(jiān)控
無代理方式采集Kubernetes pods和節(jié)點的信息
獲取Kubernetes節(jié)點主機高水平信息：
kube-controller-manager、kube-apiserver、kube-scheduler、kubelet

監(jiān)控部署方式
ZABBIX6.0提供HELM方式部署，將ZABBIX AGENT和ZABBIX PROXY等部署在Kubernetes集群中。并提供相應的模板，對Kubernetes集群進行自動發(fā)現(xiàn)及數(shù)據(jù)采集。

測試結論
ZABBIX6.0LTS版本雖然支持Kubernetes監(jiān)控，原生模板監(jiān)控項目前無法滿足所需采集指標，需再自定義定制更豐富的監(jiān)控項。
Prometheus監(jiān)控Kubernetes更有優(yōu)勢，k8s組件自帶采集接口，普米自動發(fā)現(xiàn)k8s組件Targets，抓取metrics數(shù)據(jù)，且兩者出自于統(tǒng)一基金會，適配度更佳，對集群數(shù)據(jù)采集更全面。

3、高可用架構對比

zabbix高可用?
Zabbix6.0 支持原生 Zabbix server 高可用HA集群。
Zabbix HA由多個zabbix_server實例或節(jié)點組成。每個節(jié)點獨立配置，集群為主備模式，standby（備用）節(jié)點不進行數(shù)據(jù)收集、處理或其他任務，并且不監(jiān)聽端口，并保持一個最少的數(shù)據(jù)庫連接。
在 Zabbix 儀表板或Runtime運行時的命令行上可監(jiān)控 Zabbix 集群的狀態(tài)。
Zabbix 支持部署Zabbix proxy ，有利于分擔 Zabbix server 的負載。

普米高可用
支持Federation聯(lián)邦集群機制。集群分布式類似于nginx的負載均衡模式。
聯(lián)邦集群核心在于每一個prometheus server都包含一個用于獲取當前實例中監(jiān)控樣本的接口 ，每個server處理接收監(jiān)控數(shù)據(jù)。
不同類型的采集任務劃分到不同的 Prometheus 實例中去執(zhí)行，進行功能分片。

對比優(yōu)缺點
高可用配置方面：Zabbix HA 配置簡單，操作維護成本低。
普米需要考慮數(shù)據(jù)持久化的問題。分層架構帶來的配置復雜，維護成本較高。
聯(lián)邦模式可以實現(xiàn)prometheus監(jiān)控prometheus。

4、部署方式、版本升級方式對比

zabbix部署、升級方式
支持 二進制文件安裝、源代碼包安裝、容器中安裝三種方式。
容器化部署和版本開發(fā)迭代最簡單快捷，zabbix各組件容器中單獨運行，互不影響。
純容器化部署存在采集壓力過大影響容器集群、數(shù)據(jù)持久化問題。
需部署客戶端agent采集程序。
zabbix版本升級過程復雜，特別跨版本的升級，需完成大量檢查、驗證工作。升級版本sever和proxy需保持一致，agents 不是強制性的（但推薦）。

普米部署、升級方式
支持源代碼包安裝、容器中安裝兩種方式。監(jiān)控、告警和界面都分屬于不同的組件，都需要安裝。
容器化部署更簡單快捷，容器適配性更好。
客戶端需安裝exporter采集器命令。
普米目前版本更新不大，2.0升級包含許多向后不兼容的更改，官方也無實際升級步驟，只有更新版本的遷移指南。

兩者對比優(yōu)缺點
都可以容器化部署，普米部署更方便些。
zabbix客戶端需安裝agent服務，普米客戶端安裝exporter命令，zabbix-agent安裝維護更復雜繁瑣。
zabbix版本升級過程更復雜且迭代比較快。

三、選型建議-prometheus和zabbix全面對比情況

? 所以，需要根據(jù)不同的IT架構選型適合當前環(huán)境的監(jiān)控軟件，在傳統(tǒng)架構里zabbix更有優(yōu)勢，但在云原生下現(xiàn)階段還是普米用的多點。

??? ?There are many things that can not be broken！

? ? ?如果覺得本文對你有幫助，歡迎點贊、收藏、評論！